On Wed, Jul 27, 2022, at 12:11 PM, Daniel P. Berrangé wrote: > On Wed, Jul 27, 2022 at 10:13:57AM -0400, Chris Murphy wrote: >> >> >> On Wed, Jul 27, 2022, at 4:42 AM, Daniel P. Berrangé 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. 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. > > AFAICT, use of /boot is entirely optional, and is ignored if it > can't be accessed (due to either not existing, or having an unsupported > filesystem type). I've got VMs booting with system-boot where /boot is > xfs and systemd-boot pulls the kernel found in /boot/efi. Boot Loader Spec defines $BOOT as either EFI System partition (ESP) or Extended Boot Loader Partition (XBOOTLDR), and in effect they need to be FAT in order to fulfill the interoperability intent of the spec, because it is a shared $BOOT across all distros. While some firmware also can read NTFS or HFS+, we're not likely to ever consider using them for $BOOT. I'm not sure what an XFS /boot would contain when using systemd-boot. > IIUC, the main reason for the loader to use /boot is if /boot/efi > is insufficiently large for storing the kernels, and /boot has > greater space. Admittedly this is probably still the key issue for > the upgrade scenario, since existing Fedora VMs seem to get a /boot/efi > partition that is even smaller than /boot. The main case for XBOOTLDR is dual boot, because we can't control the creation of the ESP. Microsoft and OEMs are still routinely creating 99 MiB ESPs. Otherwise we can have a large ESP, possibly scaled to the size of the drive or possibly extract intent from the user (in a custom partitioning path) about installing additional distros, etc. to reserve the proper amount of space for this shared $BOOT. >> 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. > > The Grub support for the RPM measurements is one of the big reasons > for wanting to replace Grub IMHO. Every single statement that is > executed from the grub.conf file gets individually measured into > the TPM[1]. Writing a policy to validate correctness of the measurement > taking into account grub.conf permuations is beyond the bounds of > reasonableness. This is a key problem the virt maintainers are facing > when trying to figure out how to support confidential virtualization, > where we need to measure the boot process. A vastly simplified boot > loader like sd-boot + unified kernels is quite appealing in this area. I don't disagree. But there are Secure Boot impediments that need to be figured out to switch to sd-boot. And I think they need to be explored with the other sd-boot issues in a dedicated thread, because moving to sd-boot is at best Fedora 38 time frame. And the Bitlocker issue needs improvement sooner than that. -- Chris Murphy _______________________________________________ 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
