On Mi, 01.07.20 22:55, John M. Harris Jr (johnmh@xxxxxxxxxxxxx) wrote: > Lennart, > > 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? John, 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 that. Lennart -- Lennart Poettering, Berlin _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
