Fixing a broken FDE (encrypted /boot) on (K)ubuntu 26.04

[Plecton]

Hello.

I have a longterm tradition to install linux desktops on encrypted root filesystems (/boot folder included). I have recently installed CachyOS in this manner, and it managed to create a working installation with proper encrypted rootfs using LUKS2/Argon2id (since GRUB v2.14 now supports LUKS2 and Argon2 PBKDF). I’ve been trying to install Kubuntu 26.04 LTS in a similar manner, and since it also uses the Calamares installer, I was under the impression that this was a supported feature. Apparently, it’s not.

These steps work on CachyOS, but result in a broken installation on Kubuntu 26.04:

• Boot into the installation image and run Calamares installer
• Proceed until asked for disk partition setup
• Choose manual partitioning
• Choose an empty drive, create a new GPT disk label
• Create new partition (size 512 MB), format it as fat32, label it “ESP”, enable the boot flag, set the mountpoint to “/boot/efi”
• Create new partition (rest of disk), format it as ext4, label it as “rootfs”, tick the “Encrypt” checkbox, provide a password, set mountpoint as “/”
• Proceed with installation
• (Kubuntu) If installation fails due to failed closing cryptmount, ignore it. System installed fine. For some reason the installer thinks it cannot close an already closed cryptomount.
• Reboot

Because the installed grub EFI binary does not include support for luks2 or argon2id, the system will fail to decrypt the LUKS2 volume and drop to a rescue shell instead. Looks like the developers forgot to include support for LUKS2/Argon2 in the signed grub EFI binary despite the fact that grub v2.14 now fully supports them. There is also evidence that they are even looking in the opposite direction (@Lantizia, did you solve your issue?), so it seems like (at least at the moment of this writing) we are somewhat out of luck.

The only other way is to use the unsigned binary and drop secure boot altogether (or perform custom SB configuration). The Kubuntu installer defaults to grub-efi-amd64-signed package, and I have not been able to find a way to have it switch to grub-efi-amd64-unsigned. I managed to partially fix my installation by chrooting into it from another system and manually fixing some things.

Make sure /usr/sbin is in PATH before executing any commands in the chroot environment. First I did a “rm -rf *” in the /boot/efi/EFI folder. Then, I installed grub-efi-amd64-unsigned package (you may need to fix the network before apt starts working - add a “nameserver 8.8.8.8” line at the top of /etc/resolv.conf file and save it). Running “grub-install --no-uefi-secure-boot” then seemingly installs the correct grubx64.efi binary with proper support for luks2/argon2id. I verified this by booting from it, and the password prompt now showed up and decrypted properly, but there are more problems. It seems I also had to fix the crypttab because it was missing the keyfile.

luks-<your-uuid-here> UUID=<your-uuid-here>     none luks,keyscript=/bin/cat

Replace the “none” keyword with “/crypto_keyfile.bin” in your /etc/crypttab, save, then “update-initramfs -u”. This will result in a bootable Kubuntu installation with encrypted /boot folder. I have however not been able to find a way to switch the system from using the signed grub image to the unsigned one. The system still defaults to the signed image. This means that the unsigned image will inevitably get overwritten by a package update the next time grub-install is executed. Trying to uninstall grub-efi-amd64-signed package fails because another package (shim-signed) apparently depends on it. Trying to uninstall shim-signed also fails because it is apparently an essential package that cannot be removed. There is also no easy way to install the system without a bootloader, so that it may be installed manually later on.

Basically, I’m stuck at this point and unsure how to proceed from here on.
Does anyone know how to make the system use unsigned grub binary by default?

[peterwhite23]

Welcome to the Ubuntu Discouse!

@Plecton

/boot folder included

That is unsupported by Ubuntu. See this for details and only comment on perceived security implications after having read it to the end.

Streamlining secure boot for 26.10

Ubuntu systems support secure boot using grub. grub contains a lot of parsers for file systems and other things which are a constant source of security issues. In 26.10, we’d like to propose removing the following features from signed GRUB builds: Filesystems for /boot Remove btrfs, hfsplus, xfs, zfs Retain ext4, fat, iso9660 (and squashfs for snaps) Image formats: Remove jpeg, png Retain none We do not use images, but using that in your grub.cfg locally is a massive security risk (if eve…

TL;DR: there is nothing worth hiding in /boot; it’s verifiable integrity (“verity”) you want there, not secrecy.

---

Because the installed grub EFI binary does not include support for luks2 or argon2id

I am pretty sure it still does support those things, because the actual streamlining hasn’t happened yet. It’s just that the installer will not set up GRUB for that, because of how the (still experimental) TPM-backed FDE option is implemented in the officially supported way. So, if you absolutely must have it that way, despite everything, you can make it work, just not with any help from the installer or this Discourse. But do keep in mind what is to come; the word “stranded” was used by the author of said announcement, IIRC; you connect the dots on who will be stranded where.

[iamthomasremy]

Hello there.

@Plecton

enable the boot flag

Not sure what you’re talking about here. GPT does not have a boot flag. Instead, you should use the EFI Partition type (UUID=c12a7328-f81f-11d2-ba4b-00a0c93ec93b).

@Plecton

I have a longterm tradition to install linux desktops on encrypted root filesystems (/boot folder included).

Set apart your longterm tradition, do you have a “good” reason for wanting to encrypt the /boot partition?

@Plecton

There is also no easy way to install the system without a bootloader, so that it may be installed manually later on.

Do you know if Calamares uses Curtin under the hood?

[Plecton]

I solved it. Now there is only the unsigned binary present whenever grub-install is executed.

sudo apt remove --allow-remove-essential grub-efi-amd64-signed shim-signed

[jerobarraco]

Hello.

Im having the same issue.

Even though im not trying to encrypt /boot

The installer fails and the system fails to boot if i try to encrypt the root partition.

It fails to unlock the device, even if i try to use the recovery option in grub.

Its extremely disappointing that the installer seems to not work at all in uefi with encryption.

I can replicate it 100%.

The partition manager for the installer doesnt offer the option to use luks (not luks2), though i’m not sure it will offer any improvement.

Im not sure how to fix it.

And unfortunately the installer fails at the very end. So the testing process is as annoying as it could be. And ive already formatted my system.

I dont understand why is so hard to use a custom partition layout with disk encryption. (Just btrfs for root and a swap partition). It seems like nobody even tested this flow.

I dont really know how to apply the solution in the previous post, and im not too comfortable leaving only unsigned binaries.

Found this https://codeberg.org/Calamares/calamares/issues/2517

After trying more than 5 times (which took around 2 hours).

Ive managed to install with an encrypted root, the installer succeeds, though in not the environment i want.

I was having an encrypted swap partition, when i used a non encrypted swap (which is a security risk), the installer finishes correctly.

It seems that if there’s just one extra luks volume (even in another disk), the installer fails. Which seems pretty bad to me.