Hi,
On 6/22/23 11:21, Daniel P. Berrangé wrote:
On Thu, Jun 22, 2023 at 04:59:38PM +0100, Aoife Moloney wrote:
>
https://fedoraproject.org/wiki/Changes/cleanup_systemd_install
>
> This document represents a proposed Change. As part of the Changes
> process, proposals are publicly announced in order to receive
> community feedback. This proposal will only be implemented if approved
> by the Fedora Engineering Steering Committee.
>
> == Summary ==
> Fedora default installs with a shim + grub bootloader on EFI
> platforms, yet has been shipping systemd-boot in various forms for a
> number of releases. There are a few howto's which describe how to
> replace grub with systemd-boot with varying levels of functionality.
> This should be easier with a formalized default method that can be
> built upon. This proposal aims to complete the work started with
> anaconda (inst.sdboot), kickstart (bootloader --sdboot) such that the
> "everything" media can install a grub free machine.
snip
> Beyond that there are various enhancements which can be made to remove
> the /boot partition (leaving the EFI at /boot/efi), enrolling fedora
> keys if the secure boot mode is "Setup", adding options to enable
> shim+systemd-boot, assuring that there is a systemd-boot-signed
> package, etc.
This is the $million question to - is there any proposal and/or agreement
by relevant maintainers, to start signing systemd-boot with Fedora SecureBoot
certs yet ? Without that, sdboot looks destined to remain a niche use case.
I think there remain a number of open questions, WRT how systemd-boot
will settle down. In this case, AFAIK there is an open fedora infra work
item for signing it, per zbyszek, who I've put on CC in case he misses
this discussion. Of course due to the fact that not every platform has
UEFI, and there are features in grub which aren't/shouldn't be
duplicated in systemd-boot means that it will never be capable of 100%
replacing grub on every platform.
If that's part of this proposal, then it feels more like a system-wide
change, than self-contained.
Well given it only affects a couple packages, and is optional, I flipped
a coin and said its not really system wide, but given its in the boot
path I do see the argument the other way as well.
But, IMHO the largest change is moving the boot kernel/initrd to the
ESP, rather than the use of systemd-boot itself. Given the filesystem
layout remains the same outside of those two items and the BLS entries,
all the common tools (dracut/etc) seem to be able to deal with it, and
random other packages not manipulating kernel/initrd images are behavior
should not be affected anymore than putting reFind/whatever in the boot
path.
Thanks,