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

[Neal Gompa]

On Wed, Apr 27, 2022 at 9:31 AM Lennart Poettering
<lennart at poettering.net> wrote:
>
> On Mi, 27.04.22 08:55, Neal Gompa (ngompa13 at gmail.com) wrote:
>
> > > 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].
>
> Dunno. sd-boot UI was originally based on GNOME designers
> ideas. It's a simple UI doing exactly what is needed, that's how
> designs really should be I believe. Minimal, effective, and given this
> is low-level nerd stuff that people should normally never see I think
> that's already way above what is actually needed.
>
> I personally find the refind UI (judging by the screenshots)
> stylistically problematic, but I'll certainly accept that other people
> have other tastes on that...
>
> So, ignoring how precisely it looks, what exactly is the
> "feature-rich" stuff that you prefer you appear to indicate that
> exists?
>
> To be frank, it seems to not actually bring much to the table that
> might be interesting from a modern Linux userspace perspective,
> i.e. doesn't implement boot laoder spec or boot loader interface, no
> boot counting, no random seed stuff, no certificate enrolling, no tpm
> measurement stuff, no devicetree loading, and so on. Functionalitywise
> it appears to be quite a step back from both sd-boot and in fact
> grub. I'd really prefer if we'd not complicate the boot loader
> question further, by throwing even more half-baked options into the
> mix. I mean, it's fine if this is an option, but more?
>

Can anything actually *use* that stuff today? Like those are all nice
things to have, but as you've mentioned on the Fedora mailing lists
before, most of those things don't work or provide anything in the OS
because no enablement has been done there.

But this is pretty much why I didn't want to talk about this, because
it diverts from the point I was trying to make around enabling sd-boot
as an option.

> > > > The first problem is mostly because I think bootctl(1) is a fantastic
> > > > interface to manage *any* Bootloader Spec[4] (BLS) conformant boot
> > > > manager, and I would love for that tool to be useful for doing so.
> > > > Being able to do things like install/upgrade/swap GRUB 2,
> > > > systemd-boot, or any other registered BLS-enabled boot manager would
> > > > make it tremendously useful and valuable as a "building block" tool. I
> > > > feel it would make sense to offer some kind of configuration to teach
> > > > bootctl(1) about these boot managers so that it can work for them, and
> > > > not just systemd-boot.
> > >
> > > bootctl could be taught to install other EFI stuff. It'd probably be a
> > > matter of specifying a different glob when looking for files to copy.
> > > I'm not sure if we want to get into the business of installing non-EFI
> > > stuff… What exactly do you have in mind?
> >
> > I'm purely talking about EFI boot managers. I would like bootctl(1) to
> > be able to lifecycle any BLS-conformant EFI boot manager.
>
> I think this is unrealistic to be frank. Ignoring this refind thing
> (which I have not much clue about), for grub installation is a lot more
> complex than just dropping a bunch of files+dirs into the ESP. They
> have stages, partitions, boot scripts that need to be generated. I
> think the complexities this involves is a major problem, and certainly
> not something we should make *our* problem.
>

At least in Fedora's grub2 (which is BLS-enabled), this doesn't apply.
All of that is static and we just use BLS snippets. My understanding
is that it *will* be upstreamed, but getting it upstreamed is slow
since the Red Hat grub2 patch set is *huge* and there's not enough
reviewers to go through and get patches into the tree.

And that means there are already two implementations. And there could
be more in the future.



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