Bootloaders explained: systemd-boot vs GRUB
A bootloader is the small program that hands control from your firmware to the Linux kernel. What systemd-boot and GRUB each do, and which one to pick for an Arch install.
level:Beginner
Somewhere in an Arch install you reach a step that asks, in effect, "how should this machine actually start Linux?" — and the usual answer is to install a bootloader. There are two common choices, systemd-boot and GRUB, and the decision feels weightier than it is. If you are putting Arch on a single, reasonably modern machine, you can take the default I will recommend below and never think about it again. This post explains what a bootloader is doing in the first place, what each of these two actually offers, and when the choice genuinely matters.
What a bootloader does
When you press the power button, the first software that runs is not your operating system. It is firmware baked into the motherboard. On modern machines that firmware is UEFI; on older machines it was the legacy BIOS. The firmware knows how to talk to the disk and bring up the screen, but it does not know what Linux is. Its job is to find something to run and hand off control.
That something is the bootloader. The bootloader's job is narrow: locate the Linux kernel on disk, load it into memory along with its initramfs (a small temporary root filesystem that helps the kernel get going), pass along any kernel parameters, and then jump into the kernel. From that moment the kernel takes over, mounts your real root filesystem, and starts userspace. So the chain is firmware to bootloader to kernel plus initramfs to your system. The bootloader is the short bridge in the middle.
It helps to see what runs, why each link exists, and how control passes along. The firmware exists because the hardware needs something to run before any disk is understood; it hands off because it deliberately knows nothing about operating systems. The bootloader exists to bridge that gap, and it hands off because its only purpose is to get the kernel running. The chain below traces that handoff end to end.
The boot chain: each stage loads the next and steps aside.
flowchart LR
A["Firmware<br/><i>UEFI or BIOS</i>"] --> B["Bootloader<br/><i>systemd-boot or GRUB</i>"]
B --> C["Kernel + initramfs"]
C --> D["init<br/><i>userspace starts</i>"]
If you have met other systems, this slot is familiar: the bootloader plays the same role as the Windows Boot Manager that picks which Windows to start, or the macOS startup picker you hold a key to reach. Same job — choose what to boot and load it — just a Linux-flavoured implementation.
UEFI changed the rules in an important way. Legacy BIOS could only run raw boot code stuffed into the first sector of a disk, which is why old bootloaders were complicated. UEFI instead reads ordinary .efi program files from a special FAT-formatted partition called the EFI system partition, or ESP. That is a much friendlier contract, and it is why a minimal bootloader is viable today in a way it was not twenty years ago.
systemd-boot
systemd-boot is a small UEFI-only boot manager that ships as part of systemd, which Arch already installs as its init system. There is nothing extra to add to your package list — it is already there, installed with one command, bootctl install.
Its defining trait is minimalism, and that is a deliberate design choice rather than an accident. What it does at boot is deliberately small: systemd-boot does not parse filesystems or run scripts. Why keep it that way: less code between you and the kernel means fewer ways to fail and a setup you can fully understand. How it works in practice: it reads plain text configuration files from the ESP and presents a simple menu. A boot entry is a few lines naming a title, the kernel image, the initramfs, and the kernel command line. You can read the entire configuration of a systemd-boot setup in under a minute, and when something is wrong you are looking at a handful of human-readable files rather than a generated maze.
The trade-off is scope. Because it relies entirely on UEFI, systemd-boot does not work on legacy BIOS machines at all. It also expects the ESP to be reachable from a single mounted location. The simplest and recommended approach on Arch is to mount the ESP directly at /boot, because that is where the kernel, initramfs, and CPU microcode images already live, so the boot manager can see everything in one place. systemd-boot will look for the ESP at /efi, /boot, or /boot/efi; mounting at /efi with a separate boot partition is also supported but is an advanced layout, and if you do not mount the ESP at /boot you must take care not to rely on automounting during kernel upgrades (Arch Wiki: EFI system partition). For a fresh single-OS install, mount it at /boot and move on.
GRUB
GRUB, the GRand Unified Bootloader, is the heavyweight veteran and the default on most beginner-friendly distributions. It is far more capable than systemd-boot, and far larger. GRUB works on both legacy BIOS and UEFI, can boot from a wide range of filesystems, has its own little scripting language, and supports a graphical menu with themes.
Its headline feature for many people is multi-boot. What this gives you is a single menu listing every OS on the machine; why it matters is that you choose at power-on instead of swapping firmware settings; how it manages it is a helper called os-prober that scans your disks for other operating systems — most commonly an existing Windows installation — and automatically adds menu entries for them. If you want one menu that lets you choose between Arch and Windows at power-on, GRUB is the well-trodden path, though it sometimes needs extra packages such as ntfs-3g to detect Windows partitions reliably.
The cost of all that capability is moving parts. GRUB's working configuration is generated by a tool (grub-mkconfig) from templates and detection scripts, so the file you end up booting from is not one you wrote by hand and is harder to reason about when it misbehaves. There is simply more machinery between you and the kernel. None of this is bad — GRUB is mature and reliable — but it is more than a single modern UEFI install needs.
An aside: EFISTUB and no bootloader at all
It is worth knowing that on UEFI you do not strictly need a separate bootloader program. The Arch kernel is itself a valid UEFI executable — an EFI boot stub, or EFISTUB — so the firmware can load the kernel directly if you register a UEFI boot entry pointing at it with efibootmgr. A newer variant bundles the kernel, initramfs, and boot options into a single signed file called a unified kernel image. These approaches are elegant and fast, but they are fiddlier to set up and update, and they assume a well-behaved firmware. They are good things to graduate to later, not where a first install should start.
Which should I pick?
💡 Tip Pick systemd-boot for a single modern UEFI install; pick GRUB when you are dual-booting or running on legacy BIOS hardware.
For a single, modern, UEFI machine — which describes almost any laptop or desktop made in the last decade — pick systemd-boot. It is already installed with Arch, the configuration is tiny and readable, there is nothing extra to maintain, and when you eventually need to debug a boot problem you will be glad you are reading four lines of text instead of a generated script. This is the opinionated default, and for most readers it is simply the right answer.
Pick GRUB when you have a concrete reason that systemd-boot cannot meet. The clearest reasons are: you are dual-booting with Windows or another OS and want a single automatic menu; you are on legacy BIOS hardware where systemd-boot does not run at all; or you want graphical menus, themes, or GRUB's more advanced features. If you are dual-booting, GRUB is the path of least resistance and I would not fight it.
If you are unsure and the machine is modern and Linux-only, that uncertainty itself is the signal: take systemd-boot. You are not locking yourself in. A bootloader can be replaced later without reinstalling anything else, because it is just the bridge — your system underneath does not care which one carried it.
The decision is really a short series of questions about what your hardware and goals are. Why it shakes out this way: systemd-boot covers the common case with the least machinery, so it wins by default, and you only reach for GRUB's breadth when a specific need pushes you there. How to walk it:
Pick by hardware and intent; default to systemd-boot, branch to GRUB only on a concrete need.
flowchart TD
A["How does this machine boot?"] -->|"UEFI"| B["Need dual-boot menu, themes, or BIOS support?"]
A -->|"legacy BIOS"| C["GRUB"]
B -->|"no"| D["systemd-boot"]
B -->|"yes"| C
How this fits the Arch install
This decision lands squarely in part 2 of the install, the step where you have a base system in place and need to make it boot on its own. Part 2 walks through bootctl install for systemd-boot specifically, which is the choice that matches the single-machine default here. If you decided on GRUB instead, that is also the step to swap in grub-install and grub-mkconfig. Whichever you choose, the bootloader is loading the kernel and its initramfs, so it is worth reading that explainer alongside this one — the two pieces are installed together and fail together. The whole sequence, with both install parts and the companion explainers, is gathered on the Arch install hub.
A short close
A bootloader is a small bridge, not a destination. systemd-boot and GRUB both get you across it; they differ mostly in how much machinery they carry and how many situations they cover. For a modern single-OS UEFI install, systemd-boot's minimalism is a genuine feature — less to configure, less to break, less to understand. Reach for GRUB when you actually need its breadth, especially dual-booting or old BIOS hardware. Either way, the choice is reversible, so do not let it hold up your install.