On Mi, 27.07.22 10:13, Chris Murphy (lists@xxxxxxxxxxxxxxxxx) wrote: > > Since you say systemd-boot can already do what we want in this regard: > > > > e. Replace grub for EFI systems with systemd-boot ? > > I wish it were possible. I'm pretty sure the Red Hat bootloader team > has no time or interest in it. And there's no upgrade path, because > systemd-boot requires a FAT /boot volume. That's only half the truth. sd-boot searches for kernels on the ESP (which has to be VFAT effectively, since that is the only thing UEFI requires firmwares to support), or on an optional, second partition we call XBOOTLDR which is more like fedora's /boot/ – and that one can be basically any file system, the only requirement is that it must be readable via UEFI file system APIs. VFAT qualifies for that out of the box, hence is a good choice. That said, it's not the only option, there are multiple projects supporting other file systems in UEFI, for example this one: https://efi.akeo.ie/ So, let's say you want to make sd-boot be able to access a legacy ext4 /boot/ fs. First, fix the GPT partition type of that /boot/ partition to be the XBOOTLDR one (so that sd-boot can recognize it; currently fedora for some reason marks it as "generic Linux partition"). Then take the ext4 uefi driver from the project above, sign it as you sign every EFI binary, and drop it into the /EFI/systemd/drivers/ directory on the ESP. This is all you need to do, as sd-boot looks into that dir, and automatically loads all drivers found there. Net effect: "bootctl install" (the tool that installs sd-boot for you) installs two EFI binaries instead of just one. Given that the project above simply uses the Grub file system implementations and adds a bit of uefi glue on top, you would actually use the exact same code to access the file systems as before in the Grub case. That all said: I am pretty sure using non-vfat for XBOOTLDR should be a legacy thing. New installations should use vfat for ESP + XBOOTLDR, to minimize complexity. Given that fedora already generates Boot Loader Spec entries sd-boot should otherwise be ready to just read what is already there. > The lack of an upgrade path, I think, is a bigger issue than a > system-wide change proposal to: switch to systemd-boot on UEFI, > including FAT /boot partition, for new clean installs. I don't think the upgrade path would be so bad. Takes some careful work to get into place, but we went through worse migrations in Fedora I am sure. > There's quite a lot of GRUB upstream work related to TPM stuff, > including measured boot. I have no idea if we're going to use any of > that at some point, but it's not something in systemd-boot's realm. Frankly, the TPM and grub situation is a giant mess. The PCR measurements it generates measure chosen code execution paths, not static code, and hence are entirely useless if you want to reliably precalulate PCR values, and bind policy to that. It's one of the reasons why outside of fixed-purpose systems with a limited scope noone does TPM on Linux. With systemd-boot/systemd-stub we have more reliable measurements already (we measure code, not chosen code execution paths), which means there are some projects (such as ubuntu core, which currently chainload sd-boot from grub, just to be able to get the realiable TPM measurements we provide you with...). Lennart -- Lennart Poettering, Berlin _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
