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

[Lennart Poettering <lennart@xxxxxxxxxxxxxx>]

On Mi, 27.04.22 09:44, Neal Gompa (ngompa13@xxxxxxxxx) wrote:

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

Depends on what you mean by "that" stuff. Different people use
different features. I personally probably use the majority but not all
(i only have x86 machines, so devictree is not something i care about,
and suchlike).

Distros have integreated things to different levels. Arch is pretty
good in making the best of it.

Stuff like the random seed stuff generally just is there, no need to
"use" it really, it just happens there is no UI for that.

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

I think in that case you are referring specifically to the UI
integration of "boot into windows", "boot into boot loader entry",
"boot into firmware" and so on in gdm?

While integrating that in gdm would be fantastic, all the stuff is
exposed on the command line just fine. i.e. i use "systemctl reboot
--boot-loader-entry=…" and things like that all the time.

So, yeah, I am pretty sure "that stuff" is pretty well used, but in
some scenarios more and and in others less.

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

are you saying grub installation on fedora is just dropping some files
and dirs into the ESP now? are you *sure* about that?

i am pretty sure that's not the case, i.e. the weird boot counting
stuff grub is doine actually works with an expicit file that needs to
be created with specific properties, no?

Lennart

--
Lennart Poettering, Berlin