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

[Neal Gompa <ngompa13@xxxxxxxxx>]

On Wed, Apr 27, 2022 at 11:49 AM Zbigniew Jędrzejewski-Szmek
<zbyszek@xxxxxxxxx> wrote:
>
> 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@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.
>
> 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
>

At first I thought we actually fixed something here (and inadvertently
caused another problem), but now I think that's because the package is
not yet restricted. Since it's still a "normal" package, it doesn't
have the restrictions imposed on it yet of which Koji users can do
builds and where it can be successfully built.

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

I don't disagree even in the slightest, but we currently do not
restrict releng to just Red Hatters (which I'm happy about!), so they
can't be blanket allowed.



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