Public bug reported: **Summary**
I installed Kubuntu 26.04.1 on a 32 GB USB drive using automatic partitioning with encryption enabled. During boot, the initramfs rejected the correct passphrase. The generated crypttab entry had no `luks` option. Adding it and rebuilding the initramfs fixed the boot. I am reporting this against Ubuntu's calamares package because the installer generates the entry. The interaction with cryptsetup-initramfs may also need investigation; I have not established why LUKS autodetection failed. **Release and installer packages** Installation was on an MSI B550-A PRO desktop, in 64-bit UEFI mode. The USB installation was then booted on a Lenovo laptop. Installer: `Kubuntu 26.04.1 LTS "Resolute Raccoon" - Release amd64 (20260826.1)` Packages read directly from the installer's SquashFS image: ```text calamares 3.3.14-0ubuntu25 calamares-settings-kubuntu 1:26.04.12 calamares-settings-ubuntu-common 1:26.04.12 cryptsetup-initramfs 2:2.8.4-1ubuntu4 initramfs-tools 0.151ubuntu1 ``` The target was a Transcend USB drive with approximately 29.4 GiB capacity. Calamares created this GPT layout: - 300 MiB FAT32 EFI system partition. - 4 GiB unencrypted ext4 mounted at `/boot`. - About 25.1 GiB LUKS2 containing ext4 mounted at `/`. - No swap partition. **Steps to reproduce** 1. Boot the Kubuntu installer in UEFI mode. 2. Select minimal installation. 3. Select erase disk and enable encryption, producing the layout above. 4. Complete the installation and boot the installed system. 5. Enter the correct passphrase at the initramfs unlock prompt. **Actual result** The installed system failed to boot after passphrase entry, with: ```text unknown fstype, bad password or options? ``` **Expected behavior** The installed system should unlock the LUKS root filesystem and boot with the correct passphrase, without manually editing crypttab or rebuilding the initramfs. **Available evidence and missing logs** I do not have the original Calamares installation log or a boot trace showing why LUKS autodetection failed. The package versions above were recovered from the installer image; the current cryptsetup version in the installed system has not been checked. The error message and configuration below were recorded during troubleshooting. **Configuration and successful workaround** The installed `/etc/crypttab` contained this entry, without fourth- column options. The same entry was present in `cryptroot/crypttab` inside the original initramfs: ```text luks-<uuid> UUID=<uuid> none ``` From another Linux system, `cryptsetup open --test-passphrase` accepted the same passphrase and returned exit status 0. Opening the container read-only exposed the expected ext4 filesystem. I changed the crypttab entry to: ```text luks-<uuid> UUID=<uuid> none luks ``` I then rebuilt the initramfs for `7.0.0-38-generic` in the installed system's chroot and verified that it contained the corrected entry. The USB installation then booted successfully. No change to the passphrase, LUKS header or filesystem was needed. **Source investigation** In [`src/modules/fstab/main.py`](https://codeberg.org/Calamares/calamares/src/commit/d62849a39a97dbcd4bd9389ebc38e9643a81fa86/src/modules/fstab/main.py), `generate_crypttab_line_info()` sets `password = "none"` and `crypttab_options = ""` when processing the encrypted root entry and a separate `/boot` entry has no `luksMapperName`. This is the branch matching this installation. It removes `luks` along with the keyscript options. The function also clears options in a separate branch for layouts with an unencrypted root; that branch does not apply here. The attached `repro_crypttab.py` runs that method with synthetic partitions. For this layout, both `luks` and `luks,keyscript=/bin/cat` as input produce an empty options field. With `/boot` inside root or separately encrypted, the options are retained. I checked this against the actual module on the installer USB, upstream v3.3.14, v3.4.3 and commit `d62849a39a97dbcd4bd9389ebc38e9643a81fa86`. All produced the same result. This check only runs the configuration method; it does not repeat the installation. Ubuntu's cryptsetup scripts attempt LUKS autodetection when the explicit option is absent and fall back to `plain` if detection fails. Why that detection failed here remains unknown. Restoring the explicit option resolved the observed boot failure. A [Kubuntu 24.04 report from September 2025](https://askubuntu.com/questions/1555639/kubuntu-24-04-wont- immediately-accept-password-after-being-installed-with-disk) describes the same partition layout and workaround. ** Affects: calamares (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2172138 Title: Kubuntu 26.04.1 encrypted installation fails to boot; adding luks to crypttab fixes it To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/calamares/+bug/2172138/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
