Fedora now has a sensible UEFI boot setup (and has for some time)

April 6, 2022

The news of the time interval is that Fedora is considering deprecating legacy BIOS booting (via). This gave me feelings partly because back in 2018, I wrote an entry about what turned out to be an unfortunate decision Fedora made about how to use UEFI, where Fedora put your main Grub2 configuration file into your EFI system partition. This is a terrible thing for anyone who uses mirrored disks because it makes keeping two EFI system partitions in sync much more difficult; at the time, Fedora updated your main Grub2 configuration on every kernel update. I was all set to make a grumpy tweet about this until I decided to check the current state of things on my work laptop (which uses UEFI booting). To my pleasant surprise, Fedora has switched to a more sensible UEFI boot setup.

The modern Fedora EFI setup has a stub EFI grub.cfg in /boot/efi/EFI/fedora that simply points to your real grub.cfg in /boot/grub2. This grub.cfg itself is also basically a stub that loads further information from files in /boot/loader/entries, following the Boot Loader Specification. The net result is that the files in your EFI system partition only need to change when Grub2 itself is updated, perhaps only on Fedora version upgrades. This makes it much easier to keep a backup EFI system partition on your second disk up to date; you only have to remember to update once in a while.

(The EFI grub.cfg does know the UUID where /boot/grub2 lives, so you need to somehow update it if you change that location. I suspect it's generated at install time.)

Based on the timestamps in /boot/efi/EFI/fedora on my work laptop, I suspect that this change happened in Fedora 30, when Fedora switched over to the Boot Loader Specification. As I found out, this switch to a BLS configuration could have gotchas, and since the switch reduced even your main grub.cfg to somewhat of a stub, it seems like good timing. Fedora could have put the main grub.cfg in the EFI system partition, but it would still have wanted to load BLS entries from /boot.

For my own future reference, as of Fedora 35 the RPMs that have stuff in /boot/efi on my laptop are efi-filesystem, grub2-common, grub2-efi, shim-x64, and mactel-boot (which I suspect I could live without). If I want to switch either my home desktop or my work desktop over to UEFI boot, I need to insure that these are installed and have their files on my EFI system partition.

(I tried to switch my office workstation to UEFI back in 2018, but failed fairly badly, partly due to motherboard BIOS issues. Things might be better now, but on the other hand Fedora is not (yet) talking about completely removing BIOS MBR boot support, so why rush. Perhaps I'll have replaced my office workstation by the time Fedora does drop BIOS booting support.)

Sidebar: My laptop's EFI grub.cfg

For my own future use, this is:

search --no-floppy --fs-uuid --set=dev <long-UUID>
set prefix=($dev)/grub2
export $prefix
configfile $prefix/grub.cfg

My laptop has /boot as a separate partition from the root filesystem, because the root filesystem is in LVM. If /boot was on the root filesystem, the prefix would presumably be '($dev)/boot/grub2'. These days, the actual BLS entries in /boot/loader/entries use 'linux ...' and don't apparently need 'linuxefi' any more. The /boot/grub2/grub.cfg file does have an option for UEFI firmware settings, created by /etc/grub.d/30_uefi-firmware, so that's another thing to add during a conversion.

I hope and assume that the EFI Grub2 can work with software RAID mirrors the way that the BIOS MBR one can, but I haven't actually tested it.


Comments on this page:

This is a terrible thing for anyone who uses mirrored disks because it makes keeping two EFI system partitions in sync much more difficult […]

There is a way around this using mdadm. The trick is to use metadata version 1.0:

Use the new version-1 format superblock. This has fewer restrictions. It can easily be moved between hosts with different endian-ness, and a recovery operation can be checkpointed and restarted. The different sub-versions store the superblock at different locations on the device, either at the end (for 1.0), at the start (for 1.1) or 4K from the start (for 1.2). "1" is equivalent to "1.2" (the commonly preferred 1.x format). "default" is equivalent to "1.2".

With the soft RAID metadata placed at the end of the partition, the FAT32 information is not clobber ed and the UEFI system can still read it.

   mdadm --create /dev/md0 --metadata 1.0 --raid-devices=2 --level=1 /dev/sd[ab]1
   mkfs.fat -F32 /dev/md0

EFI of course knows nothing about RAID, so you have to tell it, via the efibootmgr utility, about things (GRUB, whatever) on both partitions. The risk is that the EFI firmware itself can perhaps write to the ESP partition, and since the alteration is outside of mdadm, it will not get synced.

Generally syncing manually with dd should be sufficient.

Written on 06 April 2022.
« The failure of the idea of X resources
What goes into an X resource and its name »

Page tools: View Source, View Normal, Add Comment.
Search:
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Wed Apr 6 22:43:53 2022
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.