On Mi, 01.07.20 22:55, John M. Harris Jr (johnmh(a)splentity.com) wrote:
We don't need more systemd-bloat just to boot our systems. However your
bootloader works, it doesn't really matter if it's not up to snuff with GRUB2.
When it supports LUKS, LVM, LUKS+LVM, a recovery console and several
filesystems, then it'll be more of a viable option, and I still wouldn't
recommend having yet another systemd component as a core part of our systems.
At what point is systemd large enough that you'll stop adding more cruft?
sd-boot is tiny precisely *because* it doesn't implement storage
stacks, file systems, and drivers. I think it's the big problem of
Grub that it goes down that road even on EFI, as all that is a
redundant reimplementation on EFI where the firmware *itself* already
implements a basic storage stack you *have* to rely on, and you cannot
escape from. So booting Linux via Grub on EFI means you have a chain
of three storage stacks: the without doubt crappy EFI one, the
questionnable one in Grub and finally the pretty OK one in Linux. To
boot a reasonable system on EFI you cannot really escape the storage
stack on Linux, and the storage stack of EFI. However, why would you
plug a third one in the middle? sd-boot just says: no, let's not do
that. Loading a kernel and an initrd off disk is not hard, if we have
to use the EFI firmware to load the boot loader off disk anyway, then
it's OK to also load these two files off disk as well with it.
This makes sd-boot tiny, and simply the entire opposite of "bloat".
If you want to talk about "bloat": grub is a more or less complete OS
these days, it slowly but surely reimplements a major section of the
Linux OS, with complex storage and file systems, including write
access. All that even with little sympathy from the Linux fs
developers who made clear in the past they have little interest in
supporting alternative implementations of their fs (see this very
mailing list's discussion about xfs support in grub for more info).
And yes, EFI is an OS too, it also implements drivers and file systems
(much fewer though). Key here though is that the OS it implements is
an OS you *cannot* escape: if grub is used it's that EFI OS that will
load your grub binary. sd-boot just goes one step further and says: oh
well, instead of loading just the boot loader of disk via EFI, let's
load the kernel/initrd off disk with it too. If loading the EFI
loader like this worked, then loading the kernel/initrd off disk via
the very same APIs hsa the best chance to work.
You know, Grub made some sense back in the old days before EFI was in
the mix, because the old MBR boot protocol was such a simplistic
scheme that it only had sector access and not even the most basic file
system support, but you almost always want basic fs support, even if
all you want to do is show a boot menu. Hence back then adding some
basic fs support to Grub definitely made sense.
But now we live in a world where firmware can do that anyway, and you
cannot avoid it, and hence you might as well use it for two more files
than just the boot loader itself, and remove a redundant
reimplementation of a full pretend-Linux-compatible storage stack out
of your boot loader.
TLDR: boot loader should be simpler and not needlessly reimplement LVM
and xfs. If there's "bloat" here anywhere, it's probably these
reimplementations of LVM and xfs, but not in sd-boot that avoids all
Lennart Poettering, Berlin