GRUB can boot almost anything from almost anywhere, at the cost of a configuration system nobody enjoys. systemd-boot does one thing, in about twenty lines, and cannot do several things GRUB can. Which is right depends on facts about your machine.

What each actually is

GRUB is a bootloader with its own filesystem drivers. It can read ext4, Btrfs, XFS, LVM and more, which means it can load a kernel from your root filesystem directly. It supports BIOS and UEFI, chainloads other operating systems, has a scripting language, and a rescue shell.

systemd-boot, formerly gummiboot, is a UEFI boot menu. It does not implement filesystem drivers. It uses UEFI’s own services to read the EFI System Partition and hand a kernel to the firmware.

That single design decision produces every difference between them.

	GRUB	systemd-boot
Firmware	BIOS and UEFI	UEFI only
Reads root filesystem	Yes	No
Kernel location	Anywhere	On the ESP
Config size	Hundreds of generated lines	Around 20
Boot from Btrfs snapshot	Yes	No
Secure Boot	Signed shim path	Usually your own keys
Windows entry	Chainloads	Firmware handles it
Rescue shell	Yes	No

The case for systemd-boot

The config is readable.

# /boot/loader/loader.conf
default  arch.conf
timeout  3
console-mode max
editor   no

# /boot/loader/entries/arch.conf
title   Arch Linux
linux   /vmlinuz-linux
initrd  /initramfs-linux.img
options root=UUID=xxxx-xxxx rw quiet

That is the whole thing. Compare with grub.cfg, which is generated by a shell script from fragments in /etc/default/grub and /etc/grub.d/, runs to hundreds of lines, and must not be edited directly.

Nothing to regenerate. Add a file to loader/entries/, and it appears in the menu. No update-grub, no grub-mkconfig, no forgetting to run it.

It is already installed. Part of systemd, so no extra package on any systemd distribution.

editor no is a real security setting. GRUB’s command line editing lets anyone at the console add init=/bin/bash and get a root shell. Disabling the editor closes that, and GRUB’s equivalent is password protection, which is more configuration.

The case for GRUB

It boots from your root filesystem. Kernels stay in /boot on your normal filesystem, so the ESP stays small and a /boot full of kernels is not a FAT partition.

Btrfs snapshot booting. This is the big one. GRUB can read Btrfs, so it can boot a kernel from inside a snapshot, which is what makes “roll back to yesterday from the boot menu” possible. Tools like grub-btrfs generate those entries automatically. systemd-boot cannot do this at all, because the kernel would have to be on the ESP. Our Btrfs snapshots guide covers the workflow.

BIOS support. Older hardware, some virtual machines, and anything not using UEFI.

Secure Boot without effort. Distributions ship a signed shim plus a signed GRUB, and that chain is accepted by firmware trusting Microsoft’s key out of the box. Our Secure Boot guide covers why that matters.

The rescue shell. When something is wrong, GRUB’s command line lets you find and boot a kernel by hand. systemd-boot gives you a menu with nothing on it.

Choosing

GRUB if: BIOS boot, Btrfs snapshot booting, Secure Boot without enrolling keys, complex multi-boot, or a small ESP you cannot enlarge.

systemd-boot if: UEFI, one or two Linux installs, an ESP of 512 MB or more, and you value a config you can read in full.

It is not a decision that matters much. Both boot Linux reliably. If GRUB works, leaving it alone is defensible; the reason people switch is config simplicity rather than any functional gain.

Switching to systemd-boot

Check the prerequisites

# UEFI, not BIOS
[ -d /sys/firmware/efi ] && echo UEFI || echo BIOS

# the ESP and its size
findmnt /boot/efi /boot
lsblk -o NAME,SIZE,FSTYPE,MOUNTPOINT

# firmware boot entries
efibootmgr -v

The ESP size is where this usually stops. Kernels and initramfs images have to live on it, so 100 MB is not enough. You need 512 MB minimum, and a gigabyte if you keep several kernels.

Enlarging an ESP means moving partitions, which means a backup and possibly a reinstall. If yours is small and full, that is a strong argument for staying with GRUB. Our partitioning guide and /boot guide cover the layout.

Install it alongside

# where is the ESP mounted
export ESP=/boot/efi

sudo bootctl --esp-path="$ESP" install
sudo bootctl status

This copies the loader to $ESP/EFI/systemd/ and adds a firmware boot entry. It does not remove GRUB. Both are now installed and the firmware menu chooses.

Write the entries

# find the root UUID
findmnt -no UUID /

sudo tee "$ESP/loader/loader.conf" <<'EOF'
default  linux.conf
timeout  3
console-mode max
editor   no
EOF

ROOT_UUID=$(findmnt -no UUID /)
sudo tee "$ESP/loader/entries/linux.conf" <<EOF
title   Linux
linux   /vmlinuz-linux
initrd  /initramfs-linux.img
options root=UUID=$ROOT_UUID rw quiet
EOF

The linux and initrd paths are relative to the ESP, not to /. Getting that wrong is the most common mistake.

Copy the kernel command line from your working GRUB config rather than inventing one:

cat /proc/cmdline

That is what booted the system you are currently using, minus the bits GRUB adds itself. Our kernel parameters guide covers what each option does.

Getting the kernel onto the ESP

If /boot is the ESP, kernel updates land there already. If they are separate, something has to copy them on every update.

Arch uses a pacman hook, or kernel-install.

Fedora uses kernel-install natively, which writes entries for you.

Debian and Ubuntu are the awkward case. There is no first-class support, so people use systemd-boot-manager, or a kernel postinst hook, or mount the ESP at /boot directly.

This is the real maintenance cost of systemd-boot on a distribution that does not support it natively. A kernel update that does not copy the new kernel across leaves you booting an old one, or nothing.

# the modern way, where the distribution supports it
sudo kernel-install add "$(uname -r)" /boot/vmlinuz-"$(uname -r)"
bootctl list

Test before removing anything

# what the firmware will try
efibootmgr -v

# make systemd-boot first
sudo efibootmgr -o 0001,0002

# or choose once, from the firmware menu, at the next boot
sudo systemctl reboot --boot-loader-menu=0

That last command shows the boot menu on the next restart only, which is the safe way to try it.

Boot successfully several times before removing GRUB. Then:

sudo apt remove grub-efi-amd64        # only once you are sure

There is rarely a reason to remove it at all. A GRUB install sitting unused on the ESP costs a few megabytes and is a working fallback.

Going the other way

sudo apt install grub-efi-amd64
sudo grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=GRUB
sudo update-grub
sudo efibootmgr -v

Then move kernels back to /boot if you had relocated them, and confirm update-grub found everything before rebooting.

Unified kernel images

Worth knowing about, because it changes the picture.

A UKI bundles the kernel, initramfs and command line into a single signed EFI executable. The firmware can boot it directly with no bootloader at all, and because the command line is inside the signature, nobody can add init=/bin/bash.

# assemble one
sudo ukify build \
  --linux=/boot/vmlinuz-linux \
  --initrd=/boot/initramfs-linux.img \
  --cmdline="root=UUID=xxxx rw quiet" \
  --output="$ESP/EFI/Linux/linux.efi"

# systemd-boot finds these automatically
ls "$ESP/EFI/Linux/"
bootctl list

systemd-boot picks up anything in EFI/Linux/ without an entry file. This is where things are heading for Secure Boot setups, because a signed UKI is a genuinely tamper-resistant boot path. Our Secure Boot custom keys guide covers signing it.

The trade-off is that every kernel or initramfs change requires rebuilding and re-signing the image.

When it does not boot

# from a live USB
sudo mount /dev/nvme0n1p2 /mnt
sudo mount /dev/nvme0n1p1 /mnt/boot/efi

# is the loader there
ls /mnt/boot/efi/EFI/systemd/
ls /mnt/boot/efi/loader/entries/

# are the kernels where the entry says
ls /mnt/boot/efi/*.img /mnt/boot/efi/vmlinuz* 2>/dev/null

# reinstall the firmware entry
sudo bootctl --esp-path=/mnt/boot/efi install

The three failures, in order of likelihood: the entry points at a path that does not exist, the kernel was never copied to the ESP, and the firmware entry is missing or deprioritised. Our chroot rescue guide covers the full recovery procedure.

Most firmware also has a one-time boot menu behind F12, F11 or Esc, which is faster than any of the above when the other loader is still installed.

Frequently Asked Questions

What is the main difference between systemd-boot and GRUB?

GRUB is a full bootloader that can read many filesystems, supports BIOS and UEFI, and can load a kernel from almost anywhere. systemd-boot is a thin UEFI menu that relies on the firmware to read the EFI System Partition, so kernels have to live there. GRUB is more capable, systemd-boot is far simpler.

Can systemd-boot boot from a BIOS system?

No. It is UEFI only by design, because it uses UEFI services to load the kernel rather than implementing filesystem drivers of its own. On a BIOS or legacy boot machine, GRUB or syslinux is the option.

Does systemd-boot work with an encrypted root?

Yes, because the decryption happens in the initramfs rather than in the bootloader. The kernel and initramfs sit unencrypted on the EFI System Partition, which is also how GRUB usually handles it, and the passphrase prompt comes from the initramfs after the kernel has started.

How large should my EFI partition be for systemd-boot?

At least 512 MB, and a gigabyte is better. Kernels and initramfs images live on it rather than in a separate boot partition, so several installed versions add up quickly. The 100 MB partition a Windows installer creates is too small and is the most common problem when switching.

Which one works better with Secure Boot?

GRUB has the established path, because distributions ship a signed shim and a signed GRUB that Microsoft key verification accepts. systemd-boot can work with Secure Boot, and it usually means enrolling your own keys and signing the loader and kernels yourself, which is more work and gives you a chain you control.

Can I have both installed at once?

Yes, and it is the sensible way to switch. Both live in different directories on the EFI System Partition and the firmware boot menu picks between them. Install the new one, leave the old one in place, and remove it only after you have booted successfully a few times.