Will Fedora use Btrfs for /boot in the future?

I had a fresh installation of F33 but noticed that the /boot still uses the Ext4 file system. Will Fedora use Btrfs for /boot in the future? If yes, do I need to have another fresh installation to make this change happen?

I don’t think this will ever happen.
/boot has to be on a clean partition. It is like when you have encrypted your OS, /boot has to be on separate partition.
Maybe because the computer doesn’t boot other than EFI, fat or ext* partitions.

So you are saying /boot cannot use the Btrfs?

Fedora has a feature, “GRUB hidden menu”. At boot time GRUB resets a counter in a file called grubenv and if the boot succeeds, a systemd unit updates this counter to indicate success. The next time GRUB reads this file, it knows whether the boot was successful. If it is, the GRUB menu isn’t shown, the counter reset, and the system booted. If the boot wasn’t successful, the GRUB menu is shown, and the counter reset.

The gotcha is if this file is located at /boot/grub2/grubenv, as it is on non-UEFI systems. If /boot is on Btrfs, then GRUB writing to grubenv becomes indistinguishable to Btrfs from corruption because the write isn’t happening through Linux kernel code - the various parts of Btrfs metadata including checksums aren’t updated. Because of this, writes to grubenv are disallowed by GRUB when it detects the grubenv file is on Btrfs. This also applies to mdadm RAID, and LUKS. If the boot success counter can’t be reset, GRUB always thinks boot succeeded, so it never shows the GRUB menu.

There are some ideas how to resolve this, but they’re not likely to happen in the Fedora 34 time frame. So I expect /boot will remain on ext4 by default; but the installer will let you do this in Custom and Advanced-Custom partitioning. You can still show the GRUB menu using F8, which on a number of systems requires also pressing an Fn key.

As for the future, I expect we’d have a quick doc describing how to migrate $BOOT to Btrfs. And users can decide if they want to do that or do a clean install.

It’s true for Btrfs on LUKS, $BOOT needs to be unencrypted. But once native Btrfs encryption lands, it’ll be possible to selectively encrypt (or not) each subvolume. So the subvolume used for $BOOT can be non-encrypted.


FWIW, I’ve been using a btrfs /boot partition for a while now, as I use btrfs raid and this saves me having to deal with /boot separately, and it works just like the default setup (beyond what @chrismurphy mentioned, which tbh I didn’t even know about - this is a server, I never see the boot menu :wink: ).


Chris, thank you for the very detailed explanation of the issue with putting /boot on btrfs. Would you mind expanding on “It’s true for Btrfs on LUKS, $BOOT needs to be unencrypted?” Is this simply because GRUB 2.04 does not support LUKS2? If that is the only issue, once the next GRUB release arrives, presumably $BOOT can then be encrypted (since GRUB LUKS2 support was merged earlier this year)?

GRUB and Anaconda support. I think GRUB 2.06 will support LUKS2, it currently supports LUKS1 so you could use that, but the installer doesn’t support configuring GRUB. You’d have to do that yourself. I’m doubtful we’ll ever support it because the a11y and i18n issues with the GRUB environment are even more bleak than they are with the initramfs environment. There isn’t a subset of the desktop stack to bake into the initramfs. And so far there isn’t enough work going into GRUB to satisfy such requirements.

Also, what we really want/need for $BOOT is not encryption. The kernel and initramfs don’t contain secrets, so we don’t need them to be private. What we want is integrity, and possibly authenticity. And we probably want those all the time, not just when the user opts into encryption of user data. The kernel is already signed, so its authenticity can be verified. The initramfs is a problem, however. And we kinda mask that problem by encryption. The likelihood of malicious alteration of the initramfs if it’s encrypted is pretty low but it’s not zero.

There are ideas for solving the initramfs problem, including a prebaked no-host-only (universal) initramfs created within the Fedora build infrastructure, and signing it. But it’s a ways off I think right now.


Purely out of curiosity, what would be involved in this? Isn’t - for example - a fallback initramfs fairly universal already?

The “no host-only” is such a universal initramfs. They’re shipped on ISOs but not in the kernel package. The negative is, bigger download, and longer boot time to load the much larger initramfs. Another possibility is a locally created “host-only” initramfs like we have now, but to either use measure boot or hashing, sealing the requisite secret in something like a TPM. I’m not sure what direction Fedora will go in.

1 Like