Summary
A UEFI automated install with encryption completes successfully, but the installed system cannot unlock its LUKS root and drops to an initramfs rescue shell at boot. The crypttab is written to the target but never baked into the initramfs.
Affected path
GUI "Automated Installation — erase a disk and install" with "Encrypt the filesystem" enabled (check_encrypt → setup.luks), on UEFI firmware. live-installer currently ships on LMDE, so this reproduces on LMDE 7. Plain and LVM-without-encryption installs are unaffected.
Reproduction (LMDE 7, OVMF/QEMU)
The installed system boots to:
Gave up waiting for root file system device.
ALERT! /dev/mapper/lvmmint-root does not exist. Dropping to a shell!
BusyBox ... (initramfs)
There is no unlock prompt; the encrypted root never appears. A BIOS install of the same layout booted in testing (the copied live initrd happens to unlock from the kernel cmdline), so the failure is firmware-dependent and reproduces on UEFI.
Root cause
The target is copied from the live squashfs, so it inherits live-boot's diverted update-initramfs — a wrapper that no-ops unless the live medium is mounted at /run/live/medium inside the chroot. finish_installation() bind-mounts /run non-recursively (mount --bind /run/ /target/run/), so that submount is absent in the chroot and the update-initramfs -t -u -k all call is silently skipped. write_crypttab() still writes the LUKS entry, but with no rebuild the cryptsetup initramfs hook never bakes /conf/conf.d/cryptroot into the image.
Found while developing #180. Fix in the linked PR.
Note
The fix covers the GUI/automated encrypt path that sets setup.luks. The manual-partition (skip_mount) path, where a user sets up their own dm-crypt, still hits the no-op'd update-initramfs; that residual gap is out of scope here.
Summary
A UEFI automated install with encryption completes successfully, but the installed system cannot unlock its LUKS root and drops to an initramfs rescue shell at boot. The crypttab is written to the target but never baked into the initramfs.
Affected path
GUI "Automated Installation — erase a disk and install" with "Encrypt the filesystem" enabled (
check_encrypt→setup.luks), on UEFI firmware. live-installer currently ships on LMDE, so this reproduces on LMDE 7. Plain and LVM-without-encryption installs are unaffected.Reproduction (LMDE 7, OVMF/QEMU)
The installed system boots to:
There is no unlock prompt; the encrypted root never appears. A BIOS install of the same layout booted in testing (the copied live initrd happens to unlock from the kernel cmdline), so the failure is firmware-dependent and reproduces on UEFI.
Root cause
The target is copied from the live squashfs, so it inherits live-boot's diverted
update-initramfs— a wrapper that no-ops unless the live medium is mounted at/run/live/mediuminside the chroot.finish_installation()bind-mounts/runnon-recursively (mount --bind /run/ /target/run/), so that submount is absent in the chroot and theupdate-initramfs -t -u -k allcall is silently skipped.write_crypttab()still writes the LUKS entry, but with no rebuild the cryptsetup initramfs hook never bakes/conf/conf.d/cryptrootinto the image.Found while developing #180. Fix in the linked PR.
Note
The fix covers the GUI/automated encrypt path that sets
setup.luks. The manual-partition (skip_mount) path, where a user sets up their own dm-crypt, still hits the no-op'dupdate-initramfs; that residual gap is out of scope here.