systemd boot instead of grub

The Wrong Default in 2026

GRUB became the default Linux bootloader during the BIOS era. It
handled MBR partition tables, chainloading other operating systems,
custom kernel configurations through a Turing-complete shell-like
language, network boot through PXE, and a dozen other capabilities
that the typical Linux system genuinely needed in 2005. The
codebase reflects this. GRUB is approximately a quarter of a million
lines of C, with its own scripting language, a configuration
generator that produces config files, and a multi-stage boot
process inherited from the BIOS world.

On a modern UEFI system that runs exactly one operating system,
almost none of this complexity is necessary. The motherboard
firmware already does what GRUB's early stages used to do. The
boot entry is a single UEFI binary that the firmware loads
directly. The kernel selection is a directory of small text files.
The chainloading machinery is unused because there is no second
operating system to chainload. The configuration generator runs
every kernel upgrade to produce a file that could have been three
lines if it had been written by hand.

systemd-boot is the bootloader written for this case. It is
approximately thirty thousand lines of C. It has no scripting
language. It has no config generator. It boots UEFI binaries from
the EFI System Partition with a list of available entries declared
in plain text files. On a single-OS UEFI system it does what GRUB
does, in a fraction of the code, faster, with less to go wrong.

What the Smaller Bootloader Buys You

The case for systemd-boot on the single-OS UEFI case is not
ideological. It is operational, and it has three specific
dimensions.

Boot speed. systemd-boot loads in tens of milliseconds rather
than the seconds GRUB takes to render its menu, parse its
configuration, and probe its modules. On a system that boots once
a week, this is invisible. On a system that reboots after every
kernel update, the difference is noticeable. On a hypervisor that
needs to come back fast after a power event, it matters.

Attack surface. GRUB has had multiple high-severity CVEs over
the past decade, including the BootHole vulnerability disclosed in
2020 that affected essentially every Linux installation with
Secure Boot. The fixes propagated through distribution security
trackers across most of 2021. systemd-boot has had a smaller
number of CVEs over the same period, and its smaller codebase
means audit and patch cycles are correspondingly shorter. The
security calculus is not that systemd-boot is invulnerable. It is
that the surface to defend is smaller.

Operational legibility. A GRUB configuration file is generated
by grub-mkconfig from /etc/default/grub and the contents of
/etc/grub.d/. The output is a script several hundred lines long
that the user is not expected to edit, because the next
regeneration will overwrite it. A systemd-boot configuration is a
directory of small text files in /boot/loader/entries/, one per
boot option, each containing a half-dozen lines of key value
pairs. The kernel command line is in one file. The kernel path is
in one file. The initramfs path is in one file. You can read your
boot configuration without consulting documentation.

The Boot Loader Specification

The reason systemd-boot's configuration looks so different is that
it adopts the Boot Loader Specification, an open standard
documented at systemd.io/BOOT_LOADER_SPECIFICATION/. The
specification defines the file format that boot loaders can read
to enumerate available kernels, the directory structure on the
EFI System Partition, and the kernel-install integration that
makes new kernels appear automatically without rewriting any
configuration.

The specification is not exclusive to systemd-boot. The Boot Loader
Specification has been adopted by GRUB in BLS mode and by other
bootloaders. The point is that the file format is documented,
human-readable, and stable across releases. A kernel installed
through kernel-install shows up in the boot menu without any
configuration regeneration step. The new kernel is a new file
under /boot/loader/entries/. The boot loader notices and adds it
to the menu.

When You Should Not Switch

systemd-boot is the right choice for single-OS UEFI systems. It is
not the right choice for several specific other cases that are
worth naming.

Multi-boot with non-Linux operating systems. systemd-boot can
chainload other UEFI bootloaders, but the integration is less
polished than GRUB's, and the configuration is more manual. If you
genuinely dual-boot with Windows or another non-Linux system, GRUB
is the more comfortable choice.

Encrypted /boot. GRUB can decrypt a LUKS-encrypted /boot
partition by typing a passphrase at the bootloader prompt.
systemd-boot cannot. If your security model requires the kernel
itself to be encrypted at rest, you need GRUB. Note that most
modern setups instead encrypt root via LUKS and leave /boot
unencrypted but on a verified-boot path, which is what
systemd-boot supports natively.

BIOS systems without UEFI. systemd-boot is UEFI-only. On any
hardware that does not have UEFI firmware, the choice is GRUB or
one of the other BIOS-era bootloaders. This case is rare in
hardware purchased after approximately 2014.

Specialized network boot or exotic kernel arguments. GRUB has
a richer feature set for network booting via TFTP and for
runtime-modifiable kernel parameters. If your workflow depends on
these features, GRUB is doing genuine work for you.

For everything outside these cases, which is most Linux systems on
most modern hardware, systemd-boot is the right default.

Closing

The defaults you inherited from 2005 are not the right defaults
for 2026. GRUB earned its position as the default Linux bootloader
in an era when the BIOS world it was built for actually existed
and the multi-boot scenarios it solved were common. The era has
ended for most users. The default has not changed because the
default rarely changes, regardless of whether it is still correct.

systemd-boot has been mature, stable, and Boot Loader Specification
compliant for years. The Debian installer has supported it as an
option in Expert Install since Debian 12. Fedora Workstation has
shipped it as the default since version 36. Arch's installer
recommends it. The ecosystem has moved. The single-OS UEFI Linux
system that you boot tomorrow morning would, for almost every
operational measure, be better served by it than by GRUB.

The next time you install Debian on hardware that has UEFI and
will run only Debian, pick systemd-boot from the Expert Install
bootloader question. Twenty seconds of saved boot time, a smaller
attack surface, a configuration you can read without consulting
documentation, and one fewer 250 000-line bootloader codebase
running on your hardware. The right choice is no longer the
default. Make it deliberately.