+1

@javierm would be great (as I mentioned before) to have "upgrade from F33" steps somewhere on the wiki (with warning that you are on your own is fine).

+1

+1

+1

I'm concerned that this is regressive for UEFI systems when /boot on Btrfs is used (which is possible with advanced partitioning). Moving grubenv to /boot means that GRUB can no longer write to it in that scenario, which breaks the GRUB Hidden Boot Menu feature we've had for a while now.

The XFS and ext4 developers upstream are also generally unhappy with the idea that GRUB writes to those filesystems in a corruptive manner (that is, it's not recorded in their journals). I'd personally prefer a solution where we unified GRUB configuration to be stored in a dedicated small partition (be it FAT or ext2 or something custom) on both BIOS and UEFI.

So as it stands... -1

+1

@javierm would be great (as I mentioned before) to have "upgrade from F33" steps somewhere on the wiki (with warning that you are on your own is fine).

Sorry I was on vacation. @chrismurphy suggested in the fedora-devel thread that we could switch to the new configuration scheme on upgrade but keeping the old config files.

And have proper documentation on how to access those and revert the changes for users that have custom configs that diverged from the default and might have issues.

I've updated the proposal wiki page mentioning that and will add more details as we implement the changes.

I'm concerned that this is regressive for UEFI systems when /boot on Btrfs is used (which is possible with advanced partitioning). Moving grubenv to /boot means that GRUB can no longer write to it in that scenario, which breaks the GRUB Hidden Boot Menu feature we've had for a while now.

The XFS and ext4 developers upstream are also generally unhappy with the idea that GRUB writes to those filesystems in a corruptive manner (that is, it's not recorded in their journals). I'd personally prefer a solution where we unified GRUB configuration to be stored in a dedicated small partition (be it FAT or ext2 or something custom) on both BIOS and UEFI.

So as it stands... -1

That's fair. Although this is already the case for legacy BIOS installations that use btrfs for /boot. In other words, I think that it was only working by luck because for EFI systems the grubenv was stored in the ESP.

As we have already discussed in other venues, the grubenv being a file is unreliable for most file systems so is something that has to be addressed regardless of this change proposal.

So about @ngompa 's objection to this, that really is a special corner case, but yes it is possible for people to have created the special setup Neal describes and yes in that case moving grubenv to /boot will break the hidden-menu functionality.

I'm not sure if this warrants a -1 to the proposal though, I believe documenting this + some workaround for it should be sufficient.

But as mentioned this has more to do with the fact that storing the grubenv in a filesystem-file is a bad idea in general.

As discussed in detail here: https://pagure.io/fedora-workstation/issue/206 we really should be moving away from that. As discussed there Suse already has grub-patches to instead store the grubenv in an part of the btrfs filesystem header which is reserved for bootloader use. As @javierm says in the linked issue, that is also the long term plan for Fedora, but we really want to discuss and develop a solution for this upstream so that we don't end up with conflicting solutions between distributions which stomp all over each-others data.

+1

After a week, the vote is (5,0,-1). Tagging for the next meeting, per FESCo's ticket policy.

• AGREED: Unification of GRUB config files is accepted (+6, 1, -0) (sgallagh, 16:27:42)