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

Wed Apr 27 15:48:29 UTC 2022

On Wed, Apr 27, 2022 at 11:26:14AM -0400, Neal Gompa wrote:
> On Wed, Apr 27, 2022 at 11:13 AM Zbigniew Jędrzejewski-Szmek
> <zbyszek at in.waw.pl> 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 at poettering.net> 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.

I think you're wrong. Both my scratch build [1] and the CI scratch
build [2] attached to the pull request succeeded w/o issue.

[1] https://koji.fedoraproject.org/koji/taskinfo?taskID=86306226
[2] https://koji.fedoraproject.org/koji/taskinfo?taskID=86306453

If the official releng build fails, that'd be of course stupid (*),
but a) I can live with running a one-line command twice per year,
b) this would need to be done if the package was split out anyway,
so it's strictly more work if the package is split out.

Zbyszek

(*) Stupid on many levels. Not least because releng can do anything
and masquerade as any user.