Ubuntu systems support secure boot using grub. grub contains a lot of parsers for file systems and other things which are a constant source of security issues.

In 26.10, we’d like to propose removing the following features from signed GRUB builds:

• Filesystems
  • Remove btrfs, hfsplus, xfs, zfs
  • Retain ext4, fat, iso9660 (and squashfs for snaps)
• Image formats:
  • Remove jpeg, png
  • Retain none
  • We do not use images, but using that in your grub.cfg locally is a massive security risk (if even still allowed)
• Partition tables:
  • Remove part_apple
  • Retain part_gpt and part_msod
• Support for LVM
• Support for md-raid; except raid1.
• Support for LUKS-encrypted disks

In effect systems must boot with /boot on a raw ext4 partition (whether a separate or inside of /); on GPT or MBR disks.

This means for example, that an encrypted system must use an ext4 /boot partition; it is no longer possible to encrypt the /boot partition. Likewise a system on ZFS, XFS, BTRFS must use an ext4 /boot partition.

RAID systems are usually set up by mirroring the /boot partition, rather than putting /boot on a RAID natively, so this should not be a substantial loss.

We understand these are controversial options; however we believe they’d substantial improve security, but also simply pivoting to new boot solutions in the future.

The features will continue to be available without secure boot and security support.

Affected systems will by default stay on 26.04 LTS, that is, the upgrade will be disabled in ubuntu-release-upgrader.

Can we please not drop btrfs? It’s a read-only filesystem driver that is actively supported by upstream developers. Users who want to leverage boot-to-snapshot setups with Btrfs need this support.

That’s not my experience with users. Software RAID1 is incredibly common. It would indeed be a substantial loss.

Have you considered switching to systemd-boot instead? It’s the minimal bootloader you’re looking for, and it integrates into systemd-based systems well anyway.

except Raid 1

I think they are implying raid1 wouldn’t be removed but other raid types would

systemd-boot is UEFI only, grub supports both BIOS and UEFI

Do you really want to support >=20 years old systems?

Most web hosting/cloud/VPS environments today don’t support UEFI today, either. So yes, we do.

And even if you exclude that and focus on desktop/server systems, a lot of UEFI implementations have been unusably broken prior to 2017, so only the last decade of PCs have things in useful enough order.

Also, GRUB supports more than x86, and Ubuntu is a multi-arch platform, supporting platforms that neither IBM/Phoenix BIOS (and descendants) nor UEFI exist. A common bootloader drastically simplifies the maintenance burden on that front.

To add to the reply by @Conan_Kudo, bear in mind that many people have dual-boot or multi-boot systems, not all of which necessarily support UEFI.

Some Ubuntu flavors have grub themes, and I know those use images. I don’t think you can yank this since it’s something flavor customization relies on.

Does this mean that LUKS2 encrypted /boot partitions will not be allowed? I have (although manually) set on my development 26.04 system encrypted /boot partition with ext4 and LUKS2 (pbkdf) and everything works correctly.

In my personal opinion removing support for LUKS2-encrypted /boot partition isn’t wise unless GRUB2’s encryption implementation defeats security enhancements provided by encrypted /boot

I would be terribly disappointed if you were to remove images. At the moment, we can use PNG and JPEG. Supposedly, TGA is also supported, but I’ve been unable to make it work.

I’ve been seeing my welcoming Ubuntu background when I boot for many years!

From what I’ve read, the security vulnerabilities affect only versions of Grub prior to 2.12, and TGA doesn’t present a vulnerability.

To add to @tomekdev’s comment, surely Grub must support both LVM and LUKS? LUKS is an industry standard within Linux, so how would we boot without its support? LVM is also common. My system uses both LVM and LUKS.

I don’t know, if it’s a real deal then I understand and of course accept it. In the meantime, as a normal user I feel like I have to struggle more to get what I want. We had a simple timeshift btrfs layout yearso ago and that was taken away, now relying on scripts that not always work - especially on 26.04. Needing to setup a different /boot partition in order to have btrfs, xfs and zfs does feel strange, just as choosing a driver on 26.04.

Please explain why.

If one has the privileges to change the boot picture, couldn’t that person also change other boot parameters?

Setting a GRUB theme is the easiest way to make the boot just a bit less ugly and partially hide the embarrassing obsolescence of GRUB.

In effect systems must boot with /boot on a raw ext4 partition (whether a separate or inside of /); on GPT or MBR disks.

Full disk encryption is mandatory in many environments in Europe for security conformity. So support for encrypted /boot (via LUKS) is important.