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

[Lennart Poettering]

On Mi, 27.04.22 09:31, Neal Gompa (ngompa13 at gmail.com) wrote:

> > > Some of you might know about the recent discussion in Fedora about
> > > dropping BIOS support[1][2]. While the end result for now is that
> > > we're not dropping it[3], several side discussions involved enabling
> > > systemd-boot as an option in Fedora in the future.
> > >
> > > While I *personally* am not a huge fan of systemd-boot itself, I
> > > *am*
> >
> > I asked this elsewhere already, without getting a reply: why aren't
> > you though? Can you elaborate on what crucial thing you are missing?
>
> It is not very friendly when you're in a failure scenario or have to
> deal with boot stuff.

But how does refind help you in failure scenario? Now you piqued my interest...

> Eventually, I'd like to have a comparable experience to Windows or
> macOS on Fedora, and I just don't see that happening with systemd-boot
> as it stands today.

Hmm, you mean this thing on macos:

https://support.apple.com/library/content/dam/edam/applecare/images/en_US/macos/macos-sierra-startup-disk.png

is that correct? I mean, does it actually offer you to do more than
pick one of these icons and go for it? that's actually less of a UI
than sd-boot if you so will… what else can it do?

i know the windows boot loader can do more, but I think it's fairly in
the territory of having gone too far.

(it has the wifi selector, but i doubt this is relevant for us, so
ignore that).

> > Note that the commands in the last section of the "bootctl --help"
> > text are something we never can make generic really. They are
> > specifically about installing sd-boot in the ESP, I see no avenue
> > about making this a grub installer, sorry...
>
> 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 mentioned elswhere, grub needs to generate a boot script, and has
multiple stages and a separate boot partition iirc. This is not stuff
I want to see in bootctl.

> 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.

I think we systematically disagree on one point here: I am pretty sure
picking a boot loader is genuinely someting a distro should be doing,
and not the admin really. I mean, yes, I personally of course switched
away from Fedora's default choice of grub to use sd-boot, and of
course I'd prefer if it wasn't such a mess to do so. But also: we
should not advertise this as something people should actually do and
should make easy to do.

> 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.

We kinda do that already. But for the "bootctl update" stuff we
actually want to know the version of the boot loaders we install, but
only sd-boot implements a logic for that, how we can know it from the
binary.

> 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.

But why would that be painful? I really don't follow. how we organize
our git tree or what we put together in a tarball should not matter to
the build processs. it's totally ok to decouple, desynchronize the
build process of the sd-boot side and the rest, and that should be all
you need?

> 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.

[citation needed]

> 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.

I don't understand why upstream release lifecycles should have to
propagate 1:1 into RPM build cycles. It is absolutely, totally fine if
Fedora builds userspace systemd RPM packages for 251 today and the
systemd-boot parts 3 weeks later. The builds can be entirely
independent and decoupled. In fact it's even OK if systemd-boot for
example skips a few upstream releases. Our code is tightly coupled at
build time, but at runtime as very losely coupled only, and it is our
explicit goal to ensure that old userspace can work with new sd-boot
and vice versa. Anf in fact work with other boot loaders, if they'd
implement the specs...

Lennart

--
Lennart Poettering, Berlin