On Saturday, July 4, 2020 9:19:34 AM MST Lennart Poettering wrote:
If it way my decision I'd propose the following as the path to
the
future:
1. Unify/standardize on the boot loader spec, not the boot loader
2. Let's use UEFI as model and make MBR boots more alike UEFI then the
other way round (right now, UEFI boots in grub are considered a
special case, and booting on UEFI is attempted to be as close as
possible to MBR). i.e this is a race-to-the-bottom
vs. race-to-the-top issue: make the stuff that doesn't work like
today's industry standard work like it, and don't make today's hw
work like the industry standard of yesteryear.
GRUB2 + BIOS boot is currently the best way to boot a system, as it actually
supports situations such as full disk encryption, boot from btrfs or ZFS,
including ZFS with native encryption.
Specifically this means:
a. Teach grub proper boot loader spec support (and maybe boot loader
interface support too,
i.e.
https://systemd.io/BOOT_LOADER_SPECIFICATION +
https://systemd.io/BOOT_LOADER_INTERFACE)
That systemd throws some crap out doesn't make it a standard. There's no
reason for GRUB to adopt this, or for anyone else to use this.
b. Prepare a static no-module build of Grub that reimplements
roughly
how booting on EFI works: i.e. support only VFAT file systems, then
search for suitable partitions (ESP/XBOOTLDR), and retrieve boot
loader spec entries from them, and populate the menu by it, and
that's it. Do this the same way on all archs we support, regardless
if MBR or ARM or EFI boot protocols.
There is even less reason to *remove* features from GRUB, to make up for the
alternative bootloaders having less.
As I understand a good chunk of a/b already exists.
With these changes it doesn't matter too much which boot loader is
used, it can be sd-boot or Grub. Or it could even be the native boot
loader spec support in firmware (i.e. LinuxBoot). It doesn't matter
anymore.
Please note that projects such as Libreboot (blobless coreboot with GRUB as
the payload) currently assume that the installed system either uses GRUB2 or
syslinux/isolinux.
but the effect of this approach would be great: suddenly
"systemctl
kexec" and "systemctl reboot --boot-loader-entry=" would jus twork for
all these boot loaders, and installers could all understand each
other's drop-ins and logic, on all archs... And you could switch boot
loaders any day and there's a major chance things would just work. You
could multi-boot between Linux distros without having the boot loaders
overwrite each others data all the time.
How does `systemctl kexec` differ from `kexec`? Can it not simply use `kexec`
under the hood? What's the benefit of supporting `--boot-loader-entry=`?
You can already multiboot between Linux distros, and we've been able to do so,
as well as between other families of OS, for about two decades now.
Note that I personally would actually prefer if the firmware would
natively implement the boot loader spec and we wouldn't have to have
sd-boot around at all. Such a scheme would be fantastic actually, as
it would remove so many variables from the stack.
sd-boot exists only to add the minimum on top of EFI to make the above
work, i.e. something that in an ideal world would just be subsumed by
the firmware itself.
We don't need more bloat in the UEFI stack. It's already painfully specific to
Windows based platforms, and it's a complete hack that it works for our
systems now. Do you remember the state of UEFI in the RHEL6 days?
--
John M. Harris, Jr.