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

[Neal Gompa]

On Wed, Apr 27, 2022 at 10:13 AM Zbigniew Jędrzejewski-Szmek
<zbyszek at in.waw.pl> wrote:
>
> 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.
>

Windows also provides a functioning graphical boot manager since at
least Windows 10.

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

It also has a major downside that in the event the OS doesn't boot,
you don't have a friendly way to do recovery. Nowadays both Windows
and macOS provide graphical boot managers and graphical
tools/environments for recovery. These are both things I want in
Fedora as well.

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

Note that it means Fedora CI, pull requests from contributors, and
releng auto-rebuilds will no longer work. Maintainers basically
sign-on to do all of those things manually and have to be responsive
for doing it. You will get FTBFS tickets every cycle because of it,
for example.



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