grub2-install

In Fedora 34 (and the corresponding CentOS Stream 8 release) grub2-install now implements the grub-install should not be used on EFI systems small print.

Not really small print, it's right there in paragraph two of the manpage.

The problem is, and has been for a decade, that EFI systems have a notion of Secure Boot where they will only boot cryptographically signed images. You may recall the debacle around this as the EFI implementors (BIOS manufacturers) only used Microsoft keys in their firmware (after all, who else makes Operating Systems?) thus preventing any other operating system from booting on a Secure Boot enabled system.

*Ching!* *Bonuses all round!*

The non-Microsoft fix is to have your key signed by Microsoft which was great if you were RedHat, Canonical and other large players who could pay some Microsoft tax but not so great if you were a smaller organisation.

To be fair Microsoft have an EFI signing process which even covers (an even more onerous path for) shims which are fairly trivial bits of code which are 1) signed and 2) will run something else (which is presumably vetted in some way). Various shim implementations are open source. And to be doubly fair, with compliant firmware, you can replace the signing keys.

In the RedHat case, strings suggests that shimx86.efi will run a corresponding grubx86.efi (in the same directory?).

The problem with grub2-install is that it is creating an unsigned image to be booted. Now, most of the time, none of us have Secure Boot enabled because it's not adding value and so booting off an unsigned image isn't a problem. (Although with the advent of Windows 11 requiring Secure Boot capability -- not necessarily a requirement -- maybe the times, they are a-changing.)

However, in Fedora 34, they have laid down the law:

# grub2-install --boot-directory=/tmp/usb-sde/boot --efi-directory=/tmp/usb-sde/boot/efi --target=x86_64-efi --bootloader=multiboot -v /dev/sde
grub2-install: error: this utility cannot be used for EFI platforms because it does not support UEFI Secure Boot.

With the reasoning that if, in the future, you do enable Secure Boot then the system won't boot.

In fact, most of the debate and documentation seem to revolve around users making mistakes (re-)building their currently running operating system and aren't overly concerned with people creating multiboot USB drives.

Breaking your current build is a concern for those support staff tasked with unpicking the mess it creates, so fair enough, but the argument against USB drives seems to be that you're not supposed to be building multiboot USB drives. Images for USB sticks are meant to be dd'd on and no funny business.

Fedora do supply signed EFI images but they are installed from packages and not by a command. Officially, these files are in the shim-* and grub2-efi-* packages. You can check you have booted using EFI by looking for the directory /sys/firmware/efi (which contains lots of stuff).

# rpm -q -a | egrep '(shim|grub2-efi)-'
shim-x64-15.4-4.x86_64
grub2-efi-x64-2.06~rc1-4.fc34.x86_64

We can then check to see what this packages have installed using repoquery (itself from dnf-tools):

# repoquery -l shim-x64
Last metadata expiration check: ...
/boot/efi/EFI/BOOT/BOOTX64.EFI
/boot/efi/EFI/BOOT/fbx64.efi
/boot/efi/EFI/fedora/BOOTX64.CSV
/boot/efi/EFI/fedora/mmx64.efi
/boot/efi/EFI/fedora/shim.efi
/boot/efi/EFI/fedora/shimx64.efi
/etc/dnf/protected.d/shim.conf
# repoquery -l grub2-efi-x64
Last metadata expiration check: ...
/boot/efi/EFI/fedora/fonts
/boot/efi/EFI/fedora/grub.cfg
/boot/efi/EFI/fedora/grubx64.efi
/boot/grub2/grub.cfg
/boot/grub2/grubenv
/boot/loader/entries
/etc/dnf/protected.d/grub2-efi-x64.conf
/etc/grub2-efi.cfg
/etc/grub2.cfg

Maybe we can just tar these over?

grub.cfg

The next problem is that Fedora 34 has introduced a new, smarter, GRUB layout using systemd-boot.

You used to manage grub menuentrys by editing grub.cfg which lived in one of several places -- I won't try to list them as I'm not sure I ever had a handle on it but the likes of .../efi/EFI/centos/grub.cfg and /boot/grub/grub.cfg.

Now we get a stock /boot/grub2/grub.cfg and then a number of BootLoaderSpec .conf files in /boot/loader/entries of the likes:

# cat /boot/loader/entries/84267b152bf2d0e931200d128381e90c-5.11.19-300.fc34.x86_64.conf
title Fedora (5.11.19-300.fc34.x86_64) 34 (Server Edition)
version 5.11.19-300.fc34.x86_64
linux /vmlinuz-5.11.19-300.fc34.x86_64
initrd /initramfs-5.11.19-300.fc34.x86_64.img
options root=/dev/mapper/fedora-root ro resume=/dev/mapper/fedora-swap rd.lvm.lv=fedora/root rd.lvm.lv=fedora/swap rhgb quiet
grub_users $grub_users
grub_arg --unrestricted
grub_class kernel

These are slurped in by insmod blscfg in grub.cfg.

The funny number, 84267b152bf2d0e931200d128381e90c, is, in this case /etc/machine-id although the Boot Loader Entries specifications merely suggest it should be something unique to avoid multiple operating systems clashing for dual-boot systems.