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

[Zbigniew Jędrzejewski-Szmek]

On Wed, Apr 27, 2022 at 08:55:55AM -0400, Neal Gompa wrote:
> On Wed, Apr 27, 2022 at 6:47 AM Zbigniew Jędrzejewski-Szmek
> <zbyszek at in.waw.pl> wrote:
> >
> > On Tue, Apr 26, 2022 at 07:12:02PM -0400, Neal Gompa wrote:
> > > Hey all,
> >
> > Hi Neal,
> >
> > thank you for starting the discussion. I think it'd be good to figure
> > out what are the high-level options we have as a community…
> >
> > > 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
> >
> > You mentioned that a few times, and we (at least Lennnart and I) have
> > asked for details. If there's something important missing from sd-boot,
> > we would like to know.
> >
> 
> I think this is probably a distraction from this discussion, but sure
> I guess I can answer: I fundamentally dislike systemd-boot because I
> feel it's not a very user-friendly boot manager because of its
> absolutely spartan interface. I'm much more of a fan of rEFInd[1],
> which provides a feature-rich and user-friendly EFI boot manager[2].

Ah, icons and graphics ;) Yeah, we don't provide that, and I don't think
there are any plans to work on this. Instead of trying to make the menu
better, we can follow the example of windows: integrate the boot menu
directly in the graphical environment. We already have command-line access
to this: bootctl reboot-to-firmware, bootctl set-oneshot,
systemctl reboot --boot-loader-entry=. With a little bit of integration
users should be able to select the system / kernel to boot directly
from the reboot dialogue.

Rebooting from the DE has advantages: nice UI without much work, l10n,
accessibility, help, integration with normal auth mechanisms (e.g. polkit
auth for non-default boot entries or firmware setup), no need to
fiddle with pressing keys at the exactly right time.

> Essentially, the Koji build channel for secure boot is made up of three things:

[snip]

Thanks for the description. If the limitation that only RH folks can
build the official package is true, it'd be annoying, but not such a big
issue. In the recent times, I made the most builds, with Adam Williamson
and Yu Watanabe also doing an occasional build, i.e. all RH employees. It
is important that people can do pull requests for dist-git, but limiting the
offical builds to a few people wouldn't be a big issue. (Don't get me wrong:
I would prefer to keep the current state where a bunch of maintainer *and*
any proven packager or relengee can build systemd, but in practice it doesn't
happen much.)

> For sd-boot, it'd be making sure the package is "ExclusiveArch:
> %{efi}", then in %install, you'd do:
> 
> pushd %{buildroot}%{_prefix}/lib/systemd/boot/efi
> %pesign -s -i systemd-boot%{efi_arch}.efi -o systemd-boot%{efi_arch}.efi.signed
> popd

https://src.fedoraproject.org/rpms/systemd/pull-request/77
does the deed. PTAL. (Though it just conditionalized the build on
%ifarch %efi, instead of limiting where the package is built. In mock
this produces an additional .signed thingy that 'bootctl update'
should pick up automatically.)

Zbyszek