On Tue, Jun 13, 2023 at 07:55:09AM -0500, Jeremy Linton wrote: > Hi, > > On 6/5/23 03:24, Zbigniew Jędrzejewski-Szmek wrote: > > On Fri, Jun 02, 2023 at 05:25:22PM -0700, Luya Tshimbalanga wrote: > > > Hello team, > > > > > > I would like to bring back the topic related to the selection of bootloader > > > notably either GRUB2 and systemd-boot. With the recent adoption on UKI > > > kernel, it would be great to get systemd-boot ready for at least Fedora 39 > > > which is useful for devices like laptops. Currently, some methods allow to > > > install systemd-boot with extra step to keep supporting secure boot while > > > preserving GRUB2 [1]. What is the missing step to enable secure boot for > > > systemd-boot without at least keeping GRUB 2? > > > > Hi Luya, > > > > my goal is to have systemd-boot built as a ready-to-install Fedora package > > with a Fedora signature for SecureBoot. The signature would use a different > > certificate than grub2, and would not be trusted by our shim build. (This > > way, we don't have to touch the complicated issue of making shim trust sd-boot.) > > Users would be able to self-enroll those sd-boot singing keys on their machines, > > getting reasonable protection from SecureBoot and being able to build > > useful policies for tpm-encrypted secrets. > > I tend to agree this is the right way to use systemd-boot although users > depending on 3rd party modules will be again locked out of the secure boot > path without the shim + MOKs. That support exists in systemd-boot today but > it might be a good idea to provide a switch to disable the shim support in > sdboot if the plan is to have a clean secure boot setup without MOKs. AKA > systemd-boot-signed and a systemd-boot-signed-for-shim package. > > > > > > Unfortunately, this requires releng to adjust the infrastructure to do the > > signing, and this is not progressing at all [1]. > > > > Also, there has been work to add support for sd-boot to Anaconda [2,3]. > > There has been more progress there, but what we have is not a complete solution. > > It is with the comps change below and the acceptance of the sdbubby package > which is shimming things like kdumpctl to the systemd interface. Granted its > not complete given the secure boot path hasn't been solved, but it does > allow for testing a machine that can be updated, and generally works > transparently. Once a signed package is available it should be fairly simple > to assure the secure boot keys that need enrolling are positioned on the ESP > for systemd-boot to enroll during the next reboot. > > > > > [1] https://pagure.io/releng/issue/10765 > > [2] https://bugzilla.redhat.com/show_bug.cgi?id=2106706 > > [3] https://github.com/rhinstaller/anaconda/pull/4368 > > > > In general, I think it'd be nice to make the process of installing sd-boot much > > much simpler than it is currently. 'bootctl install' takes care of installation > > process, if the system already has the expected layout. So the installation procedure > > for Fedora should be just 'dnf install …' of a single package. But this doesn't > > currently work because of a few issues: > > > > 1. the /boot partition is formatted with ext4 > > I don't think this is really a problem with the current anaconda + > systemd-boot-unsigned + sdubby package. If the user default installs with > inst.sdboot they get a separate /boot partition, and it continues to hold > parts of the kernel debug/etc packages that aren't needed for boot. The > kernel, initrd and loader entries have all been moved to the /boot/efi ESP > partition under the assumption that systemd-boot systems will have larger > ESPs and the /boot partition can be removed in its entirety. This works > quite well today if the user uses the inst.sdboot option and simply deletes > the /boot partition with the partition tools in anaconda. It is possible to not have the XBOOTLDR partition (i.e. /boot), and only use ESP (i.e. /efi or /boot/efi) to hold kernels. In particular, when the ESP is created by the installer. But in the general case, we want XBOOTLDR to also be readable by the firmware if it is present. This matters for two cases: - installation onto systems where ESP already exists (e.g. dualboot) - switching from grub2 to sd-boot on previously installed systems. So while it's not a blocker, in the long run we should make this switch. > > 2. partitions don't have parttype uuids conforming to Discoverable Partitions Spec [4] > > (or has this been fixed? I need to check.) > > I'm not sure this is needed either given the kernel + initrd is on the ESP. We want for other reasons too. It makes things autodiscoverable and just nicer in general. > > 3. grub2 and shim carry files directly in their rpm payload, hardcoding paths and > > causing any changes to layout to conflict with what rpm thinks about the file system. > > (This part was discussed on fedora-devel recently too.) > > The anaconda inst.sdboot option explicitly doesn't install grub, grubby, > grub efi tools, nor shim. Although as noted in the review comments the > sdubby package "pins" the install location that bootctl/etc are aware of. > Which IMHO isn't a problem given the above. > > https://bugzilla.redhat.com/show_bug.cgi?id=2134972 > > And as I mention in that ticket I'm not sure I view it as a problem either > since fedora has an existing filesystem layout, and something has to make > the choice about where the files are located and that is usually the > responsibility of rpm/etc on fedora systems since it also aids in auditing > the files, dealing with updates, etc. I'm personally not super happy using > `bootctl install` to move the EFI bootloader executable to the ESP, since I > think its totally unnecessarily now that systemd-boot its its own package, > but that is what anaconda is doing at the moment. ESP and XBOOTLDR are shared with other systems. The installer shouldn't just assume that it can do whatever it wants there. So this means that the logic to do changes there must be different than just "install the file from the rpm". And then if we need to use special handling in some cases, it makes sense to use the same method in all cases. > Nor am I entirely sure the default location it likes to install itself is > "correct" if its being installed without shim, but it does "Work". > > > > > 4. grub2 and grubby and other packages are part of Requires chain in packages [e.g. 5]. > > Point 3. makes this more of a problem. > > Yes, hence: https://pagure.io/fedora-comps/pull-request/838 which is the > minimal change to make it all work. > > > So I filed a change ticket along these lines too: > > https://fedoraproject.org/wiki/Changes/cleanup_systemd_install This looks interesting. Thank your for working on thsi. (I think the title could be improved. We generally use "Capitalized_Titles_with_Underscores" and this isn't really about "systemd install".) Zbyszek _______________________________________________ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
