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

[Luca Boccassi]

On Tue, 2022-04-26 at 19:12 -0400, Neal Gompa 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*
> a fan of a lot of the mechanisms around it, and I think it would be
> valuable for us to adopt more of that in Fedora. To that end, that
> means making it easier for people to fully adopt systemd-boot on their
> systems in Fedora with minimal effort (ideally just a kickstart or
> Anaconda flag if desired).
> 
> From my point of view as someone working on several Fedora variants
> and would like to provide more optionality around this, there are a
> couple of issues:
> 
> * bootctl(1) appears to be tightly coupled to sd-boot
> * sd-boot is part of the systemd source tree
> 
> 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. 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.
> 
> 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.
> 
> 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.
> 
> 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. 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.
> 
> 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. It is more work from a
> maintenance perspective (especially around security stuff), and it
> doesn't really help with pushing the adoption of the Bootloader Spec
> as a whole.
> 
> What do you all think?

I can't comment on the first point as I don't use/work on bootctl/sd-
boot, but the second one is going to be challenging, after all sd-boot
was merged in the tree explicitly to keep it with the rest of the
system. We like our monorepos here :-)

But having a separate build shouldn't be too much of hassle I think? On
OBS it would work great as a _multibuild package. With Meson 0.60 you
can even have separate install "tags", so the following is very very
quick, you don't need to rebuild the world (and hence have dependency
tracking in the spec file, etc):

$ meson foo
<...>
$ cd foo
$ ninja src/boot/efi/linuxx64.efi.stub
[21/21] Generating src/boot/efi/linuxx64.efi.stub with a custom command
$ ninja src/boot/efi/systemd-bootx64.efi
[10/10] Generating src/boot/efi/systemd-bootx64.efi with a custom command
$ DESTDIR=/tmp/foo meson install --tags sd-boot --no-rebuild
Installing src/boot/efi/systemd-bootx64.efi to /tmp/foo/usr/lib/systemd/boot/efi
Installing src/boot/efi/linuxx64.elf.stub to /tmp/foo/usr/lib/systemd/boot/efi
Installing src/boot/efi/linuxx64.efi.stub to /tmp/foo/usr/lib/systemd/boot/efi

(note 'install --tags' requires
https://github.com/systemd/systemd/pull/23204 )

Would this be a feasible approach?

-- 
Kind regards,
Luca Boccassi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: This is a digitally signed message part
URL: <https://lists.freedesktop.org/archives/systemd-devel/attachments/20220427/af859d08/attachment.sig>