> ## Content Index > Fetch the complete content index at: https://itsfoss.com/llms.txt > Use this file to discover other available public pages before exploring further. # Why Ubuntu 26.10 Might Drop ZFS, RAID & Encryption Support From Grub - URL: https://itsfoss.com/news/ubuntu-26-10-grub-overhaul/ - Published: 2026-03-27T11:55:30.000Z - Updated: 2026-03-31T01:43:11.000Z - Description: The proposal calls for stripping out filesystem drivers and other features. - Author: Sourav Rudra - Tags: News, #publish-date Canonical engineer [Julian Andres Klode](https://github.com/julian-klode?ref=itsfoss.com), who works on Ubuntu's secure boot signing, has put forward a proposal on Ubuntu's [community forums](https://discourse.ubuntu.com/t/streamlining-secure-boot-for-26-10/79069?ref=itsfoss.com) to significantly cut down the [GRUB](https://www.gnu.org/software/grub/?ref=itsfoss.com) bootloader for the upcoming Ubuntu 26.10. The proposal takes aim at GRUB's parsers, which Julian describes as a "*constant source of security issues*," and proposes cutting a number of features from signed builds to reduce the attack surface in the pre-boot environment. ![a cropped screenshot of a post by julian andres klode on ubuntu's discourse forum that lays out a proposal to remove certain features from grub on ubuntu 26.10](https://itsfoss.com/content/images/2026/03/ubuntu-26-10-grub-features-removal-proposal.png) **What is meant to get the axe?** On the filesystem side, Btrfs, HFS+, XFS, and ZFS would all be dropped, leaving only ext4, FAT, ISO 9660, and SquashFS for [Snaps](https://snapcraft.io/about?ref=itsfoss.com). Image support would go too, alongside the Apple partition table, LVM, most md-RAID modes (*RAID1 is retained*), and LUKS-encrypted disks. In practice, that means Ubuntu 26.10 systems running [Secure Boot](https://learn.microsoft.com/en-us/windows-hardware/design/device-experiences/oem-secure-boot?ref=itsfoss.com) would need to boot from a plain, unencrypted ext4 partition on a GPT or MBR disk. No ZFS, no Btrfs, no encrypted `/boot`. **Those features would still be available through unsigned GRUB builds, but you'd lose Secure Boot entirely in exchange.** **He pitches this as a meaningful security improvement** and also as a step toward eventually moving to newer boot solutions down the line. Now, here's the catch. If your current setup relied on any of the features being dropped, the [release upgrader](https://launchpad.net/ubuntu/+source/ubuntu-release-upgrader?ref=itsfoss.com) would block you from moving to Ubuntu 26.10 at all. Those systems would stay on [26.04 LTS](https://itsfoss.com/ubuntu-26-04-release-features/) by default. ## There's resistance [Neal Gompa](https://www.linkedin.com/in/ngompa/?ref=itsfoss.com), a well-known name in Linux spaces and contributor to Fedora, openSUSE, and several other distributions, pushed back on a couple of points right away. On Btrfs, [he argued that](https://discourse.ubuntu.com/t/streamlining-secure-boot-for-26-10/79069/2?ref=itsfoss.com) GRUB's driver for it is read-only and actively maintained upstream, and that users running boot-to-snapshot setups depend on it being there. He also disputed Julian's suggestion that native `/boot` RAID setups are uncommon, saying that software [RAID1](https://en.wikipedia.org/wiki/Standard%5FRAID%5Flevels?ref=itsfoss.com#:~:text=%5B11%5D-,RAID%201,-%5Bedit%5D) is "*incredibly common*," in his experience, and removing it would be a substantial loss, not a minor one. When a community member questioned **whether there was a need to support older systems**. Neal laid out that a large chunk of web hosting, cloud, and VPS environments still don't support [UEFI](https://uefi.org/?ref=itsfoss.com) and that plenty of UEFI implementations predating 2017 were too broken to be practically useful. Another Ubuntu community member, [Paddy Landau](https://discourse.ubuntu.com/t/streamlining-secure-boot-for-26-10/79069/6?ref=itsfoss.com), raised a different concern. Dropping PNG and JPEG support in signed builds would kill [boot menu theming](https://itsfoss.com/customize-grub-linux/), something he's had running on his Ubuntu setup for years. He also questioned the security case, noting that the known vulnerabilities appear to affect GRUB versions before 2.12 and that [TGA](https://en.wikipedia.org/wiki/Truevision%5FTGA?ref=itsfoss.com) format doesn't carry the same risk. **The sharpest response** came from [Thomas Ward](https://discourse.ubuntu.com/u/teward/summary?ref=itsfoss.com), a Ubuntu Technical Board member, [who stated that](https://discourse.ubuntu.com/t/streamlining-secure-boot-for-26-10/79069/29?ref=itsfoss.com) Ubuntu's own default installers, including the server installer, set up LVM by default, and LUKS encryption on Ubuntu currently requires LVM. Canonical's own recommended installation configuration would, under this proposal, end up incompatible with Secure Boot on 26.10\. He's asking for a clear, per-feature public justification before anything moves forward and argues that without it, dropping features that users and compliance environments actively depend on is simply not justifiable. And I agree with him. If you can't provide convincing reasons to remove each one of those features, then don't bother proposing it, simple. --- **Suggested Read 📖:** [*Fedora's project leader has suggested something to tackle age verification*](https://itsfoss.com/news/fedora-leader-suggests-age-verification-api/) [Fedora Project Leader Suggests Linux Distros Could Adopt Apple’s Age Verification APIHe thinks a cross-distro API standard can be a practical solution to tackle age verification.![](https://itsfoss.com/content/images/icon/android-chrome-512x512-348.png)It's FOSSSourav Rudra![](https://itsfoss.com/content/images/thumbnail/fedora-apple-age-verification-api-banner.png)](https://itsfoss.com/news/fedora-leader-suggests-age-verification-api/)