What is a bootloader?
A bootloader loads the operating system. It’s copied to memory from a special sector on the boot media and runs before any operating system is booted. If multiple bootable system images are detected, the bootloader allows the user to select the system to start. 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.
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. It’s designed to work on any hardware platform and boot just about any Unix operating system from virtually any boot media and file system. Because it’s intended to cover a wide range of platforms and distributions, Grub is commonly used as the default bootloader shipped with most Linux distros. If you’ve interacted with a Linux bootloader, it’s probably been Grub. It also provides options for visual configuration like text, background colors and graphical splash images. Ubuntu’s version of Grub, for example, uses Canonical-brand purple. Grub supports multiboot systems and was written 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 systems is included in the same file, which is edited to reflect changes. The primary operating system’s bootloaders lives in the MBR, and other operating systems are chain-loaded through bootloaders on their own partitions. This works, and for most uses 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.
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 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, with basically no configuration options. With its limited interface, systemd is a far smaller bootloader than Grub. Some people install it for speed or to manage multiple operating systems more effectively. Because systemd 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.
Conclusion: Is Grub or Systemd-boot better?
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 might 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.
