Canonical has proposed a major change to Secure Boot in Ubuntu 26.10, aiming to reduce the GRUB bootloader’s feature set in signed configurations.
The proposal titled “Streamlining secure boot for 26.10“, published on Ubuntu’s Discourse by Canonical engineer Julian Klode, recommends providing a minimal GRUB build for Secure Boot systems in order to reduce the code executed in the privileged pre-boot environment.
The proposed signed GRUB for Secure Boot would remove support for features such as LUKS disk encryption, LVM, most md-raid modes, ZFS, Btrfs, and various filesystem and image parsing capabilities. Systems would be expected to boot from a simpler layout, typically a plain ext4 /boot partition on GPT or MBR.
According to Canonical, it’s all for security. GRUB parses filesystems, disk formats, and other structures before the operating system loads. Each supported format increases the attack surface, so reducing this scope is intended to lower the risk of vulnerabilities in the Secure Boot chain.
These features would remain available on systems that do not use Secure Boot or use unsigned GRUB builds. However, those configurations would not benefit from Secure Boot protections.
And now it gets interesting. Systems relying on unsupported features in the Secure Boot path would be unable to upgrade to Ubuntu 26.10 using the standard release upgrader. Canonical states these systems would remain on Ubuntu 26.04 LTS unless reconfigured.
As expected, the proposal has raised significant concern in community discussions. Many Ubuntu installations, especially on servers, rely on encrypted volumes with LVM. Users note that removing support in the Secure Boot path would require changes to established deployment models.
ZFS and Btrfs users also express similar concerns. These filesystems are often used for snapshot-based workflows or advanced storage configurations. Requiring a separate ext4 /boot partition alters how these systems are structured and maintained.
Upgrade disruption is another major issue. Blocking upgrades for affected systems leaves users with few options, such as reinstalling, reconfiguring storage layouts, or disabling Secure Boot.
Last but not least, questions remain about RAID support, especially the scope of md-raid functionality to be retained. In light of this, some aspects of the proposal are unclear about how mirrored boot setups would function under the new model.
And to complete the picture, the proposal also removes support for image formats such as PNG and JPEG in signed GRUB builds, used to render GRUB themes, including background images, icons, and other visual elements in the boot menu. Canonical argues that keeping image decoding code in the Secure Boot path adds unnecessary attack surface.
At this stage, the change is still a proposal for Ubuntu 26.10. No final implementation details or decisions have been announced. Given the scope of the proposed changes and the community response, the discussion is expected to continue as Canonical refines its approach.
