Initially released in 1995, the GRUB bootloader has been around for 30 years. A major rewrite began around 2002 resulting in GRUB 2. Even today, the overwhelming majority of Linux computers continue to rely on GRUB.

Despite GRUB's advanced age, most Linux users are only vaguely aware of GRUB's existence. GRUB typically operates silently in the background – the average user doesn't notice it during operating system installation or the boot process. If a user does see GRUB, this typically means something has gone seriously wrong. Because attempting to understand GRUB in that moment creates significant stress, you should have at least a basic understanding of GRUB's architecture and configuration so that you know your recovery options should a crisis arise.

The GRUB bootloader is actually called GRUB 2 to distinguish it from the first version. I will use the name GRUB 2 even though the old version isn't really around anymore.

GRUB 2 stands as a sophisticated utility in your toolkit, offering extensive customization options. Like all highly configurable and powerful tools, GRUB 2 provides everything you need to either highly optimize or, in the worst case, potentially render your system unbootable. Keep this in mind when experimenting with new features. Do not conduct experiments on hardware used in production environments. I highly recommend using a test environment, such as a virtual machine.

In this article, I offer you a guided tour of GRUB 2 and its operating environment. While far from exhaustive – major Linux distributions dedicate entire chapters of their documentation to it, and the official GRUB 2 website [1] provides an entire book – I aim to offer essential insights into GRUB 2's functionality. The purpose of this article is to bring together all the essential elements necessary for comprehending your system's boot process and the role GRUB 2 plays in it. To truly understand GRUB 2, you need basic knowledge of the processes involved in starting a computer.

The Boot Process

When you turn on your computer, the firmware first starts the Power On Self Test (POST), which consists of several tests to verify that the hardware is working properly. (I'll discuss the firmware in detail a little later.) Once it's clear that the hardware is okay, the firmware determines which device to boot the system from. It loads this device's boot manager (GRUB 2 in this example) and launches it. In addition to Linux systems, GRUB 2 can launch other operating systems (like Microsoft Windows) as well using a technique called chainloading, where GRUB 2 passes control to the other operating system's bootloader. When GRUB 2 takes over from the firmware, it loads the Linux kernel into RAM, passing it the necessary kernel parameters (e.g., the location of the root filesystem). GRUB 2 then loads the initial filesystem (initramfs) into RAM.

GRUB 2 at Work

To see how GRUB 2 works, you can manually load the kernel. First, you need to access the GRUB 2 shell from the GRUB 2 menu (Figure 1). The menu you actually see depends on your installed system; in fact, you may not see GRUB 2 at all. If this is the case, you need to correct GRUB 2's configuration by changing two lines in the GRUB 2 configuration file /etc/default/grub (Figure 2). (Do not modify /grub/grub.cfg by hand, as it gets updated automatically every time a new kernel is installed; this will be covered in depth later). Change GRUB_TIMEOUT_STYLE from hidden to menu and GRUB_TIMEOUT to the number of seconds you want it to wait until the default system (i.e., the system in the GRUB 2 menu with the line number specified with GRUB_DEFAULT) will be booted. In my case, the original setting for GRUB_DEFAULT was  , which means the first line as GRUB 2 starts counting from zero (as shown in Figure 1). If I want to boot Windows 10 by default, I need to change the GRUB_DEFAULT to 2, which would be the third line in the menu counting from zero.

Figure 1: The GRUB 2 menu.

Figure 2: The GRUB 2 configuration file.

Once you change the settings, you will need to update the GRUB 2 configuration, using the command suggested by the configuration file:

sudo update-grub

GRUB 2 offers a lot of parameters for its configuration. In this article, I will cover only a couple of them, so I suggest looking at the GRUB manual and experimenting with some of the parameters not covered here.

Now, when you reboot your computer, it will show you the GRUB 2 menu. The default OS specified by the line number you configured with GRUB_DEFAULT will boot based on the time you set in GRUB_TIMEOUT. In my example, the OS that will boot is Windows (the third line in Figure 1).

Now that you can see the GRUB 2 menu, you can access the GRUB 2 shell by typing c at the command line and the GRUB 2 shell opens waiting on your input at the prompt (>). Figure 3 shows the manual boot process.

Figure 3: Manually booting the Linux system from the GRUB 2 shell.

When looking at the GRUB 2 shell, I recommend setting its paging to the shell command more's paging so that you can scroll. The GRUB 2 shell is very similar to the Linux command shells (for a list of all available commands, see the online manual [2]).

In Figure 3, I use ls to see the available partitions. The system I want to boot lives in partition 5. To verify this, I use the command

ls (hd0,5)/

to show the content of partition 5. For your system, set the root of your navigation to partition 5 using

set root=(hd0,5)

Now you can simply look in /etc/fstab to see that the root partition is mounted from /sda5. You need this information in the next line, where you tell GRUB 2 which kernel to boot and where the root filesystem is mounted. GRUB 2 still needs the location of initramfs (the initial filesystem), which you communicate with the initrd command. You should mount initramfs with the same version number as your kernel. Then, you can tell GRUB 2 to take over using the boot command.

I have used the manual boot process here to show what GRUB 2 is doing. As a practical application, you could use this process when your system does not boot automatically and you are stuck at the boot> prompt. You can use this process to boot your system if the menu is broken, or you can use it to boot into an older kernel that the boot menu no longer offers.

UEFI, BIOS, and GRUB

In GRUB 2's ls output shown in Figure 3, you may wonder about the meaning of (hd0), (hd0,msdos10), (hd0,msdos9), and so on. The hd0 indicates the first hard disk (remember GRUB starts counting disks at zero), and msdos1 is the first partition, msdos2 the second, and so on. Your computer may instead say (hd0,gpt1), (hd1,gpt2), and so on – this difference is due to the partitioning your firmware uses.

Recent systems use Extensible Firmware Interface (EFI), the original specification developed by Intel, to bridge the gap between the operating system and hardware during startup. EFI replaced the Basic Input/Output system (BIOS), overcoming its limitations. Due to Unix/Linux systems's long lifetime compared to Windows installations, many Unix/Linux machines still use the legacy BIOS. While GRUB works on both firmware versions, there are a couple of differences between the two firmware architectures that affect the use of GRUB.

Unified EFI (UEFI) uses the GUID Partition Table (GPT), where the Globally Unique Identifier (GUID) allows the partition table to be uniquely identified across several systems. (UEFI builds upon the EFI specification by adding enhancements such as enhanced FAT variants, advanced security features such as secure boot, and modern hardware features including networking support.) BIOS, on the other hand, uses the Master Boot Record (MBR) to organize and structure data on storage devices (see Table 1 for a comparison). The main difference lies in how these technologies organize data: MBR starts at sector 0, cylinder 0, head 0, while GPT uses the entire partition.

Another difference between UEFI and BIOS is that UEFI is much faster. Because of this, UEFI offers a secure boot mechanism, which ensures that only trusted operating systems can start up.

UEFI also stores its parameters in non-volatile random-access memory (NVRAM). In addition, BIOS uses keyboard-only navigation in a text interface, while UEFI provides a modern graphical interface with mouse support.

As you'll see later on, another difference between UEFI and BIOS comes into play during the installation of GRUB. Finally, BIOS installs the boot information in the MBR, while UEFI installs its configuration files in /boot/UEFI on the disk and in NVRAM.

UEFI files lives in a partition mounted as /boot/efi (Figure 4). You need to have superuser permission to look inside this directory. Here you will find the operating system along with the UEFI files. At a minimum, these files include BOOTX64.efi and grubx64.efi, which are in the directory named after the operating system it can boot (Debian in my example). The firmware also contains information that Debian is one of the operating systems and points to the debian directory in the partition /boot/efi. The executable file grubx64.efi is the operating systems's bootloader (again Debian). The BOOTX64.efi executable file is used as the last-resort mechanism to locate and execute a bootloader when no other boot configuration exists. There are other EFI files as well, such as the signed bootloader (shimx64.efi), the memory mapping utility (mmx64.efi), the UEFI shell (shellaa64.efi), and others.

Figure 4: Contents of the EFI partition.

BIOS is much different. BIOS's MBR consists of the first 512 bytes of the partition, including the Master Boot Routine (446 bytes), the partition table (64 bytes), and an identification code that also is used to verify the MBR's integrity. To understand the MBR's contents, you need to be fluent in hexadecimal notation.