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

[Lennart Poettering]

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?

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

Lennart

--
Lennart Poettering, Berlin