- Proposed Configuration: A February 2026 Ubuntu Discourse proposal outlines plans to strip support for btrfs, xfs, zfs, hfsplus, LVM, LUKS, and image rendering from signed GRUB bootloaders.
- Security Justification: The initiative aims to reduce the attack surface of the bootloader, which has recorded over 60 potential vulnerabilities since 2020.
- Lack Of Exploitation: None of the identified vulnerabilities for GRUB currently appear in the CISA Known Exploited Vulnerabilities catalog.
- Operational Impact: Removing support for encryption mechanisms like LUKS would force /boot partitions to remain unencrypted, potentially exposing kernels to tampering.
- Developmental Patterns: The proposal reflects a five-year trend of removing legacy features and specific boot functionalities from the Ubuntu software ecosystem.
- Historical Context: The lead engineer previously authored a tool named sicherboot in 2016, which functioned as a GRUB replacement using systemd-boot.
- Systemic Conflict: Changes to the bootloader requirements conflict with established Ubuntu Server defaults, such as the standard use of LVM.
- Implementation Path: The proposed update would effectively mandate that /boot partitions use a raw ext4 filesystem to maintain compatibility with Secure Boot.
The Proposal
6 Filesystems Cut
[
Klode wants to strip btrfs, xfs, zfs, hfsplus, JPEG, and PNG from signed GRUB for Ubuntu 26.10.
](https://discourse.ubuntu.com/t/streamlining-secure-boot-for-26-10/79069?ref=sambent.com)
The Engineer
APT Lead Developer
[
Julian Klode controls APT, the package manager for every Debian and Ubuntu system, plus the Secure Boot signing pipeline.
](https://wiki.ubuntu.com/JulianAndresKlode?ref=sambent.com)
The History
sicherboot (2016)
[
Klode built a GRUB replacement using systemd-boot a full decade before proposing to gut GRUB.
](https://github.com/julian-klode/sicherboot?ref=sambent.com)
The Pattern
5 Years of Cuts
[
os-prober disabled (2021), GRUB targets dropped (2023), Rust forced on APT (2025), GRUB stripped (2026).
](https://lists.ubuntu.com/archives/ubuntu-devel/2021-December/041769.html?ref=sambent.com)
CVE Data
60+ Vulnerabilities
[
GRUB's filesystem parsers produced 60+ CVEs since 2020, including 8.8 HIGH in HFS. The attack surface is real.
](https://nvd.nist.gov/vuln/detail/CVE-2024-56737?ref=sambent.com)
The Catch
Zero Exploited in Wild
[
None of those 60+ CVEs appear in CISA's Known Exploited Vulnerabilities catalog.
](https://www.cisa.gov/known-exploited-vulnerabilities-catalog?ref=sambent.com)
The Cost
Unencrypted /boot
[
Removing LUKS means boot partitions sit unencrypted, vulnerable to kernel tampering and bootkit injection.
](https://discourse.ubuntu.com/t/streamlining-secure-boot-for-26-10/79069?ref=sambent.com)
Canonical
Same Pattern, New Cut
[
Snap forcing, Amazon spyware, terminal ads, age verification, and now boot stripping. Canonical keeps reducing what your system can do.
](https://www.sambent.com/the-engineer-who-tried-to-put-age-verification-into-linux-5/)
On March 25th, 2026, a Canonical engineer named Julian Andres Klode posted a proposal to the Ubuntu Discourse titled "Streamlining secure boot for 26.10" that would strip support for btrfs, xfs, zfs, hfsplus, JPEG, PNG, LVM, and LUKS-encrypted disks from Ubuntu's signed GRUB bootloader builds. The practical consequence is that every Ubuntu system running 26.10 or later would need its `/boot` partition on a raw ext4 filesystem, unencrypted, on a GPT or MBR disk, or it simply will fail to boot with Secure Boot enabled.
Listen to this article
0:00 --:--
Failed to load audio
This is a demolition project, it's been running for five years now.
Julian Klode is the lead developer of APT, the package manager that powers every Debian and Ubuntu system on the planet. He's been a Debian Developer since October 2008 and an Ubuntu Core Developer since July 2016. He was promoted to Senior Engineer at Canonical in November 2025, four months before dropping this proposal. He manages the entire shim/GRUB/kernel signing pipeline for Ubuntu's Secure Boot infrastructure, meaning he controls the keys that decide what your computer is allowed to run at boot time.
And in 2016, a full decade before this proposal, he built a tool called sicherboot that replaced GRUB with systemd-boot and handled Secure Boot signing automatically. "Sicher" is German for "secure." He archived it in January 2023 and recommended users switch to sbctl instead, but the intent was clear a decade ago: he wanted GRUB gone.
CLICK TO REPLAY
In December 2021, Klode disabled os-prober in GRUB 2.06, which broke automatic dual-boot detection for millions of Ubuntu users who also run Windows or other Linux distributions. His exact words on the mailing list were that the outcome was "obviously a bit controversial and not necessarily in the best interest of our users," and he did it anyway because os-prober mounts all partitions on your disk using grub-mount, which he called a security risk.
In October 2023, he proposed dropping grub-coreboot, grub-efi-ia32, grub-xen, grub-uboot, and grub-firmware-qemu from Ubuntu, claiming "we believe nobody uses them." Steve Langasek pushed back, pointing out that removal requires demonstrating actual maintenance burden. In the same email, Klode floated killing BIOS support entirely, calling it "a risky platform."
In October 2025, he announced a hard Rust dependency for APT starting May 2026, effectively threatening four Debian architectures that lacked Rust toolchain support: DEC Alpha, HP PA-RISC, Motorola 680x0, and Hitachi SH4. He closed with "thank you for understanding," which is corporate shorthand for "the discussion is over." John Paul Adrian Glaubitz called his wording "unpleasant" and "confrontational."
And now, March 2026, the biggest cut yet: remove six filesystem drivers, all image rendering, LVM, and LUKS from signed GRUB. His own words in the proposal: "We understand these are controversial options; however we believe they'd substantial [sic] improve security, but also simply pivoting to new boot solutions in the future."
Someone will point out that Fedora and other distributions are also moving toward systemd-boot. True. The difference is that Fedora offers it as an option alongside a fully functional GRUB. Klode is gutting GRUB's functionality so aggressively that switching becomes the only viable path. There's a canyon between offering an alternative and burning down the incumbent so the alternative wins by default.
That last phrase is the tell. "Pivoting to new boot solutions in the future" means systemd-boot or Unified Kernel Images, and Klode has been building toward this since sicherboot in 2016. Every removal makes GRUB less functional, and eventually replacing it becomes the path of least resistance, which is exactly how you boil a frog when you also happen to control the signing keys.
And before anyone says I'm attributing malice where there's only engineering pragmatism: pragmatism doesn't require a decade of groundwork. One bad decision is a judgment call. Five decisions over five years, all moving in the same direction, all made by the same person who built the replacement tool in 2016 and controls the signing keys in 2026, that is a trajectory. I'm reading the commit history, not his mind.
Ok so the security argument has real teeth.
The NVD CVE database contains over 60 GRUB-related vulnerabilities across 2020-2025. The BootHole bug (CVE-2020-10713) was a buffer overflow in GRUB's config parser that allowed arbitrary code execution and Secure Boot bypass. Since then, GRUB's filesystem parsers have been an assembly line of heap buffer overflows: CVE-2024-56737 in HFS scored 8.8 HIGH, CVE-2025-0678 in SquashFS scored 7.8 HIGH, and the 2025 batch alone found heap overwrite bugs in seven different filesystem drivers (UFS, SquashFS, ReiserFS, JFS, RomFS, UDF, and HFS). These are all the same bug class, integer overflows leading to heap corruption, repeating in the same C codepaths year after year because GRUB's parser code was written without bounds checking.
CLICK TO REPLAY
From what I found, the filesystem attack surface is genuinely massive and continuously producing new vulnerabilities even in GRUB 2.12, the current release. Klode has a point about reducing attack surface.
But look at which modules are actually being cut and which ones are being kept. btrfs has zero CVEs. XFS has zero CVEs. ZFS has zero CVEs. All three are marked for removal. Meanwhile SquashFS, which has two CVEs including a 7.8 HIGH, gets to stay. The aggregate number of 60+ GRUB vulnerabilities sounds terrifying until you look at the actual modules on the chopping block and realize the ones users depend on have cleaner security records than the ones being retained. He's using the total to justify removing things that have no vulnerability history.
CLICK TO REPLAY
But his solution creates a bigger problem than the one it solves, and the community identified it within hours.
Removing LUKS support from GRUB means your /boot partition sits unencrypted on disk. An attacker with physical access, or malware with root privileges, can modify kernel parameters, swap initramfs images, or inject persistent bootkits without breaking any cryptographic seal. As one Discourse commenter named peb pointed out, removing encryption from the boot chain breaks the chain of trust that Secure Boot claims to protect. You harden the bootloader by making the thing it loads completely defenseless. Zero GRUB vulnerabilities appear in CISA's Known Exploited Vulnerabilities catalog, meaning every single one of those 60+ CVEs is theoretical. The attack surface exists on paper while the protection being removed, encrypted boot partitions, stops real attacks against production infrastructure right now.
User mlocik97 called it "absurd" and compared it to "improving security of planes by forbidding them to fly." DClauzel from France pointed out that encrypted `/boot` is mandatory in regulated European environments, and Klode lives in Marburg, Germany. Multiple users noted that Ubuntu 24.04 Server defaults to LVM during installation, meaning Canonical's own recommended server configuration would be incompatible with their own proposed boot requirements two releases later.
The obvious defense is that Ubuntu Server's LVM defaults and Klode's GRUB proposal come from different teams. That makes it worse. Either Canonical's internal teams have zero coordination and the left hand is stripping features the right hand depends on, or they coordinated and the server team gets overruled by the boot team anyway. Both answers are damning, and neither one helps the sysadmin whose 3 AM pager just went off.
And the migration path Klode offers is brutal: restructure your disk layout, disable Secure Boot, or stay on 26.04 LTS forever. For enterprise deployments running hundreds or thousands of Ubuntu servers with LUKS-encrypted boot partitions, "restructure your disk layout" is a euphemism for "rebuild your entire infrastructure."
CLICK TO REPLAY
Klode's own blog reveals a philosophical contradiction. His APT solver, solver3, is explicitly designed to "always keep manually installed packages around, it never offers to remove them." His 2025 post on sound removals argues that "the solution to remove A rather than upgrade it would still be wrong" when upgrading would resolve the conflict. He built a package manager that protects user choices and then built a boot infrastructure that overrides them.
And his 2021 post on migrating away from apt-key contains this gem: the "security increase is minimal, since package maintainer scripts run as root anyway." Klode treats security pragmatically when it comes to package signing, but treats the boot chain as sacred ground where user capabilities get sacrificed. The inconsistency is either dishonest or convenient, and both options lead to the same place.
CLICK TO REPLAY
This is the same Canonical that forced Snap packages on users by silently routing `apt install chromium-browser` through their proprietary store, the same Canonical that piped desktop searches to Amazon without consent and then tried to silence the critic who built a fix with trademark threats, the same Canonical whose VP of Engineering Jon Seager already distanced the company from one controversial proposal this month when a developer tried to put age verification into the Ubuntu installer.
CLICK TO REPLAY
The pattern is consistent, and it runs across multiple Canonical engineers operating in the same direction: reduce what your system can do and route the escape hatch through something Canonical controls. Dylan Taylor wanted to collect your birthday and Julian Klode wants to control which filesystems you boot from, and they both wrapped it in compliance language while generating immediate community backlash that Canonical has yet to meaningfully address.
CLICK TO REPLAY
The inevitable response is that I'm 'harassing' an open source developer for doing his job. Every single source in this article is a public mailing list post, a public Git commit, a public Discourse proposal, or Klode's own public blog. He's a Senior Engineer at a company that controls Ubuntu's boot infrastructure for millions of machines worldwide. He posted this proposal publicly and invited feedback. Public accountability for public proposals affecting public infrastructure is called journalism. If the argument against scrutiny is that the person making sweeping changes to how your computer boots deserves to do it in silence, then the argument is that you don't deserve to know what's happening to your system.
Klode's proposal remains just a proposal, and the Discourse thread is actively hostile to it. But Klode controls the signing pipeline, manages the shim and GRUB packaging and the kernel trust chain, and he has the keys, and he's been removing capabilities from GRUB for five years in a trajectory that points at exactly one destination: replacing it with the tool he built in 2016.
Phoronix covered it today. Hacker News is discussing it. The community is paying attention. Whether Canonical's leadership treats this like the os-prober incident, where the removal went through despite objections, or like the 32-bit library removal, where Valve threatening to drop Ubuntu support forced a reversal, depends entirely on whether anyone with enough market leverage cares about their boot partition.
My guess is that most Ubuntu users will find out what happened after the update breaks their server at 3 AM.
Ubuntu GRUB Stripping Proposal Quiz
Test your understanding of Canonical's controversial boot security changes
Progress 0/10 answered
Question 1
What did Julian Klode propose removing from Ubuntu's signed GRUB builds for 26.10?
Only JPEG and PNG image support
btrfs, xfs, zfs, hfsplus, JPEG, PNG, LVM, and LUKS support
All filesystem drivers except FAT
Only legacy BIOS boot support
Question 2
What tool did Klode build in 2016 that replaced GRUB with systemd-boot?
grub-alternative
bootctl
sicherboot
shim-manager
Question 3
What does "sicher" mean in German?
Simple
Boot
Fast
Secure
Question 4
What did Klode disable in GRUB 2.06 in December 2021?
Secure Boot verification
LUKS encryption support
os-prober (dual-boot detection)
UEFI firmware updates
Question 5
How many GRUB-related CVEs were found between 2020 and 2025?
12
Around 30
Over 60
Over 200
Question 6
What severity score did CVE-2024-56737 receive for GRUB's HFS filesystem driver?
5.3 MEDIUM
6.7 MEDIUM
7.8 HIGH
8.8 HIGH
Question 7
How many GRUB CVEs appear in CISA's Known Exploited Vulnerabilities catalog?
3
12
1 (BootHole only)
Zero
Question 8
Under Klode's proposal, what filesystem must /boot use?
Any Linux-native filesystem
btrfs or ext4
ext4 only
FAT32
Question 9
What phrase in Klode's proposal hints at replacing GRUB entirely?
"reducing the attack surface"
"pivoting to new boot solutions in the future"
"streamlining the boot process"
"improving security posture"
Question 10
Which Canonical executive distanced the company from the age verification proposal earlier in March 2026?
Mark Shuttleworth, CEO
Jon Seager, VP of Engineering
Steve Langasek, Release Manager
Julian Klode, Senior Engineer
0/10
Your Score
0
Correct
0
Incorrect
0
Unanswered

Opinion | Chuck Norris Is Still Undefeated
Opinion | To Bury, Not to Praise
Opinion | Will the Real James Fishback Please Stand Up?
About Free Expression