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

Wed Apr 27 13:31:10 UTC 2022

On Wed, Apr 27, 2022 at 7:41 AM Lennart Poettering
<lennart at poettering.net> wrote:
>
> On Di, 26.04.22 19:12, Neal Gompa (ngompa13 at gmail.com) wrote:
>
> > Hey all,
> >
> > 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. 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.

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.

I'm a fan of rEFInd[1], which provides a feature-rich and
user-friendly EFI boot manager[2] that I feel can offer that
experience. It even supports the Discoverable Partitions Spec[3], and
I hope that they'll support the Boot Loader Spec[4] eventually.

[1]: https://www.rodsbooks.com/refind/
[2]: https://www.rodsbooks.com/refind/features.html
[3]: https://systemd.io/DISCOVERABLE_PARTITIONS/
[4]: https://systemd.io/BOOT_LOADER_SPECIFICATION/

> > * bootctl(1) appears to be tightly coupled to sd-boot
>
> Well, kinda. But also not. So if you type "bootctl --help" then you'll
> see three sections of commands. The last section "systemd-boot
> Commands" shows commands that only really make sense for systemd-boot
> as they install/remove/update the boot loader itself. They are the
> only things inherently tied to sd-boot.
>
> The other two sections are useful outside of sd-boot: the first
> section ("Generic EFI Firmware/Boot Loader Commands") is useful on any
> kind of UEFI section, the second section ("Boot Loader Specification
> Commands") on all boot loaders that implement the (upstream) boot loader
> spec/boot loader interface, as documented.
>
> Note though that at this point grub does not implement either of the
> specs properly, or has any upstream work in that area to my
> knowledge.
>
> > The first problem is mostly because I think bootctl(1) is a fantastic
> > interface to manage *any* Bootloader Spec[4] (BLS) conformant boot
> > manager, and I would love for that tool to be useful for doing so.
> > Being able to do things like install/upgrade/swap GRUB 2,
> > systemd-boot, or any other registered BLS-enabled boot manager would
> > make it tremendously useful and valuable as a "building block" tool.
>
> As mentioned the commands in the first two sections of the --help
> blurb should work just fine with other loaders, and the reason the
> sections exist in the --help text is to help making this clear.
>
> > I feel it would make sense to offer some kind of configuration to
> > teach bootctl(1) about these boot managers so that it can work for
> > them, and not just systemd-boot.
>
> So the commands in the first two sections already should work with any
> boot loader implementing these specs. I am pretty sure that bootctl
> should not be adjusted to specific boot loaders needleslly, instead
> the bootloaders should just implement the specs...
>
> Implementing the specs after all is not something that just is
> relevant for bootctl only. After all there's a lot of hookup to the
> two specs in logind too (for example, reboot into Windows, reboot into
> boot loader entry xyz, and so on), or in the kexec-based reboot
> functionality. And a lot of other stuff as well…
>
> So we kept these things reasonably generic via making this specs so
> that any other boot loader can be plugged in there. But I think real
> interest in adding support for the specs in those other boot loaders
> appears to be minimal unfortunately.
>
> 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 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.

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

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

> > We could then teach our tooling in Fedora to interact with
> > bootctl(1) to do bootloader things, rather than having to create
> > multiple tools and scripts to deal with this.
>
> Well, you can use bootctl already just fine for the commands from the
> first to sections in the --help text as mentioned — as long as your
> boot loader of choice implements the spec.
>
> > The alternative, of course, is to build sd-boot by having a second
> > source package of the systemd code and setting it up to only build the
> > boot stuff. This is painful for a variety of reasons: it guarantees we
> > need to have some kind of synchronization point to ensure fixes and
> > improvements are carried between the two.
>
> Why would you need that synchronization point?
>
> While sd-boot is built from the same systemd tree as the userspace
> components it's totally OK to run it in combination with older or
> newer userspace actually. We generally try to make this independent,
> since for us it is important that you can use sd-boot to boot multiple
> OSes, i.e. the boot loader is a single per-system resource, that needs
> to be shared by all participating OSes installed on the same
> system. i.e. in a theoretic system where suse, ubuntu and fedora all
> support the boot loader spec properly and you install all three on the
> same host, then they should be able to cooporate nicely, hence must be
> able to work well if the boot loader they end up using is slightly
> different from the one they themselves would install.
>
> How do we achieve this? First of all, the interface between sd-boot
> and userspace is relatively minimal and fixated in specs or
> documentation (i.e. efi vars, and the aforementioned specs). Moreover,
> the boot loader actually reports to userspace which features it
> specifically supports via an efi var. This is in fact the
> checkmark/crossmark table that bootctl shows you when you run it.
>
> Note thta these days, there's som nontrivial code shared between the
> EFI and userspace side of things. That's easy now because it comes
> from the same build tree. It would be much harder and a
> dependency/versioning mess if we'd split this up, and still share this
> code. And in the future I actually would like to share *more* code
> here, not less. After all, right now the boot loader spec parsers in
> userspace (i.e. what bootctl does) and the ones in uefi space
> (i.e. what sd-boot does) are distinct pieces of code. Which sucks, we
> should unify that.
>

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.

--
真実はいつも一つ！/ Always, there's only one truth!