Systemd-boot, previously called “gummiboot,” is Grub’s newer competitor. On compatible EFI systems, you can use systemd-boot in place of Grub to boot the system’s operating system. From a high-level perspective, systemd-boot links to the bootloader already in UEFI, offering the most basic feature set for selecting an operating system. Grub, on the other hand, loads what is sometimes described as “an entire OS” to manage booting the user’s operating system, providing far greater capability.
What Is a Bootloader?
A bootloader loads the operating system. It’s copied to memory by your machine’s BIOS from the first valid block of your disk and runs before any operating system boots. From there, it provides a basic set of features that allow you to modify how you want your machine to boot for that session. For example, GRUB gives you an option to load different kernels for your Linux distro.
If the bootloader detects multiple bootable system images, it allows the user to select which system to load. The bootloader then boots the operating system and hands off hardware control to the OS. On most systems, the bootloader appears right after the splash screen for the motherboard.
FYI: BIOS and UEFI are the two firmware that you will find in x86_64 motherboards today. Learn what makes them tick and how you can determine which firmware is best for you.
Grub vs. systemd-boot: What Is Grub?
GNU GRUB, more commonly known as Grub or GRUB 2, stands for GRand Unified Boot Interface. It’s based on the Free Software Foundations’s multiboot specification. Its developers designed it to work on any hardware platform and boot just about any Unix-like operating system from virtually any boot media and file system.
Because it covers a wide range of platforms and distributions, Grub is often the default bootloader in most Linux distros. If you’ve interacted with a Linux bootloader, it was probably Grub. It also provides options for visual configuration like text, background colors and graphical splash images. Debian’s version of Grub, for example, uses a unique blue-green background for its prompt.
Grub supports multiboot systems and its developers wrote it specifically for that purpose. However, it can be a little tricky if anything goes wrong. Problems occur most frequently when installing Grub on an existing multiboot system, removing OSes, and installing new OSes. Grub uses one conf file, so every operating system is included in the same file, which is edited to reflect changes.
The primary operating system’s bootloaders live in the MBR, and other operating systems are chain-loaded through bootloaders on their own partitions. This works, and for most use cases, it’s absolutely sufficient. But it’s a system that can also be easily upset. For example, if you don’t configure the chain-loaded kernels properly, multiple Linux installations can end up “fighting” over control of the MBR.
Good to know: there are instances where GRUB and Windows just fail to play together. Learn how you can rescue your Windows system from a botched multiboot install.
Grub vs. Systemd-boot: What Is Systemd-boot?
Linux fans may have encountered the name “systemd” before. Systemd, short for “system daemon,” is a collection of fundamental prerequisite daemons for running a Linux system. Systemd-boot is a several-thousand-lines code and has no dependencies in the rest of the systemd suite.
However, thanks to its simplicity, gummiboot was added to systemd and renamed “systemd-boot” to match systemd’s component-naming convention. Systemd’s overall goal is to boot the system quickly by starting fewer things and starting more in parallel, and systemd-boot shares that goal.
As a text-only bootloader, systemd-boot has an obviously old-school appearance. Available boot devices are listed by their title, which is handled in systemd-boot’s configuration file. The systemd-boot is basically an interface for the boot logic included in EFI, which is why it can only be used with compatible EFI systems. It’s a dramatically less configurable system than Grub, and it uses modular .conf files for each operating system that you want to boot.
With its limited interface, systemd-boot is a far smaller bootloader than Grub. Some people install it for speed or to manage multiple operating systems more effectively. Because systemd-boot uses split configuration files (a single .conf file for each kernel or operating system), it can be simpler for maintaining a system with multiple kernels or operating systems manually. These drop-in configuration text files can simply be copied to systemd’s directory when a new kernel is installed. This simplifies the configuration for multi-boot systems.
Tip: while Systemd is fast, there are still questions on its overall security. You can avoid these potential concerns by installing a Systemd-less distro, such as Devuan.
Which Is Better: Grub or Systemd-boot?
If you have problems with Grub, systemd-boot provides a dramatically simplified boot infrastructure with drop-in file configuration. It’s more robust, but it’s also not nearly as configurable or adaptable as Grub. If you’re running a multiboot EFI system, systemd-boot can provide easier boot management and may even reduce your boot times. On other system configurations, or for uses that require greater flexibility than systemd-boot affords, Grub remains your best bet.
Frequently Asked Questions
Is it possible to convert my GRUB 2 system to Systemd-boot?
Yes. For the most part, GRUB and Systemd-boot should be able to coexist inside the same system. This means that you can convert a machine that uses GRUB over to Systemd-boot.
It is important to keep in mind that installing Systemd-boot will differ depending on your Linux distro. In most cases, however, this will involve loading your OS in UEFI mode and running su && bootctl install.
Can BIOS systems run Systemd-boot?
Yes. It is possible for BIOS-only systems to run Systemd-boot by emulating a UEFI-like environment. One of the most popular programs that can do this is Clover. This is a bootloader replacement for Hackintosh machines that you can rig to work with Linux distros.
Is it possible to speed up GRUB 2?
Yes. One of the easiest ways to speed up GRUB 2 during boot is by reducing the time that it waits for its prompt. You can do this by running sudo nano /etc/default/grub, then changing the GRUB_TIMEOUT value to 1.
On the other hand, you can also make sure that GRUB will always wait for a user response by changing that GRUB_TIMEOUT value to -1. Once done, you need to run sudo update-grub to apply your new configuration.
Image credit: Unsplash. All alterations and screenshots by Ramces Red.
Our latest tutorials delivered straight to your inbox
