The Case Against the Bloated Bootloader
GRUB (Grand Unified Bootloader) is the old reliable of the Linux world. It is versatile, supports legacy BIOS, and can boot almost any OS you throw at it. However, if you are running a modern machine with UEFI, GRUB often feels like using a sledgehammer to drive a finishing nail. It relies on massive, 1,000-line scripts just to generate a simple grub.cfg, adding unnecessary overhead to every restart.
A few years ago, I spent two hours debugging a server that refused to boot after a kernel update. The culprit? A tiny syntax error in a script I didn’t even write. That frustration led me to look for something leaner and more transparent. If you want a boot process built specifically for the UEFI era, systemd-boot is the answer.
Why GRUB Is Overkill for Modern Hardware
GRUB’s complexity is a byproduct of its history. Because it was designed to bridge the gap between ancient hardware and modern software, it includes its own drivers for file systems, video modes, and even network protocols. When you hit the power button, GRUB essentially launches a mini-operating system just to find and load your actual operating system.
On a UEFI system, this is redundant. Your motherboard’s firmware already knows how to read partitions and load files. By sticking with GRUB, you are placing a middleman inside another middleman. This setup causes several headaches:
- Wasted time: GRUB can add 2 to 5 seconds to your boot sequence just for initialization.
- Fragility: Configuration files are generated by
os-proberand other scripts, making them a nightmare to edit manually. - Learning curves: Junior admins often struggle to customize boot parameters because the configuration logic is buried under layers of abstraction.
Comparing the Solutions: GRUB vs. systemd-boot
You generally have three paths when choosing a boot manager. GRUB remains the “safe” default, but it is heavy. rEFInd offers a beautiful graphical interface for multi-booting systems like macOS and Linux, but it is often overkill for a dedicated workstation.
systemd-boot (formerly gummiboot) takes a different approach. It doesn’t try to be an OS. Instead, it acts as a simple logic gate that tells the UEFI firmware which kernel to run. While GRUB’s core can take up several megabytes, the systemd-boot EFI binary is usually less than 500KB. It uses plain-text configuration files that any human can read and modify in seconds.
The “Less is More” Approach
I migrated my production Ubuntu 22.04 server to systemd-boot and saw an immediate difference. By eliminating the GRUB discovery phase, the transition from firmware to kernel became nearly instantaneous. On a standard NVMe drive, my “firmware-to-login” time dropped by roughly 3 seconds.
Before you make the switch, verify that your system is in UEFI mode. This process will not work on legacy BIOS machines. Run this command to check:
[ -d /sys/firmware/efi ] && echo "UEFI mode" || echo "Legacy mode"If the output confirms “UEFI mode,” you are ready to proceed.
Step 1: Preparing the EFI Partition
systemd-boot requires your kernel and initramfs files to live on the EFI System Partition (ESP). Most distributions mount the ESP at /boot/efi, but systemd-boot works best if the ESP is mounted directly at /boot.
Check your current setup with lsblk. If your EFI partition is only 100MB, you should resize it to at least 500MB. This ensures you have enough room to store multiple kernel versions and their associated images without running out of space during an update.
Step 2: Initializing systemd-boot
If you use a modern distribution, systemd-boot is likely already on your disk as part of the systemd package. You don’t need to download anything new; you just need to activate it. Run this command to install the manager to your EFI partition:
sudo bootctl installThis command copies the necessary binaries and creates a new entry in your motherboard’s NVRAM. You can check the status of your boot entries by running bootctl status.
Step 3: Configuring the Loader
Now you need to define how the bootloader behaves. Open the main configuration file:
sudo nano /boot/loader/loader.confPaste the following settings:
default linux.conf
timeout 3
console-mode max
editor noSetting editor to ‘no’ is a vital security step. It prevents unauthorized users from changing kernel parameters (like booting into a root shell) directly from the boot menu.
Step 4: Creating Your Boot Entry
Unlike GRUB’s single, massive configuration file, systemd-boot uses separate files for each entry. These live in /boot/loader/entries/. Create a file for your primary OS:
sudo nano /boot/loader/entries/linux.confAdd the following lines, ensuring the filenames match the files actually sitting in your /boot directory:
title Linux Desktop
linux /vmlinuz-linux
initrd /initramfs-linux.img
options root=PARTUUID=xxxx-xxxx-xxxx rwTo find your PARTUUID, run blkid -s PARTUUID -o value /dev/sdXn, replacing the device path with your root partition. Using PARTUUID is much more reliable than device names like /dev/sda2, which can shift if you plug in a new USB drive.
Step 5: Managing Kernel Updates
One common question is: “What happens when the kernel updates?” On Arch Linux, filenames are static, so you never have to touch these configs. On Debian or Ubuntu, updates often include version numbers in the filename.
To automate this, you can use kernel-install, a script included with systemd. It automatically moves kernels to the ESP and generates entry files whenever a new version is installed. For a simpler manual approach, you can create a small script that symlinks the latest kernel to a generic name like vmlinuz-linux.
Step 6: Removing the Dead Weight
Once you have successfully rebooted using systemd-boot, you can safely remove GRUB. This prevents your system from wasting resources updating a bootloader you no longer use. On Ubuntu or Debian, run:
sudo apt purge grub-common grub-pc-bin grub-efi-amd64
sudo apt autoremovePro tip: Always keep a Live USB in your desk drawer before deleting your old bootloader. While systemd-boot is incredibly stable, having a recovery tool is the hallmark of a prepared admin.
The Result: A Transparent Boot Process
Switching to systemd-boot isn’t just about shaving a few seconds off your startup time. It’s about gaining clarity. By stripping away GRUB’s complexity, you turn the boot process from a mysterious “black box” into a manageable part of your infrastructure. You get a clean directory of entries, a single config file, and a system that respects the power of your modern hardware.
