Re: Splitting sd-boot from systemd/bootctl for enabling sd-boot in Fedora

[Neal Gompa <ngompa13@xxxxxxxxx>]

On Wed, Apr 27, 2022 at 11:13 AM Zbigniew Jędrzejewski-Szmek
<zbyszek@xxxxxxxxx> wrote:
>
> On Wed, Apr 27, 2022 at 09:31:10AM -0400, Neal Gompa wrote:
> > On Wed, Apr 27, 2022 at 7:41 AM Lennart Poettering
> > <lennart@xxxxxxxxxxxxxx> wrote:
> > It is not very friendly when you're in a failure scenario or have to
> > deal with boot stuff.
>
> Well, if you have a boot failure, then a text-based interface is better
> than a graphical one. I.e. while we might want to make it easier to discover
> disks and state from sd-boot, I doubt that adding support for icons and
> themes would be of any help in failure scenarios.
>
> > 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.
>
> E.g. the biggest development in how the boot looks in recent years
> in Fedora has been hiding on the boot menus and boot messages by
> default. I.e. the _design_ is that you start with the logo of the
> manufacturer which is seamlessly replaced by the gdm login screen.
> How the boot menu looks never factors into any of this.
>

Hiding them by default doesn't mean making them scary and semi-useless
when you access them. Most people don't access UEFI menus very often,
if at all, and yet a huge amount of investment went into making that
UX better than it was in the past. Is it spectacular? No. Is it less
scary? Absolutely.

Even with rEFInd, I'd probably want to do it that way because the
point of rEFInd is to make the emergency cases and multiboot cases
more approachable, not to present it all the time by default.

> > 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.
>
> --bootloader=<name> sounds like something we can do. OTOH, I agree
> with what Lennart wrote elsewhere: we don't want to get into the
> business of fiddling with special files that'd be specific so some
> bootloader.
>
> Currently the update command only does the update if it find sd-boot.
> We could enhance it to update other installations (if it find matching
> files under /usr/lib somewhere. (I'd rather make it /usr/lib/boot/<name>,
> but I think we can talk about directory names later.)
>

That's more or less what I want. I don't really want bootctl being
*too* smart. Even for sd-boot, it doesn't do that much, and I'd rather
keep it that limited. If you need to do fancier bootloader specific
things, use the appropriate tools.

> > 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
>
> Apart from the constraint who can build official packages, is there
> anything else? If it's just that, that doesn't seem onerous.

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

Koji doesn't conceptually know the difference because there is no
namespacing for builders, only who is approved to build.

(In contrast, in the Open Build Service like what Luca Boccassi was
talking about, packagers don't control the builds at all, so OBS only
has to trust itself to sign it, so everything works properly.)


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