[stevef]

Having problems with the installer.  Downloaded iso, checked sha256 and made a USB.

Booted and attempted to install to the elderly notebook which we eventually got working with RC.  With this release version, calamares reports having problems creating partitioning.  Still using the good disk - though I will recheck it.

After two install failures, I tried to follow what was going on and it seems that as calamares creates the partitions, the system mounts them.  If I followed the RC testing correctly, this is along the same lines as the problem with early RC.  On the third attempt to install, I tried to note the timings of events to make the calamares log clearer.  I've saved the log, but unfortunately the forum is telling me I can't attach the type of file.

Here's an extract

Code:

2026-06-01 - 14:36:04 [2]:    WARNING: Diagnostic state:
"--- Diagnostic state at failure ---\nlsblk:\nNAME  FSTYPE  MOUNTPOINT                SIZE UUID\nloop0  squashfs /rofs                    2.2G \nsda                                    223.6G \n`-sda1 ext4    /run/media/linux/rootfs 215.8G 7d84491f-1ebb-47f1-876f-8b3362d98e70\nsdb    iso9660                          14.5G 2026-05-30-23-44-31-00\n|-sdb1 iso9660  /cdrom                    2.4G 2026-05-30-23-44-31-00\n|-sdb2 vfat                                5M 73B7-988D\n`-sdb3 ext4    /var/crash              12.1G bfe778aa-99a7-45dd-8b6e-1079edaf2867\nsdc                                        0B \nsdd                                      3.8G \n`-sdd1 ext4    /run/media/linux/ext4    3.8G eee300b2-f75e-4127-9574-1adfbfec7245\nzram0                                      0B\ndmesg tail:\n[Mon Jun  1 14:05:21 2026] xor: measuring software checksum speed\n[Mon Jun  1 14:05:21 2026]    prefetch64-sse  :  2076 MB/sec\n[Mon Jun  1 14:05:21 2026]    generic_sse    :  1985 MB/sec\n[Mon Jun  1 14:05:21 2026] xor: using function: prefetch64-sse (2076 MB/sec)\n[Mon Jun  1 14:05:22 2026] Btrfs loaded, zoned=yes, fsverity=yes\n[Mon Jun  1 14:05:27 2026] SGI XFS with ACLs, security attributes, realtime, quota, no debug enabled\n[Mon Jun  1 14:06:07 2026]  sda:\n[Mon Jun  1 14:06:53 2026]  sda:\n[Mon Jun  1 14:09:03 2026] systemd-sysv-generator[5721]: SysV service '/etc/init.d/LiteDistroBuilder-firstboot' lacks a native systemd unit file, automatically generating a unit file for compatibility.\n[Mon Jun  1 14:09:03 2026] systemd-sysv-generator[5721]: Please update package to include a native systemd unit file.\n[Mon Jun  1 14:09:03 2026] systemd-sysv-generator[5721]: ! This compatibility logic is deprecated, expect removal soon. !\n[Mon Jun  1 14:09:03 2026] systemd-sysv-generator[5721]: SysV service '/etc/init.d/WolfLandBuilder-firstboot' lacks a native systemd unit file, automatically generating a unit file for compatibility.\n[Mon Jun  1 14:09:03 2026] systemd-sysv-generator[5721]: Please update package to include a native systemd unit file.\n[Mon Jun  1 14:09:03 2026] systemd-sysv-generator[5721]: ! This compatibility logic is deprecated, expect removal soon. !\n[Mon Jun  1 14:09:03 2026] systemd-sysv-generator[5721]: SysV service '/etc/init.d/grub-common' lacks a native systemd unit file, automatically generating a unit file for compatibility.\n[Mon Jun  1 14:09:03 2026] systemd-sysv-generator[5721]: Please update package to include a native systemd unit file.\n[Mon Jun  1 14:09:03 2026] systemd-sysv-generator[5721]: ! This compatibility logic is deprecated, expect removal soon. !\n[Mon Jun  1 14:09:03 2026] systemd-sysv-generator[5721]: SysV service '/etc/init.d/hddtemp' lacks a native systemd unit file, automatically generating a unit file for compatibility.\n[Mon Jun  1 14:09:03 2026] systemd-sysv-generator[5721]: Please update package to include a native systemd unit file.\n[Mon Jun  1 14:09:03 2026] systemd-sysv-generator[5721]: ! This compatibility logic is deprecated, expect removal soon. !\n[Mon Jun  1 14:11:16 2026] perf: interrupt took too long (4958 > 4947), lowering kernel.perf_event_max_sample_rate to 40000\n[Mon Jun  1 14:11:43 2026] JFS: nTxBlock = 8192, nTxLock = 65536\n[Mon Jun  1 14:12:07 2026] QNX4 filesystem 0.2.3 registered.\n[Mon Jun  1 14:17:14 2026]  sda:\n[Mon Jun  1 14:17:14 2026]  sda:\n[Mon Jun  1 14:17:55 2026]  sda: sda1\n[Mon Jun  1 14:18:02 2026] EXT4-fs (sda1): mounted filesystem 7d84491f-1ebb-47f1-876f-8b3362d98e70 r/w with ordered data mode. Quota mode: none.\n[Mon Jun  1 14:23:55 2026] atl1c 0000:06:00.0: atl1c: enp6s0 NIC Link is Up<100 Mbps Full Duplex>\n[Mon Jun  1 14:23:55 2026] brcmsmac bcma0:1: brcms_ops_bss_info_changed: qos enabled: false (implement)\n[Mon Jun  1 14:23:55 2026] brcmsmac bcma0:1: brcms_ops_config: change power-save mode: false (implement)\n[Mon Jun  1 14:27:18 2026] EXT4-fs (sda1): unmounting filesystem 7d84491f-1ebb-47f1-876f-8b3362d98e70.\n[Mon Jun  1 14:27:57 2026]  sda:\n[Mon Jun  1 14:27:57 2026]  sda:\n[Mon Jun  1 14:28:21 2026]  sda: sda1\n[Mon Jun  1 14:28:21 2026]  sda: sda1\n[Mon Jun  1 14:28:29 2026] EXT4-fs (sda1): mounted filesystem 7d84491f-1ebb-47f1-876f-8b3362d98e70 r/w with ordered data mode. Quota mode: none.\n[Mon Jun  1 14:31:27 2026] usb 1-1: new high-speed USB device number 4 using ehci-pci\n[Mon Jun  1 14:31:27 2026] usb 1-1: New USB device found, idVendor=abcd, idProduct=1234, bcdDevice= 1.00\n[Mon Jun  1 14:31:27 2026] usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3\n[Mon Jun  1 14:31:27 2026] usb 1-1: Product: UDisk          \n[Mon Jun  1 14:31:27 2026] usb 1-1: Manufacturer: General \n[Mon Jun  1 14:31:27 2026] usb 1-1: SerialNumber: \\xd0\\x89\n[Mon Jun  1 14:31:27 2026] usb-storage 1-1:1.0: USB Mass Storage device detected\n[Mon Jun  1 14:31:27 2026] scsi host3: usb-storage 1-1:1.0\n[Mon Jun  1 14:31:28 2026] scsi 3:0:0:0: Direct-Access    General  UDisk            5.00 PQ: 0 ANSI: 2\n[Mon Jun  1 14:31:28 2026] sd 3:0:0:0: Attached scsi generic sg3 type 0\n[Mon Jun  1 14:31:28 2026] sd 3:0:0:0: [sdd] 7884800 512-byte logical blocks: (4.04 GB/3.76 GiB)\n[Mon Jun  1 14:31:28 2026] sd 3:0:0:0: [sdd] Write Protect is off\n[Mon Jun  1 14:31:28 2026] sd 3:0:0:0: [sdd] Mode Sense: 0b 00 00 08\n[Mon Jun  1 14:31:28 2026] sd 3:0:0:0: [sdd] No Caching mode page found\n[Mon Jun  1 14:31:28 2026] sd 3:0:0:0: [sdd] Assuming drive cache: write through\n[Mon Jun  1 14:31:28 2026]  sdd: sdd1\n[Mon Jun  1 14:31:28 2026] sd 3:0:0:0: [sdd] Attached SCSI removable disk\n[Mon Jun  1 14:31:35 2026] EXT4-fs (sdd1): mounted filesystem eee300b2-f75e-4127-9574-1adfbfec7245 r/w with ordered data mode. Quota mode: none.\n[Mon Jun  1 14:35:01 2026] EXT4-fs (sda1): unmounting filesystem 7d84491f-1ebb-47f1-876f-8b3362d98e70.\n[Mon Jun  1 14:35:28 2026]  sda:\n[Mon Jun  1 14:35:28 2026]  sda:\n[Mon Jun  1 14:35:52 2026]  sda: sda1\n[Mon Jun  1 14:35:52 2026]  sda: sda1\n[Mon Jun  1 14:35:59 2026] EXT4-fs (sda1): mounted filesystem 7d84491f-1ebb-47f1-876f-8b3362d98e70 r/w with ordered data mode. Quota mode: none."

I can see the session log states that automount is disabled, but a Thunar window spontaneously opens and shows /run/media/linux/rootfs.  At about the same time the installer errors out.

Let me know if you want more information or to try anything.

[valtam]

You can zip the log, this will save space too.
I'm assuming this is the final ISO install attempt?
How did you partition?

[stevef]

log file attached as an archive
Yes, this is using USB flash drive created from the final release iso downloaded about 12 hours ago.
I didn't do any manual partitioning - just let the installer go ahead.  Four attempted installs have all failed in similar style.

The log is from the third attempt, erase disk option.
Noted the times shown when moving through the installation menu to aid reviewing the log.

14:33:14 clicked next after selecting language
14:33:37 clicked next after setting location
14:33:43 clicked next after setting keyboard
14:34:44 clicked next after completing user information
14:35:00 clicked install after selecting erase disk

[valtam]

Thanks Steve.

We may be able to isolate your particular issue with the following - run this in a terminal in the live session, before launching the installer (or after the failed attempt, before retrying).

Step 1 — Confirm the target disk first (critical)

Device letters can shift between boots, so verify /dev/sda is really the 240 GB WDC SSD and not the USB stick:

Code:

lsblk -o NAME,SIZE,MODEL,FSTYPE,MOUNTPOINT

You should see the WDC WDS240G2G0A, 223.6G as sda. The 14.5 GB iso9660 device is the install USB — do not touch that one.

Step 2 — Unmount and wipe (run as one block)

Code:

sudo umount /dev/sda1 2>/dev/null
sudo wipefs -a /dev/sda1
sudo wipefs -a /dev/sda
sudo dd if=/dev/zero of=/dev/sda bs=1M count=16 conv=fsync
sudo partprobe /dev/sda

What each line does:

- umount — releases the partition udisks2 auto-mounted at /run/media/linux/rootfs.
- wipefs -a /dev/sda1 — the important one: erases the old ext4 superblock inside the partition. This is what sfdisk was leaving behind for udisks2 to re-grab.
- wipefs -a /dev/sda — erases the partition-table signature.
- dd … count=16 — zeroes the first 16 MiB, killing any residual MBR/GPT and the start of the old filesystem for good measure.
- partprobe — tells the kernel to re-read the now-blank table so no stale sda1 lingers.
 
Step 3 — Install

Launch the installer and choose Erase disk. The drive is now genuinely blank, so the automounter has nothing to mount during the sfdisk → mkfs window, and the install will complete.

⚠️ This irreversibly erases everything on /dev/sda — fine here since they're doing a full Erase-disk install anyway, but worth saying to them plainly.

One caveat: if udisks2 is aggressive it could re-mount between the umount and the first wipefs. If wipefs -a /dev/sda1 complains the device is busy, have them just run the dd line directly (writing to the whole-disk /dev/sda works even while a partition is mounted), then partprobe — that alone defeats the race.

If this works, then we can provide a patch.

[valtam]

Addendum: If you have a faster, more modern pc to test an install on (not doing the above fix), that would be really good too.

[valtam]

I actually have for you a more streamlined test.

Load the Live ISO.

Code:

sudo apt-get updates && apt download calamares-settings-linuxlite

Code:

sudo dpkg -i ~/calamares-settings-linuxlite_8.0-0100-linuxlite.deb

Code:

sudo sed -i 's|^Exec=.*|Exec=/usr/libexec/linuxlite/calamares-prelaunch.sh|' /home/linux/Desktop/install-linuxlite.desktop

Double click the Install Linux Lite desktop icon.

Editing the icon (the above command) may trigger the "Untrusted application launcher" dialog — you must click "Mark As Secure And Launch."

Install + cross fingers.

FYI - this bug only occurs (no offence) on potato computers. We're past the stage of supporting very old computers by todays standards, this has nevertheless been an interesting technical puzzle - and I enjoy those, but at the same time, have to be smart about how much of any free time I get is spent fixing this type of problem.

It's nothing wrong with your PC — and your slower machine is actually exactly what helped us catch this.

The installer creates a partition and then formats it. There's a brief gap between those two steps, and the system's auto-mounter can sneak in and mount the new partition before the format runs — which makes the format fail. On a fast machine the format usually wins that race, so it never shows up. On a slower machine the auto-mounter gets there first, so the install fails.

So it's a timing issue, and your hardware just exposes it more reliably. The fix I'm sending disables the auto-mounter before the installer touches the disk, which removes the race entirely.

[stevef]

Addendum: If you have a faster, more modern pc to test an install on (not doing the above fix), that would be really good too.

Thanks for looking into this.  I do have a more modern test set up currently running 7.x and I want to try the series to series upgrade path on that.

FYI - this bug only occurs (no offence) on potato computers. We're past the stage of supporting very old computers by todays standards, this has nevertheless been an interesting technical puzzle - and I enjoy those, but at the same time, have to be smart about how much of any free time I get is spent fixing this type of problem.

It's nothing wrong with your PC — and your slower machine is actually exactly what helped us catch this.

No offence taken - I realise that the notebook should really be retired and was expecting that 7.x would be the last LL it would run.  But the installed version of 8.0 RC proved to be just about acceptable.  I thought we'd exposed the race condition during the RC test.

Setting a minimum hardware spec for an OS is hard and there are a lot of old computers out there.  The notebook is possibly representative of the lower spec machine that people switching from W10 might try LL 8.x on.  If the installer fails then they'll probably just try another distro.  From the forum support point of view I think it is worth doing this if only to be able to say 'don't bother' if anyone else tries and posts about the problem but if you think it is a dead end or a waste of time let me know.

Meanwhile I'll follow the instructions from post #6 and get back.

[valtam]

Cheers :) TBH, if post #6 works, then we'll bake that into 8.2, and I'll modify the 8.0 announcement with the pre-install fix.