Canonical stripped LUKS and LVM out of Ubuntu's GRUB Secure Boot binary. Their own installer defaults to LVM.

Ubuntu 26.10 ships October 15. One week. Buried in the release notes: the signed GRUB binary for Secure Boot no longer supports LUKS on /boot, LVM, most md-raid, btrfs, XFS, or ZFS as the boot filesystem. The slimmed-down build keeps ext4, FAT, ISO9660, and squashfs. That is it.

Canonical’s server installer defaults to LVM. It has for years. A fresh Ubuntu Server install, following Canonical’s recommended setup, will not qualify for Secure Boot on 26.10. A Ubuntu Technical Board member noted this in the Discourse thread. Nobody has a clean answer to it yet.

Before calling this insane, let me explain why they did it.

GRUB’s attack surface is genuinely large

GRUB’s Secure Boot binary reads filesystems, LVM metadata, LUKS headers, RAID superblocks, and a dozen partition table formats, all before the OS loads, all inside the Secure Boot trust boundary. Every one of those parsers is an attack surface.

BootHole (CVE-2020-10713) was a buffer overflow in GRUB2’s command-line parser. Fixing it required a new shim, a new GRUB, a new kernel, and a coordinated revocation across every major Linux distro. Three or four follow-on CVEs chased it for another two years after that. The code that runs before your OS cannot be hot-patched. The only way to reduce CVE exposure in that environment is to ship less code.

Julian Klode’s proposal is architecturally correct. A minimal GRUB binary has a minimal attack surface. A bootloader that reads ext4 and nothing else cannot be exploited through a LUKS header parser.

The LUKS on /boot pattern was always a workaround

A lot of Ubuntu users have LUKS-encrypted /boot because that is what tutorials recommended for full-disk encryption before TPM2 enrollment was straightforward. The pattern made sense in 2016. In 2026, it is a workaround for a problem that has a better solution.

The better solution is TPM2-based LUKS2 unlock via systemd-cryptenroll:

systemd-cryptenroll --tpm2-device=auto --tpm2-pcrs=7 /dev/sdaX

When the TPM is enrolled, GRUB never touches the LUKS container. GRUB reads an unencrypted /boot (ext4), loads the kernel and initrd, and hands off. The initrd calls systemd-cryptsetup, which asks the TPM to unseal the volume key against the measured boot state. No passphrase prompt at boot. No GRUB-level LUKS parser.

PCR 7 binds the key to the Secure Boot policy. If someone swaps a signed shim or GRUB binary that changes the measured policy, the TPM refuses to unseal. The threat model is better than GRUB-level LUKS: the key is bound to a measured boot state, not to a passphrase that a sufficiently privileged attacker could extract from memory.

The execution is the problem

Architecturally correct and “does not break your existing setup” are not the same thing.

Systems running LUKS-encrypted /boot or LVM-based /boot with Secure Boot enabled cannot upgrade to 26.10 through the standard release upgrader. Canonical’s stated position is that those systems stay on 26.04 LTS unless reconfigured. 26.04 LTS support runs until 2029, so this is not an emergency, but it is a forced migration deadline with no clear tooling.

Canonical should have shipped a migration utility. At minimum, the upgrade path should present a clear blocker message explaining what to reconfigure and how, not a silent upgrade failure. As of early October, the migration documentation is thin.

If you are running Ubuntu with LVM or LUKS on /boot and Secure Boot enabled, do not upgrade to 26.10 until Canonical publishes a migration path. The current guidance is essentially “read the Discourse thread and figure it out yourself.”

If you are setting up a new system, skip the old patterns. LUKS2 on the data partitions, plain ext4 on /boot, TPM2 enrollment via systemd-cryptenroll. GRUB stays minimal. Secure Boot stays honest. The threat model improves.

One week out

Last month’s PKfail story showed what happens when Secure Boot’s trust chain is treated as a checkbox: hundreds of device models still booting on a compromised Platform Key two years after disclosure. Canonical cutting GRUB’s parser surface is movement in the correct direction. Whether the rollout damages user trust enough to undo that benefit is the open question.

Ubuntu 26.10 has had a busy cycle. The Rust coreutils migration was a clean execution of a major change. This one is messier. The principle is right. The execution leaves a lot of users holding an LVM install and no clear path forward.