[systemd-devel] Splitting sd-boot from systemd/bootctl for enabling sd-boot in Fedora

[Zbigniew Jędrzejewski-Szmek]

On Wed, Apr 27, 2022 at 09:31:10AM -0400, Neal Gompa wrote:
> On Wed, Apr 27, 2022 at 7:41 AM Lennart Poettering
> <lennart at poettering.net> wrote:
> It is not very friendly when you're in a failure scenario or have to
> deal with boot stuff.

Well, if you have a boot failure, then a text-based interface is better
than a graphical one. I.e. while we might want to make it easier to discover
disks and state from sd-boot, I doubt that adding support for icons and
themes would be of any help in failure scenarios.

> I know it more or less looks like Fedora's GRUB
> is configured today, but Fedora is an outlier among Linux
> distributions in that it doesn't theme GRUB or provide more
> user-friendly boot configure out of the box. I don't like it and I'd
> like to change this someday.

E.g. the biggest development in how the boot looks in recent years
in Fedora has been hiding on the boot menus and boot messages by
default. I.e. the _design_ is that you start with the logo of the
manufacturer which is seamlessly replaced by the gdm login screen.
How the boot menu looks never factors into any of this.

> Well, if you're installing and managing EFI binaries (as bootctl
> does), you can design a scheme to allow bootctl to know what to do in
> those circumstances.
> 
> As a back of the napkin example, say you offer the user three EFI boot
> manager options: rEFInd, sd-boot, or GRUB. The distribution may prefer
> GRUB, sd-boot, or rEFInd, and define that as a config file for bootctl
> to read. But if the user wants to override this choice, they could
> pass --bootloader=<name> to the install subcommand. That would write
> out a config file in /etc/systemd/boot declaring which bootloader the
> user chose as the "default" for future bootctl invocations and allow
> the commands to work.

--bootloader=<name> sounds like something we can do. OTOH, I agree
with what Lennart wrote elsewhere: we don't want to get into the
business of fiddling with special files that'd be specific so some
bootloader.

Currently the update command only does the update if it find sd-boot.
We could enhance it to update other installations (if it find matching
files under /usr/lib somewhere. (I'd rather make it /usr/lib/boot/<name>,
but I think we can talk about directory names later.)

> The bootloaders themselves could be stored in
> /usr/lib/systemd/boot/efi/<name>/, where <name> is the bootloader name
> passed to bootctl. It would then know to copy all the files from that
> directory into the ESP.
> 
> > > The second problem is because having sd-boot in the systemd source
> > > tree means that in order for Fedora to sign the boot manager EFI
> > > binaries, we have to lock down the systemd source package to the
> > > secure boot Koji build channel. This is unequivocally unacceptable
> > > from my point of view, as the restrictions around the secure boot
> > > channel make it realistically impossible for community contribution
> > > and maintenance of the package.
> >
> > I don't follow. Where's the problem using the same source package for
> > two independently built RPM packages?
> >
> > If Fedora wants to build systemd userspace packages one way,  and
> > systemd-boot another way, that's entirely fine actually. they can just
> > do that…
> >
> > > Realistically, I think if we want to make movement on making
> > > systemd-boot fully supported in Fedora, the systemd-boot boot manager
> > > code itself should be split out into its own repository with its own
> > > release cadence, while bootctl(1) and related infrastructure remains
> > > in the systemd source tree and evolves to be able to manage arbitrary
> > > BLS-conformant boot managers.
> >
> > Why though? I don't follow? as long as we provide you with a tarball
> > you can build your stuff from it shouldn't really matter if there's
> > more stuff in it you are not immediately interested in.
> >
> > I mean, if you like I could do a "cp systemd-251.tar.gz
> > systemd-boot-251.tar.gz" for you if you want two tarballs instead of
> > one, but I don't see the point?
> >
> 
> As I illustrated in another email[5], decoupling the lifecycle of the
> EFI boot manager code from the rest of systemd would be ideal to not
> make the constraints around building sd-boot with secure boot support
> painful.
> 
> [5]: https://lists.freedesktop.org/archives/systemd-devel/2022-April/047801.html

Apart from the constraint who can build official packages, is there
anything else? If it's just that, that doesn't seem onerous. 

> > > This would also (hopefully) encourage other boot managers to support
> > > the Bootloader Spec configuration model, making it succeed as a
> > > semi-universal abstraction for boot manager configuration.
> >
> > I don't think grub developers really care about bootctl. They probably
> > never heard of it I figure ;-).
> >
> > I am not sure what the reason of the general disinterest from their
> > camp towards integration with userspace/systemd is. But I doubt that
> > a missing reorganization our tarballs is what is stopping them...
> >
> 
> It's a perception that based on your integration of sd-boot with
> bootctl that there is no point for them to do it. The dynamics change
> a lot when bootctl(1) is fully decoupled from sd-boot.

Well, there have already been a few mails here describing how bootctl
is generic and not coupled to sd-boot. So instead of saying that "there
is a perception", can we acknowledge this perception as mistaken and move on?

> I don't have great answers here.
> 
> But I really do think that being able to separate those lifecycles is
> key to allowing Fedora to adopt it as a workable option.

Zbyszek