No more boot loader: Please use the kernel instead

Original Article ↗ Hacker News Discussion ↗

Red Hat engineers are promoting a “no more bootloader” approach where the Linux kernel, packaged as a unified kernel image and launched via UEFI, effectively replaces GRUB and similar tools. Supporters argue this reduces duplicated code, shrinks the attack surface, and simplifies secure boot by reusing kernel capabilities instead of maintaining a complex, separate boot stack. Critics worry about multi‑boot, advanced storage/encryption setups, kexec reliability, and fear another round of disruptive ecosystem churn akin to past init system changes.

Overview of the proposal

  • Red Hat engineers propose “no more boot loader” (nmbl): use the Linux kernel itself (via EFI stub and UKI images) as the first-stage bootloader.
  • Goal: avoid GRUB’s duplicated drivers, filesystem code, and complex scripting, which are seen as hard to maintain and a security liability.
  • UEFI firmware loads a unified kernel image (kernel + initramfs + cmdline); a small initramfs userland presents a menu, does any needed logic, then either switch_root’s or kexec’s into the target system.

Perceived benefits

  • Less duplicated code: reuse kernel’s mature drivers, filesystems, crypto, networking instead of re‑implementing them in GRUB or other loaders.
  • Potentially fewer security bugs and faster fixes, since kernel code has many more eyes and established processes.
  • Aligns with UKI / Secure Boot / measured boot workflows and simplifies signed‑boot chains.
  • Embedded and specialized systems already often use similar “Linux as bootloader” patterns.

Concerns and criticisms

  • Feels like “another Red Hat/systemd‑style churn”: fear of long-term ecosystem disruption, new tooling, and documentation gaps.
  • kexec reliability: some hardware, GPUs, ACPI, and especially Apple Silicon are cited as problematic for robust kexec-based booting.
  • Worry that complex pre‑boot logic (multi‑OS menus, network boot, ZFS/Btrfs snapshots) will just recreate another large, bug‑prone codebase inside initramfs.
  • Skepticism about tying more of the boot chain to Secure Boot, TPM, and vendor keys; concerns about user lock‑in vs owner control.

Initramfs, modules, and filesystems

  • Debate over whether we should instead aim for “no more initramfs” by compiling everything needed into the kernel or using a smarter loader (FreeBSD‑style).
  • Out‑of‑tree modules (e.g., ZFS) and stacked storage (LUKS, LVM, RAID) make initramfs or equivalent almost unavoidable for generic distros.
  • Some argue UEFI ESP plus kernel‑loaded modules from FAT is a simpler route than elaborate initramfs.

Multi‑boot and user experience

  • Many users still rely on GRUB for:
    • Dual‑booting Linux/Windows or multiple Linux installs.
    • Selecting older kernels, single‑user mode, and recovery.
    • Booting other EFI tools (memtest, shells).
  • UEFI boot menus are widely described as inconsistent, hard to reach, or feature‑poor; some see that as a blocker to “no bootloader” approaches.

Alternatives and existing practice

  • Several existing projects already use “Linux as bootloader”: LinuxBoot, Petitboot, ZFSBootMenu, Oxide’s PHBL, custom kexec setups.
  • Others are happy with simpler options: EFISTUB, systemd‑boot, rEFInd, or even LILO with no initramfs.
  • Thread consensus: idea isn’t new; the value will depend on how well nmbl handles real hardware, multi‑boot, and complex storage without recreating GRUB‑level complexity.