Installer: wipe old filesystem signatures before creating the new one

[MTSistemi]

Installing over a disk that previously held an encrypted install produces a system that finishes installing and then does not boot: the first start drops into the initramfs BusyBox shell.

Reported by a tester on 26.06.5, reproduced here on 13/09/2026 and diagnosed.

It is not btrfs

Proven both ways on Proxmox, UEFI/OVMF, the published 26.06.5 Generic image, erase disk, btrfs:

• disk that had held LUKS -> installs, first boot drops to the initramfs shell
• brand-new empty disk, same image and same choices -> installs and boots to the login screen

What actually happens

Calamares wipes the disk and creates btrfs, but the old LUKS signature survives on the partition. From the initramfs shell:

blkid /dev/sda2        ->  TYPE="crypto_LUKS"  UUID=268d1904-...
btrfs filesystem show  ->  uuid: ead78e6c-...      (the real one)
cat /proc/cmdline      ->  root=UUID=ead78e6c-...  rootflags=subvol=@

The kernel command line is correct, the filesystem really has that UUID, and mount -t btrfs /dev/sda2 /m succeeds by hand with every subvolume in place (@ @cache @games @home @log @swap). But blkid sees the stale LUKS signature first, so udev never creates /dev/disk/by-uuid/<the btrfs uuid> and the initramfs waits for a device that will never appear.

The one-line check: ls /dev/disk/by-uuid/ lists the dead LUKS UUID and not the live btrfs one.

Fix

Wipe the signatures on the target partition before creating the filesystem, so this never reaches a user.

Workaround until then

From the live session, on the partition and not the whole disk:

sudo wipefs -a /dev/sda2

Or install to a disk that never held LUKS.

Note

This is probably the same family as the earlier "exit code 32 on reinstall" report: leftovers from the previous install that the new one does not clear. It is only hit by people who install repeatedly on the same disk, which is exactly what testers do.

[MTSistemi]

Fix committed in e83839b; it ships with the next ISO.

A new installer step, shellprocess@wipestale, runs right after mount, outside the target, in both the live-build and the eggs Calamares branch. For every partition mounted under the installer's target, it checks whether crypto_LUKS sits next to another signature. If it does, it erases only the crypto_LUKS one (wipefs -t crypto_LUKS). Encrypted installs are left alone: their raw partition carries a single signature, and the /dev/mapper device is skipped. The step never fails the installation. The script, skillfish-wipe-stale-luks, is already in skillfish-base 26.09.43, so the live session of the next image has it.

Tested with loop devices, reproducing the state described above: a btrfs with the old LUKS header in its first 4 KiB. Before the step, /dev/disk/by-uuid/ had no link for the btrfs UUID. That's the symptom that stopped the boot. After it, the link is there, btrfs check is clean and the data is intact.

I'm keeping this open until the fix has been exercised inside a real installation from a new image. Until then, the workaround above still applies: sudo wipefs -a /dev/sdX2 from the live session.