>We (Red Hat boot loader engineering) will present our solution to this problem, which is to use the Linux kernel as its own bootloader. Loaded by the EFI stub on UEFI, and packed into a unified kernel image (UKI), the kernel, initramfs, and kernel command line, contain everything they need to reach the final boot target. All necessary drivers, filesystem support, and networking are already built in and code duplication is avoided.
That has been doable for a few years already. What's the new part?
Right before that paragraph, they cite issues with GRUB as a motivation for this work. What confuses me is that Redhat already has a GRUB replacement in systemd-boot. Is this work intended to obviate that as well, or is it going to relate to it somehow? I imagine doing all this and tying it to systemd would generate some backlash like usual (although at this point, it seems unlikely that this would affect the plans given how few distros don't use systemd).
>I imagine doing all this and tying it to systemd would generate some backlash like usual (although at this point, it seems unlikely that this would affect the plans given how few distros don't use systemd).
systemd-boot is independent of systemd. It's called "systemd-" because it's under the same "group of core OS software" umbrella named "systemd", but otherwise it can be compiled independently, does not require the OS to be using systemd, etc.
Edit: I also wrote originally that switching to systemd-boot would also require switching the kernel from vmlinuz+initramfs to a UKI, but I forgot systemd-boot does support vmlinuz+initramfs through explicit loader entries config.
>To be clear, systemd-boot doesn't replace GRUB, in that systemd-boot can only boot other EFI binaries, so it still requires the kernel to be compiled as a UKI. A GRUB setup with a regular vmlinuz + separate initramfs in root partition (or boot partition that's not the ESP) can't be replaced with systemd-boot directly. You first need to switch to a UKI-in-ESP setup.
> systemd-boot is independent of systemd. It's called "systemd-" because it's under the same "group of core OS software" umbrella named "systemd", but otherwise it can be compiled independently, does not require the OS to be using systemd, etc.
I think my confusion here is that calling something "systemd-" because it's part of the group called systemd is tautological; anything that's independent could just as easily not be included in that group and not be called that. `nmbl` sounds like a piece of "core OS software", so why couldn't it be included in that group as well? It almost sounds like the only reason not to is to avoid naming confusion between multiple things in the "systemd group of software" that are boot-related, and that seems kind of silly.
To be clear, I'm not taking a pro- or anti-systemd in this thread; my concerns come from a place of pedantry around naming rather than anything technical. It just feels weird to me that the name "systemd-boot" could plausibly have been applied to either the bootloader or the "no-more-bootloader" if the other didn't exist, and I wish that things were named in a way that actually conveys using information rather than arbitrarily attaching confusing branding.
Think of Systemd like GNU. They stick their name on all the software they make, even if it doesn't require only using their software. E.g. you can use GNU BASH without using GNU Sed. You can use Systemd-boot without using Systemd-journald.
I agree, I don't think this is actually 'new' at all. We have had EFI Stubs, KExec/KSplice (Heads as a loader distro for example) and non-GRUB options for a while.
At best, this approach doesn't make the boot loader 'go away', it just moves that task to EFI. Which means you depend on EFI instead of GRUB. This isn't really different from say, U-Boot, where you have a bootrom (usually in the SoC or ROM) that does bringup, then U-boot as an intermediary, and then the Linux Kernel. Same deal with BSP and Coreboot, or Bochs or any of the other boot protocol launchers.
Maybe if their scope is the narrowest of all the scopes (only x86 and only UEFI 2.0 and higher and only specific distros) it might make sense, just to have it be invented in-house as a fake moat. But the end-user doesn't really benefit (as there is no change), and other distros are unlikely to care. You do get a dependency on IBVs and OEMs to implement their UEFI correctly, which most have a hard time doing as it is. And you can't re-use it anywhere else, except maybe SystemReady ARM servers.
>We (Red Hat boot loader engineering) will present our solution to this problem, which is to use the Linux kernel as its own bootloader. Loaded by the EFI stub on UEFI, and packed into a unified kernel image (UKI), the kernel, initramfs, and kernel command line, contain everything they need to reach the final boot target. All necessary drivers, filesystem support, and networking are already built in and code duplication is avoided.
That has been doable for a few years already. What's the new part?