Ubuntu engineers are debating ways to reduce the number of features present in the signed version of GRUB, the boot loader used on systems with Secure Boot enabled.
Canonical engineer Julian Klode proposes dropping support for /boot on btrfs, HFS+, XFS and ZFS filesystems, alongside GRUB’s JPEG and PNG image parsers, ahead of Ubuntu 26.10.
Apple partition table support, LVM volume handling, all software RAID except RAID 1 and, more controversially, LUKS-encrypted /boot partitions are also on the chopping block.
Many of these features are said to be ‘inherited by Debian, but never tested in Ubuntu’.
“The timing here is crucial”, Klode says, adding that “by performing the changes directly after an LTS, we can keep affected users on an LTS release with support for 10 years, rather than an interim release with 9 months of support”.
The emphasis on ‘affected’ is mine, as it’s the most important point: only those who use Secure Boot or installed Ubuntu with a ‘complex’ boot setup not provided by the OS installer would be blocked from upgrading to Ubuntu 26.10.
Security is the main motivator
GRUB (GRand Unified Bootloader) is the black screen with white monospaced text you see when you start up a computer that runs Linux (and most Linux distributions use GRUB). It lets you select an operating system, chained bootloader or other feature you want to use…
Which is the problem.
GRUB runs before Linux does, so lacks the protections included in Linux operating systems. A bug in any component GRUB has, even if Ubuntu doesn’t use it, could potentially be exploited by an attacker – e.g., CVE-2024-45774, a vulnerability in GRUB’s JPEG parser.
But is the drama and fear around this proposal valid?
The majority of people who install Ubuntu do so using the stable OOTB options present in the OS installer. If you installed Ubuntu with full disk encryption (FDE) on ext4, your setup is unlikely to be affected.
Canonical engineer Máté Kukri has clarified this, stating that the distro is “not removing any kind of FDE support […] whatsoever”.
But if you manually created a LUKS-encrypted /boot, placed it on a ZFS or btrfs filesystem, or configured a non-RAID-1 software RAID (as some experienced Ubuntu users choose to do), this proposal would leave you unable to upgrade to Ubuntu 26.10.
Ubuntu Technical Board member Thomas Ward points out that the distro’s server installer sets up LVM by default, and that LUKS encryption on Ubuntu currently requires LVM. Some official system configurations could be caught out by the same restrictions.
Klode’s case for removing LUKS from /boot (that it offers “security by obscurity, but not actual security”) has drawn heat from users, while the need for other removals has been questioned (btrfs and XFS have no GRUB CVEs, but squashfs, staying put, has).
Proposals
Security is a noble aim, and measured, reasonable feedback will shape how this proposal moves forward in the coming months. Some users are concerned, but not all of Canonical’s engineers are convinced by the rationale, asking for further clarification.
It’s unclear if blocking upgrades from 26.04 LTS to 26.10 for complex setups will create much of an impact. Ubuntu 28.04 LTS is likely to be the release most 26.04 LTS users will want to upgrade to. 2 years away gives time for the proposals to bed in.
After all, the point of interim releases is to trial and test substantive changes, to allow time for discussion, feedback and refinement – in the worst case scenario, a rollback.