FOSDEM 25: Booting without bootloader

The modular Grand Unified Bootloader in version 2.x is still the boot method used by the installers of most Linux systems. Support for a number of file systems, EFI, secure boot and multiboot make Grub 2.x suitable for many scenarios. However, the source code of Grub 2, which is written in C and assembler, is constantly growing, making maintenance time-consuming and development slow.

A lean, modern alternative especially for EFI systems is Systemd-boot, a minimalist boot loader from Systemd, which starts via EFI boot entry and only shows a boot menu with available kernel versions.

Boot process: One UKI for everything

Then everything can go, says Marta Lewandowska from Red Hat in her talk at FOSDEM 25 – because bootable unified kernel images (UKIs) can do without a boot loader altogether. With this concept, called NMBL for "No More Boot Loader", the generated images contain all the ingredients to boot a system up to the start of the user space. As with Systemd, the actual boot is performed by an EFI boot entry in the firmware, which uses a minimal Grub 2 emulation layer to call up an image including kernel, predefined boot parameters and initial ramdisk with all drivers for file systems or network interfaces.

The image is also signed for an activated secure boot on request. According to Lewandowska, dispensing with other helpers besides EFI for system startup is intended to reduce the administrative effort behind the creation of UKIs and their boot entries. Since no full-blown boot loader is loaded, the system boots very quickly with this new method.

And finally, rebooting to another system in a dual-boot scenario via NMBL is also planned. For this purpose, an EFI boot entry created by NMBL should set the EFI variable "BootNext" with a new path to a bootable binary and then reboot the system. This method has the advantage that it can also be used to boot predefined systems that do not have valid secure boot signatures themselves. This is because only the trusted system can create a boot entry via NMBL and then boot –. The Secure Boot chain of trust would therefore remain intact.

A second boot method of NMBL remains with a conventional approach if hardware or network images require more preparation in the initialization phase in order to start the actual operating system. Here, NMBL first boots the initial ramdisk with a minimal kernel and a small userspace in the style of Grub 2, can thus also show an editable menu for the actual boot entries and then loads the selected system via Kexec. The advantage here is still the absence of a boot loader, because the Linux kernel takes care of all these steps, including the menu display, itself – from a single signed UKI.

Weak point: Faulty UEFI conversions

NMBL is currently still available on Github as a preview version ((https://github.com/rhboot/nmbl-poc/)), which aims to prove the plausibility of this approach. The Linux system chosen for these first practical demonstrations of NMBL is Fedora Linux. The NMBL scripts integrate themselves as modules in Dracut in order to create an initial ramdisk with the usual tools from the standard package sources. However, the Linux kernel started in this way, which Kexec is then supposed to start, is still causing difficulties.

A kernel patch is also required for this to work. Further experiments with NMBL will initially remain in the Fedora environment so that the developers there can maintain the appropriate patches for its standard kernels. In an initial presentation of the project on LWN last summer, the developers also emphasize that their tests to date have largely been carried out in virtual machines with a clean UEFI implementation. Experience has shown that real hardware does not always behave well and predictably. A number of buggy firmwares exhibit non-standard boot behavior in their UEFI versions.

Lennart Poettering, who already criticized NMBL last year, also points out this problem: A lot of the undesirable effects at hardware level set in during the first initialization. His approach with systemd-boot is therefore to load as little as possible, just enough to show a menu for selecting the kernel and initial ramdisk. NMBL, on the other hand, has to do all this with the full-blown Linux kernel in use and a ramdisk, which in his view meant even more effort than using the simplest possible boot loader for EFI entries.

(nie)