Installer crash at partition step

Hi,

I originally described the issue here: Installer crash on partition - #13 by joekamprad

I removed all partitions before running the installer. When I am at the partitioning stage, I select the NVMe disk, select erase to create a SWAP partition with hibernate. The installer crashes.
It seems like there is a random chance when changing the SWAP option for the installer to crash.

Here is the log: https://0x0.st/88E-.txt (although I looked into it and I do not see any errors there)

These debug lines appeared even when the installer ran correctly so I don’t think these are related.

08:41:35 [6]: DEBUG (Qt): getting temp failed for  "/dev/nvme0n1" :  No such file or directory
08:41:35 [6]: DEBUG (Qt): getting powered on time failed for  "/dev/nvme0n1" :  No such file or directory
08:41:35 [6]: DEBUG (Qt): getting power cycles failed for  "/dev/nvme0n1" :  No such file or directory

Did you try creating a new gpt partition on the disk first with gparted. Then run the installer and select erase disc swap file and bootloader of choice.

Edit: I am suggesting this rather than just deleting the partitions because something maybe not quite right with the main GPT partition.

I completed the installation successfully after a few tries. The issue was appearing randomly when changing the SWAP option. If I kept changing the option it would crash when selecting it, not when applying the change.
As I already ran the installer, I could try to reproduce the issue, but my disk would not be unallocated.

To be clear, there was not any partitions on the disk selected. And I was able to reproduce it multiple times.

If you are randomly changing the swap option and I don’t know if that was after one attempt or not it is best to restart the ISO and select what you want. If you make changes after making a setting it has to reset and sometimes it can cause it to crash.

Do you mean it was unallocated space and no GPT partition existed? What I was suggesting was to create the initial GPT partition first with gparted and then run the installer if you are having this issue. But it’s all a moot point since you already have it installed.

I am writing this because it happened multiple times when I first selected the option. Then, by trying more times, I noticed it was randomly crashing, and I guess I was not lucky the first time. The installer works great after that, and if you keep trying it will work.
My understanding is, there may be a bug when querying some information that makes the installer crash.
It was unallocated space. Creating the initial GPT partition might resolve the issue, but there might be something to fix in the installer to avoid users encountering this in the future. Maybe it only happens when you modify the partition using gparted before running the installer ?

I know it happens to some users but it isn’t frequent. I do a lot of installs testing and if anyone would run into this it should happen to me. It’s surprising that i haven’t worn out my disks by now. All i can say is that it’s not happened to me. That way the installer works with scripts is that sometimes like i said it has to reset and maybe it gets tripped up when doing that. It could be for a number of reasons because it is an online installer there are many factors that could possibly cause it to have a conniption. :man_shrugging:

I haven’t found this happening to me. The only issue i have seen is when using replace partition sometimes which i rarely use.

What kind of tools should I use to gather more information about what the installer is trying to do if I try to reproduce the issue in the future (as the log is not detailed enough to capture the information) ?

The install log is all that I know. :person_shrugging:

Edit:

I’m also not that great at deciphering what I’m always looking through either. :wink:
I try my best!

So I restarted the ISO, selected all default settings, and I was able to reproduce the issue. The system log from dmesg shows the following:

[  237.324273] calamares[2655]: segfault at 10000000000 ip 00007c9f332a12a6 sp 00007fffe8d58a08 error 4 in libQt6Gui.so.6.7.2[4a12a6,7c9f32ed9000+627000] likely on CPU 7 (core 3, socket 0)
[  237.324283] Code: 4c 39 47 08 75 35 48 8b 76 08 48 85 f6 74 2c 48 8b 76 08 3b 46 40 7d 23 8b 7e 44 39 f9 7d 1c 0f af c7 48 8b 56 30 01 c8 48 98 <48> 8b 14 c2 48 89 d0 c3 66 90 48 8b 97 08 01 00 00 48 89 d0 c3 90
[  237.324326] audit: type=1701 audit(1738345378.616:174): auid=1000 uid=0 gid=0 ses=2 pid=2655 comm="calamares" exe="/usr/bin/calamares" sig=11 res=1

I tried to look at strace too:

statx(AT_FDCWD, "/root/.config/kdeglobals", AT_STATX_SYNC_AS_STAT|AT_NO_AUTOMOUNT, STATX_ALL, {stx_mask=STATX_BASIC_STATS|STATX_MNT_ID, stx_attributes=0, stx_mode=S_IFREG|0644, stx_size=3421, ...}) = 0
statx(AT_FDCWD, "/root/.config/kdeglobals", AT_STATX_SYNC_AS_STAT|AT_NO_AUTOMOUNT, STATX_ALL, {stx_mask=STATX_BASIC_STATS|STATX_MNT_ID, stx_attributes=0, stx_mode=S_IFREG|0644, stx_size=3421, ...}) = 0
--- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0x10001006b} ---
+++ killed by SIGSEGV (core dumped) +++

if someone needs extra information, I can easily reproduce the issue (at least on my machine :slight_smile: )

It will have to be looked at by the devs. :wink:

After looking through the github issues of calamares, I found an issue that looks like mine: https://github.com/calamares/calamares/issues/2405
except I am not sure it fixes exactly the same thing. I guess we can wait until https://github.com/calamares/calamares/pull/2414/commits/3e9eabe9df8a8412d0cccd583001440a2075bb61 gets into the endeavouros fork.

Hello! I’m new here so I’m not sure if this is a helpful addition to the discussion, but I had the installer crash on me today when I was using the keyboard to cycle through options for “swap” in the “Partitions” section of the installer. Searching found me this bug report which seems related. I’m able to restart the installer so this isn’t stopping me from progressing, but I figured I’d add this experience to the discussion.

2 years later :waving_hand: