Add support for systemd-boot (and minimal GRUB2 builds)

[travier]

We will need bootupd to support installing and updating minimal bootloaders like systemd-boot (and a potentially upcoming minimal build of GRUB2) alongside shim.

Initial support was being worked on in #978 but we should not use bootctl directly as we also need to install and update shim alongside systemd-boot.

[travier]

Or implement support in bootctl: systemd/systemd#27234

[travier]

The end goal is that we want to have a single image that will be used for all installation methods:

• Current state:
  • rpm-ostree/bootc with ostree+composefs backend without fs-verity
  • with GRUB2 + static GRUB configs
  • and split kernel/initramfs
• What we want to migrate the existing systems to:
  • bootc with pure composefs backend
  • with GRUB2 + static GRUB configs
  • and split kernel/initramfs
• Sealed images and potentially new default in the future:
  • bootc with pure composefs backend
  • with minimal GRUB2 build / systemd-boot, no GRUB config
  • and UKI or split kernel/initramfs

See https://hackmd.io/WDPXRiUsQe2ugBhjp147xQ for a longer discussion about those layouts.

Thus we need to include all of shim, current GRUB2 and the minimal GRUB2 / systemd-boot in a single image and add a way for bootupd to figure out which one to install and update.

At installation time, we will need some form of "runtime" configuration to select which bootloader to install as the configuration can not (always) be part of the image itself. This is similar to the filesystem option for bootc base images in that you can derive an image and set a fixed filesystem/bootloader but the default image will have to support all of them.

At update time, we can either rely on a key stored in /boot/bootupd-state.json or query the currently used bootloader from EFI vars to decide which one to use.

Shim currently hardcodes the name of the bootloader that it will execute once it's done setting things up: https://src.fedoraproject.org/rpms/shim-unsigned-x64/blob/rawhide/f/shim-unsigned-x64.spec#_127

As both the minimal GRUB2 and systemd-boot are not named as grub<efiarch>.efi in the packages themselves, we will have to add logic to bootupd to write the choosen bootloader under the expected name.

See:

• https://koji.fedoraproject.org/koji/rpminfo?rpmID=47120161
• https://koji.fedoraproject.org/koji/rpminfo?rpmID=47120163
• https://koji.fedoraproject.org/koji/rpminfo?rpmID=46647998 and later https://src.fedoraproject.org/rpms/systemd)

Thus we can not easily figure out from the state on the disk what version of the three setups we have (unless we do hash comparisons, etc.).
We should be able to figure out what installed on the disk by reading PE metadata from the EFI binaries.

[travier]

It is possible to tell shim to execute another binary but that requires writing an EFI variable (boot entry) thus we likely can not rely on this as we want this to work for disk boot images that do not have such an entry:

• https://wiki.gentoo.org/wiki/Shim#Setup (see the tip)
• https://wiki.gentoo.org/wiki/Shim#systemd-boot

[cgwalters]

rpm-ostree/bootc with ostree+composefs backend without fs-verity
...
bootc with pure composefs backend

That's a big migration, definitely a goal though, bootc-dev/bootc#2079 and bootc-dev/bootc#20

[travier]

We also need shim in the boot path to have firmware updates with fwupd work as expected.

[Johan-Liebert1]

1. Put grub-cc in /usr/lib/efi/grub2-cc/1:2.12-59.fc45/EFI/fedora/grubx64-cc.efi /usr/lib/efi/grub2-cc/1:2.12-59.fc45/EFI/fedora/grubx64.efi as suggested by @travier

2. In bootupd, we'll have grub-cc as an EFIComponent, we can then rename this to grubx64.efi and proceed with copying to ESP.
   This will be a preprocessing step depending upon the bootloader param

The following is what the internal structure looks like. In the preprocessing step, we'll either remove grub-cc or grub2
depending on which bootloader is chosen

systemd-boot should be pretty similar

Some(
    [
        EFIComponent {
            name: "grub-cc",
            version: "1:2.12-59.fc45",
            path: "usr/lib/efi/grub-cc/1:2.12-59.fc45/EFI",
        },
        EFIComponent {
            name: "grub2",
            version: "1:2.12-58.fc44",
            path: "usr/lib/efi/grub2/1:2.12-58.fc44/EFI",
        },
        EFIComponent {
            name: "shim",
            version: "16.1-5",
            path: "usr/lib/efi/shim/16.1-5/EFI",
        },
    ],
)

3. The state file gets kinda complicated. We can store it in the ESP as it doesn't make sense to have /boot in grub-cc or systemd-boot case, but with this we might run into some complications in RAID setups.
   In RAID setups we mount all the available ESPs and install the bootloader to all, so where do we keep the state file? Feels weird to keep the state file in all the ESPs

4. For updates, we can read LoaderInfo-* to detect the bootloader. This is exactly what we do in bootc

[travier]

Good points here.

1. Put grub-cc in /usr/lib/efi/grub2-cc/1:2.12-59.fc45/EFI/fedora/grubx64-cc.efi

We should likely ask that as part of the split into a distinct package: https://fedoraproject.org/wiki/Changes/Grub2LightForConfidentialComputing.

Maybe /usr/lib/efi/grub2-cc/1:2.12-59.fc45/EFI/fedora/grubx64.efi so that we don't even have to add the logic to rename the file. Maybe the system-boot signed package should add a hardlink at a similar path as well so that we don't have to do renames at all.

3. The state file get kinda complicated. We can store it in the ESP as it doesn't make sense to have /boot in grub-cc or systemd-boot case, but with this we might run into some complications in RAID setups.
   In RAID setups we mount all the available ESPs and install the bootloader to all, so where do we keep the state file? Feels weird to keep the state file in all the ESPs

I guess we should have a state file per ESP in the "no /boot and RAID/multiple ESP" case. I don't think we've tried RAID and the new composefs backend.

[Johan-Liebert1]

Maybe /usr/lib/efi/grub2-cc/1:2.12-59.fc45/EFI/fedora/grubx64.efi so that we don't even have to add the logic to rename the file. Maybe the system-boot signed package should add a hardlink at a similar path as well so that we don't have to do renames at all.

sounds good to me

I guess we should have a state file per ESP in the "no /boot and RAID/multiple ESP" case

we can go with this if you think it's fine

I don't think we've tried RAID and the new backend.

we haven't

[travier]

From a discussion with Pragyan, let's focus on the systemd-boot + shim use case for bootupd and keep the standalone systemd-boot via bootctl support in bootc only.