Fedora approves a smaller GRUB

Leo Sandoval and Marta Lewandowska have put forward a change proposal for Fedora 45, which is expected in October, to provide a separate, slimmed-down version of GRUB for a niche use case. The new package would be in addition to the main GRUB package and would not replace it for the majority of Fedora users. The idea met with some resistance from Fedora contributors who thought that it would be better to use systemd-boot, or another modern bootloader, rather than trying to wrangle GRUB into a suitable state for the use case. The Fedora Engineering Steering Council (FESCo), however, voted to accept the change on July 7.

Signed, sealed, booted

The change proposal specifies the creation of a UEFI-only build of GRUB with a minimal set of modules for booting unified kernel images (UKIs) using boot loader specification (BLS) files. The target use case is for booting "sealed bootable container" images in virtual environments (e.g., running virtual machines in public clouds) for confidential computing.

LWN has covered bootable containers (bootc) in the past, but sealed bootc images are relatively new. A sealed image is one with all of the components for a fully verified boot chain: that includes firmware, the UKI, and a composefs repository, with fs-verity enabled, for the filesystem rather than OSTree, which has traditionally been used for bootc. A sealed image relies on Secure Boot and currently is only supported on x86_64 and aarch64 systems with UEFI.

The main users of the new GRUB package, according to the proposal, will be the Fedora CoreOS developers. Since CoreOS is meant to be a minimal, automatically updated operating system, the hope is that a stripped-down GRUB with fewer built-in modules will have a smaller attack surface and require less-frequent updates. CoreOS may be the first user of the new GRUB build, but the proposal envisions "a minimal UEFI bootloader for virtual environments that can be further tailored for use in those environments".

It is interesting to see Lewandowska, who is a Red Hat quality engineer, now endorsing GRUB for this use case after arguing that it should be replaced not long ago. She gave a a talk at DevConf.cz, in 2024, about a project called nmbl (for "no more bootloader", pronounced "nimble") that would replace GRUB for use with UKIs. Instead of using a separate bootloader, nmbl would use the Linux kernel as its own bootloader. Her blog post that was published to coincide with the talk gives a good overview of nmbl, as well as its anticipated advantages over GRUB.

She pointed out at the time that Red Hat was carrying "hundreds of downstream patches" for the project and had argued that GRUB was too complex. Lewandowska also pointed out the large number of vulnerabilities it had been subject to over time, as well as all of the filesystem, storage, and memory-allocation bugs that she said GRUB's developers did not have the time to fix.

During the proposal discussion, Lewandowska explained her change of heart regarding GRUB, at least in part: "This year GRUB upstream moved to GitLab, has much better [continuous integration], become more accessible and much more lively." It would appear that work on nmbl has stalled as GRUB has had a revival: the repository that seems to have the most up-to-date work on the project, a dracut plugin for working with nmbl, was last updated in August 2025. The proposal does not mention nmbl at all.

Why not systemd-boot?

The original vision for sealed bootable containers called for using systemd-boot rather than GRUB. The proposal mentions that systemd-boot was considered, but was rejected for several reasons. It argued that systemd-boot "has not been widely tested or fuzzed, like GRUB has been", and that long-term maintenance of more than one bootloader would add technical debt. An early version of the proposal claimed that the systemd team would "view any additional features [for systemd-boot] as a no-go".

Fedora change discussions are still conducted on both its discussion forum and the Fedora development mailing list, though a proposal to change that and move discussions solely to the mailing list is currently being entertained. This meant that the discussion was, naturally, a bit fragmented. On the forum, Zbigniew Jędrzejewski-Szmek said that the arguments against systemd-boot were "divorced from reality". He said that the project was "fairly widely used", its code was being fuzzed through OSS-Fuzz (albeit "not as extensively as it should be"), and added that systemd-boot received new features regularly.

On the mailing list, Lennart Poettering commented that he was "really irritated" by the comment that systemd developers were not adding features. "We are adding new stuff to systemd-boot/systemd-stub all the time, including stuff contributed by Red Hat's [confidential computing] folks". On the forum, Lewandowska said that proposal sponsors were told by "RHEL/Fedora systemd maintainers" that new features were not being added to systemd-boot. The bullet point about new features has since been removed from the proposal by Kashyap Chamarthy.

Michael Gruber said that he was not against the proposal, per se, but complained that it was "giving up on the idea of systemd-boot (or something else) as a new and lean boot loader". GRUB does too many things, he said, and he was not convinced that "chopping off parts" of the software would be the right way to go. Alberto Ruiz also thought that the reasons given for rejecting systemd-boot were faulty: "the burden of maintaining a GRUB variant is likely higher than the burden of supporting systemd-boot in an additional use case that is very limited in scope".

If GRUB were not so widely used, Lewandowska said, "I would agree adopting it for this use case does not make sense". But, given the amount of investment it has already received, she believed that it made sense to use GRUB rather than to adopt something new.

The proposal provided instructions and links to packages for early testing. Gerd Hoffman observed that the test GRUB package "does not look very stripped down to me", and provided output comparing the size of the standard GRUB binary against the test version. The smaller GRUB package was only about 64KB smaller than the standard binary, which is a bit larger than 4MB. Sandoval acknowledged that it needed more work and linked to the tracking ticket for the work of removing non-essential modules from GRUB.

Neal Gompa said he was generally in favor of the proposal, though he wanted to see support for other common filesystems such as Btrfs, ext4, and XFS. Currently the slimmed-down build only includes the FAT filesystem module. Timothée Ravier replied that adding more supported filesystems would contradict the goal of including as few modules as possible to reduce the attack surface and reduce the need for updates. That led to an extended debate about other cloud use cases and the problems with UEFI.

Gompa also said that he had been "exploring and engaging with upstream" GRUB developers on the topic of providing additional security features around data integrity. "With the revived upstream and our patches getting merged at a rapid clip now, I'm very optimistic about the future of the GRUB project." Poettering, however, was less enthusiastic about expanding GRUB's filesystem features. "It's hard enough for the Linux storage people to maintain that as part of the Linux kernel, and now you expect the handful of Grub maintainers to keep up with this in their own codebase?"

Oron Peled suggested another strategy, highly reminiscent of nmbl, for dealing with the various filesystems that bootable components might live on. Specifically, he thought the project should consider using an intermediate kernel to boot another kernel, thereby reusing the Linux kernel's filesystem drivers. Jędrzejewski-Szmek pointed out that Peled's suggested approach "has been discussed extensively in the past" but had a number of downsides. For example, he said that the kernel's "'embrace all CVEs' approach" that has resulted in a constant stream of CVEs meant "we'd be updating that smaller kernel all the time".

Accepted

In considering the change, FESCo member Simon de Vlieger said that he found it difficult to vote on; he did not see the value in having the stripped-down GRUB in virtual environments, but thought it might be useful in other situations that were not being considered or targeted. "This stripped down version is at odds though with what I've seen people expect this to turn into (having filesystem drivers, that sort of stuff)." But, since it was only the introduction of a new package, he cast a "weak-ish +1" in favor of the proposal. He said that he expected any deliverables, such as CoreOS, that might use the new package by default would need to go through the change process for approval.

Ravier said that he was wearing multiple hats in the discussion since he was involved with CoreOS, Fedora's Atomic desktops, Red Hat Enterprise Linux (RHEL) CoreOS, as well as being a member of FESCo. He was in favor of the change since it would be used in RHEL and CentOS CoreOS for confidential-computing setups. But, from the FESCo perspective "I don't think this change brings a lot of value to Fedora and we should focus on using systemd-boot instead". He said he was working on using systemd-boot for the Atomic desktops, but: "In the end, I'm +1 as this is an additive change that is useful for some groups of Fedora and does not prevent us from doing something else in the future."

In the end, none of the FESCo members expressed much enthusiasm for the proposal, but none of the members seemed inclined to oppose it. It passed with five votes in favor (out of nine possible) and none against. Assuming all goes well, the new package should appear in Fedora 45. It will be interesting to see how the experiment goes, and whether there is a change proposal in time for Fedora 46 to make this the default bootloader for Fedora CoreOS.