vault

Boot Loaders Beyond GRUB

14 min read

Boot Loaders Beyond GRUB

GRUB is the default Linux bootloader, but it is not the only one, and on many modern systems it is no longer the best one. The alternatives split along two axes: what firmware they target (legacy BIOS vs UEFI vs embedded boot ROMs) and how much they do (a full scripting environment like GRUB, versus a thin menu that just lists pre-described entries, versus nothing at all). At the minimal end sits systemd-boot (sd-boot), a UEFI-only boot manager with no config language that simply lists Boot Loader Specification entries from the EFI System Partition. rEFInd is a graphical UEFI manager that auto-detects kernels and operating systems. The syslinux family (SYSLINUX, ISOLINUX, PXELINUX, EXTLINUX) is the lightweight choice for install media and PXE network boot. U-Boot is the de-facto standard on embedded and ARM systems, with its own staged loader (the SPL) and image format (FIT). And at the absolute minimum, the kernel’s own EFI stub — optionally wrapped as a Unified Kernel Image — lets UEFI load vmlinuz directly with no bootloader at all. This note surveys each and gives an honest “when to choose” comparison, pinned to current upstreams (systemd man pages, U-Boot docs, Linux 6.12 LTS) as of mid-2026.

This note assumes familiarity with the boot relay (firmware → bootloader → kernel) and with GRUB as the baseline. It deliberately does not re-explain GRUB’s internals — see that sibling note — and treats the EFI stub and UKI only at the survey level, deferring mechanism to The EFI Stub and Unified Kernel Images.

Mental Model

The central realization is that “bootloader” conflates two jobs that modern designs split apart: (1) getting the kernel into memory and jumping to it — a job UEFI firmware can now do itself for any PE/COFF binary — and (2) choosing which kernel, i.e. the menu. GRUB does both in one large, scriptable program. The alternatives each make a different cut:

  • systemd-boot / rEFInd keep only the menu job and delegate the loading job to UEFI (they hand kernels to the firmware as EFI executables, or rely on the EFI stub). They are boot managers, not boot loaders in the old sense.
  • syslinux / U-Boot keep both jobs but in much smaller, more specialized packages — syslinux for a specific medium (FAT, ISO, PXE), U-Boot for a specific world (embedded SoCs that have no UEFI at all).
  • The EFI stub / UKI eliminates the separate program entirely: the kernel is the EFI executable, so UEFI’s own boot manager does the choosing and the firmware does the loading.
flowchart TB
  ROOT["'I need to boot a Linux kernel'"] --> Q1{"Firmware?"}
  Q1 -->|"Embedded SoC<br/>(no UEFI/BIOS)"| UBOOT["U-Boot<br/>(SPL → U-Boot proper<br/>→ bootm of a FIT image)"]
  Q1 -->|"Legacy BIOS or<br/>removable install media"| SYSL["syslinux family<br/>(SYSLINUX/ISOLINUX/<br/>PXELINUX/EXTLINUX)"]
  Q1 -->|"UEFI"| Q2{"How much do you want<br/>the loader to do?"}
  Q2 -->|"Full scripting,<br/>multi-OS, BIOS too"| GRUB["GRUB"]
  Q2 -->|"Thin menu over<br/>BLS entries"| SDB["systemd-boot"]
  Q2 -->|"Graphical,<br/>auto-detect kernels"| REFIND["rEFInd"]
  Q2 -->|"Nothing —<br/>let firmware load kernel"| STUB["EFI stub / UKI<br/>(no bootloader)"]

A decision tree for picking a boot loader/manager. What it shows: the first cut is the firmware (embedded SoCs force U-Boot; removable/legacy media favors syslinux; UEFI opens up the rest); within UEFI the cut is how much logic you want in the loader, from GRUB’s full scripting down to no loader at all. The insight to take: on a modern UEFI machine you are no longer obligated to run a heavyweight bootloader — the lighter you go, the smaller the Secure Boot attack surface, which is exactly why systemd-boot and the bare EFI stub have displaced GRUB on many servers and immutable-OS distributions.

systemd-boot (sd-boot) — the Minimal UEFI Manager

systemd-boot, shipped with systemd and also called sd-boot, is described by its own man page as “a simple UEFI boot manager. It provides a textual menu to select the entry to boot and an editor for the kernel command line” (systemd-boot(7)). Two design choices define it. First, it “supports systems with UEFI firmware only” — there is no BIOS version, by design. Second, it has no scripting or configuration language: unlike grub.cfg, you cannot write conditionals or loops. Configuration happens only through a small static loader.conf and through EFI variables set at runtime.

Instead of generating a menu from scripts, sd-boot discovers entries from standardized files on the ESP. It reads two entry types defined by the Boot Loader Specification (BLS):

  • Type #1 entries: “Boot entries defined with… Boot Loader Specification Type #1 description files located in /loader/entries/ on the ESP and the Extended Boot Loader Partition.” These are plain text .conf files with keys like title, linux (kernel path), initrd, and options (the kernel command line) (Boot Loader Specification).
  • Type #2 entries: “Unified kernel images… which are executable EFI binaries in /EFI/Linux/ on the ESP.” These are UKIs — single signed PE binaries bundling kernel + initrd + cmdline.

A Type #1 entry is strikingly simple:

title      Fedora Linux 41
version    6.12.0
linux      /6a9857a.../6.12.0/linux        # kernel, path relative to $BOOT
initrd     /6a9857a.../6.12.0/initrd       # initramfs
options    root=UUID=... rw quiet          # kernel command line

To boot it, sd-boot uses the EFI stub built into the kernel: it tells the firmware to load that linux file (a PE/COFF image, thanks to the EFI stub) with the given initrd and options. The menu lives entirely in those files; sd-boot just enumerates and launches. It communicates state back to the OS through EFI variables under vendor UUID 4a67b082-0a4c-41cf-b6c7-440b29bb8c4f (LoaderEntries, LoaderEntryDefault, etc.), which is how systemctl reboot --boot-loader-entry=... can ask sd-boot to boot a specific entry next time. It is installed and managed with bootctl, and entries are populated by kernel-install. Secure Boot works naturally because what gets verified is the EFI binary (the kernel or UKI) the firmware loads — there is far less loader to sign than with GRUB.

Choose systemd-boot when: the machine is UEFI-only, you run mostly Linux, and you value a tiny, auditable boot surface over scripting flexibility — servers, developer laptops, and especially immutable/atomic distributions that pair it with UKIs.

rEFInd — the Graphical Auto-Detecting Manager

rEFInd (a fork of the older rEFIt) is “a graphical EFI/UEFI boot manager” that presents “a menu of options to the user when the computer first starts up” (rEFInd home, R. Smith). Like sd-boot it is a manager, not a classic loader, and it is “limited to EFI/UEFI systems”: “You will not find rEFInd useful on older BIOS-based computers.” Its distinguishing feature is automatic detection: it scans the ESP and other partitions for OS boot loaders and for Linux kernels, building a graphical, icon-driven menu with little or no manual configuration. It “supports direct Linux kernel booting through the EFI stub, using configuration files named refind.conf and refind_linux.conf” — refind_linux.conf supplies the kernel command line for an auto-detected kernel, while refind.conf holds global settings and optional manual stanzas. It also “supports theming, Secure Boot management, and EFI driver loading” (the latter lets it read filesystems UEFI itself doesn’t, e.g. ext4 or btrfs, via EFI filesystem driver binaries).

Choose rEFInd when: you multi-boot several operating systems (notably macOS alongside Linux and Windows) and want a polished graphical menu that “just finds” everything without writing config — it is the most user-friendly of the managers, at the cost of being beta-quality and a single-maintainer project.

The syslinux Family — Lightweight, Medium-Specialized

Syslinux is not one program but a family of small, single-purpose loaders, each tied to a boot medium (Debian wiki, Syslinux):

  • SYSLINUX — boots “from File Allocation Table - FAT - filesystems.” The classic use is bootable USB sticks and floppies.
  • ISOLINUX — boots “from CD-ROM ISO 9660 filesystems.” This is what most Linux install CDs/DVDs and live images use to start.
  • PXELINUX — boots “from a network server using the Pre-eXecution Environment (PXE) system,” i.e. it is fetched over TFTP by a network-booting machine. The backbone of datacenter/network install (Debian Installer netboot, kickstart deployment).
  • EXTLINUX — boots “from Linux ext2/ext3 filesystems” (and ext4, with documented caveats around the 64-bit feature and btrfs).

All four share a config syntax (syslinux.cfg / extlinux.conf / pxelinux.cfg/default) that is far simpler than GRUB’s. They were designed for BIOS; UEFI support exists but is widely regarded as incomplete relative to GRUB and sd-boot.

Uncertain

Verify: the exact state of syslinux UEFI support and the project’s maintenance status as of 2026. Reason: the upstream syslinux wiki (wiki.syslinux.org) was unreachable during this task (repeated connection timeouts), so the family details here are sourced from the Debian wiki rather than the upstream project, and the “UEFI support incomplete / project largely dormant” characterization rests on widely-repeated community knowledge I could not pin to a fetched upstream primary. To resolve: reach the syslinux wiki or the kernel.org git repo and check the latest release date and EFI status. uncertain

Choose syslinux when: you are building install or live media, or doing PXE network boot — its small size and per-medium specialization make it ideal where a full GRUB install is overkill and you control the medium.

U-Boot — the Embedded and ARM Standard

On embedded systems and most ARM SoCs there is no UEFI and no BIOS — there is a tiny mask-ROM in the silicon that can only load a small blob from a fixed location. U-Boot (“Das U-Boot”) is the universal bootloader for this world, and it solves the “load yourself out of a tiny hole” problem with its own staged design, the SPL.

The SPL (Secondary Program Loader) is a stripped-down first stage whose documented job is: “Sets up SDRAM and loads U-Boot proper” (U-Boot SPL docs). The flow on a typical ARM SoC is: Boot ROM (immutable silicon firmware) loads the SPL into the few kilobytes of on-chip SRAM available before DRAM is initialized; the SPL initializes the external DRAM and then loads U-Boot proper (the full bootloader with its command line) into that DRAM. For the very tightest SRAM budgets there is an even earlier TPL (“Very early init, as tiny as possible”) before SPL. This staging exists for exactly the same reason as GRUB’s BIOS images: the first code to run has almost no memory to work with and must bootstrap a larger, more capable stage.

Once U-Boot proper is running, it boots an OS with the bootm command, which operates on a FIT (Flat Image Tree) image: “U-Boot uses Flat Image Tree (FIT) as a standard file format for packaging images that it reads and boots” (U-Boot FIT docs). A FIT image — structured like a device tree — bundles “Single or multiple kernels, Ramdisks and initramfs images, Device tree blobs (FDT),” and named configurations selecting among them, and it “supports cryptographic protection through signatures and hashes, enabling verified boot.” The bootm syntax bootm [fit_addr]#<conf> selects a configuration, and the U-Boot docs note “Booting using Flat Image Tree (FIT) is recommended” over the older legacy uImage format (bootm docs). The device-tree blob is essential here: ARM has no self-describing hardware enumeration like x86’s ACPI, so U-Boot must hand the kernel a .dtb describing the board.

Choose U-Boot when: you are on embedded hardware, an ARM/RISC-V SoC, a development board, or a router/IoT device — anywhere there is no PC-class firmware. (Note that modern U-Boot can also present a UEFI interface, letting GRUB or the EFI stub run on top of it, which is how some ARM servers boot a standard distribution.)

The EFI Stub / UKI — “No Bootloader”

The most radical alternative is to use no bootloader at all. Modern Linux kernels are built with CONFIG_EFI_STUB, which makes the kernel image itself a valid UEFI application: “a kernel zImage/bzImage can masquerade as a PE/COFF image, thereby convincing EFI firmware loaders to load it as an EFI executable” (kernel EFI stub docs). Copy vmlinuz to the ESP, rename it with a .efi extension (“Without the extension the EFI firmware loader will refuse to execute it”), and the UEFI boot manager can launch the kernel directly. The command line is passed by the firmware (or typed in the UEFI shell), and the initramfs is supplied via initrd= or “a Linux-specific UEFI protocol at boot time” (LINUX_EFI_INITRD_MEDIA_GUID). This is also why the older EFI handover protocol is now “deprecated in favour of the ordinary PE/COFF entry point” per the 6.12 x86 boot docs — the kernel just is the EFI program now.

The practical refinement is the Unified Kernel Image (UKI): rather than juggling a separate vmlinuz, initramfs, and command line, systemd-stub (sd-stub) wraps them into one PE binary “combining various resources inside a single PE binary image (a ‘Unified Kernel Image’ or ‘UKI’ for short), which may then be signed via UEFI SecureBoot as a whole” (systemd-stub(7)). The kernel, initrd, and command line live in PE sections named .linux, .initrd, and .cmdline. Because the whole thing is one signed file, the Secure Boot trust chain has nothing to verify between firmware and kernel — there is no GRUB and no separate initramfs to tamper with. The mechanism is detailed in The EFI Stub and Unified Kernel Images; the point here is that it represents the logical end of the “make the loader smaller” trend: the loader disappears.

Choose the bare EFI stub / UKI when: UEFI-only, security is paramount, and you want a tamper-evident single signed boot artifact — increasingly the default on immutable and confidential-computing distributions. The cost is rigidity: changing the command line means rebuilding (and re-signing) the UKI, which is why a thin manager like systemd-boot is often paired with UKIs to restore a menu without giving up signing.

An Honest Comparison

LoaderFirmwareConfig styleSecure BootMulti-OSBest for
GRUBBIOS + UEFIGenerated grub.cfg (scriptable)via shim; large surfaceexcellentthe universal default
systemd-bootUEFI onlynone (BLS entries)clean (verifies kernel/UKI)Linux-centricminimal UEFI servers/laptops
rEFIndUEFI onlyauto-detect + refind.confvia shimexcellent (incl. macOS)graphical multi-boot
syslinuxBIOS (UEFI weak)simple *.cfgweaklimitedinstall/live media, PXE
U-Bootembedded ROMbootm + FIT / envFIT signaturesn/aARM/embedded/SoC
EFI stub / UKIUEFI onlybaked into imagestrongest (one signed file)nonelocked-down/immutable

The throughline: the more capable and portable the loader, the larger its trusted code and the more there is to misconfigure; the more minimal, the smaller the attack surface but the more rigid the result. GRUB occupies the “do everything everywhere” corner; the EFI stub the “do nothing, let firmware boot the kernel” corner; sd-boot, rEFInd, syslinux, and U-Boot sit at deliberate points between, each optimized for one firmware world or one boot medium.

Failure Modes

  • Picking a UEFI-only manager on a BIOS box. systemd-boot, rEFInd, and the EFI stub cannot boot a legacy-BIOS machine — there is nothing to register with, no EFI System Partition role. The symptom is the firmware never finding a bootable device. Use GRUB (BIOS mode) or syslinux instead.
  • EFI stub kernel won’t launch. Forgetting the .efi extension, or putting the kernel outside the ESP, makes the firmware silently refuse it. The fix is the rename and ESP placement noted above.
  • syslinux on UEFI. Expecting full GRUB-grade UEFI behavior from syslinux leads to frustration; its EFI support lags. For UEFI, reach for sd-boot, rEFInd, or GRUB.
  • UKI command-line drift. Because the command line is baked into a signed UKI, editing /etc/kernel/cmdline without rebuilding the UKI changes nothing — a common surprise for people used to editing grub.cfg or a BLS .conf.

Production Notes

The industry trend through the early 2020s into 2026 has been away from GRUB on locked-down systems and toward the BLS + UKI + systemd-boot stack. Fedora, RHEL, and Arch all ship and document systemd-boot as a first-class option; immutable/atomic distributions (Fedora Silverblue/CoreOS-style, openSUSE MicroOS) and confidential-computing images favor signed UKIs because a single signed artifact is far easier to attest than firmware → shim → GRUB → kernel → initramfs. On the embedded side, virtually every ARM/RISC-V board, router, and single-board computer boots through U-Boot, increasingly via a UEFI shim that lets the same distribution boot media work on a Raspberry-Pi-class device and a PC. rEFInd remains the enthusiast multi-boot favorite, and syslinux/isolinux/pxelinux remain quietly ubiquitous as the thing that starts the installer — most people who have ever booted a Linux ISO have used ISOLINUX without knowing it.

See Also

Graph View