09

Stage 2: GRUB

GRUB takes over from the bootloader and gives you a menu. Here is what it does next.

Boot / Beginner / 16 min read

Stage 1 loaded a small piece of code that can read a filesystem. That code loaded GRUB's main body into memory. Now, for the first time in the boot process, the machine is running a program that can do more than just load the next sector. GRUB can read configuration files, display a menu, accept keyboard input, and -- most importantly -- find and load a Linux kernel.

GRUB stands for GRand Unified Bootloader. The "unified" part matters: GRUB can boot Linux, Windows, BSD, and other operating systems from a single menu. But its core job on a Linux system is straightforward. Read a config file. Show a menu. Load the kernel and an initial RAM filesystem into memory. Hand control to the kernel.

GRUB's Architecture

GRUB is not a single program. It is a modular system built from a small core and a collection of loadable modules. The core provides the command-line interpreter, the module loader, and basic device access. Modules add specific capabilities: filesystem drivers, compression support, graphical terminal rendering, network booting, and more.

Key term: GRUB module A loadable piece of code that adds a specific capability to GRUB. Modules are stored as files in /boot/grub/ (or /boot/grub2/ on some distributions). Common modules include ext2.mod (for reading ext2/ext3/ext4 filesystems), normal.mod (the menu system), and linux.mod (for loading Linux kernels).

When GRUB's core starts, it loads the normal module, which provides the familiar menu interface. The normal module then reads the configuration file and builds the menu entries. If the configuration file is missing or corrupt, GRUB drops to a rescue shell -- a minimal command line where you can manually type commands to boot the system.

Fig. 09a -- GRUB modular architecture
GRUB Core command line + module loader normal.mod menu system ext2.mod ext2/3/4 FS linux.mod kernel loader gzio.mod gzip decomp xfs.mod XFS FS part_gpt.mod GPT partitions video.mod framebuffer ... 100+ more /boot/grub/grub.cfg normal.mod reads config
GRUB's core loads modules on demand. The normal module reads grub.cfg and builds the boot menu. Filesystem modules let GRUB read files from partitions.

The Configuration File

GRUB's behavior is controlled by a file called grub.cfg, usually found at /boot/grub/grub.cfg or /boot/grub2/grub.cfg. You are not meant to edit this file by hand. It is generated automatically by the grub-mkconfig command (or grub2-mkconfig on Fedora/RHEL systems), which scans your system for installed kernels and writes the appropriate menu entries.

A typical grub.cfg entry looks like this:

menuentry 'Ubuntu' --class ubuntu --class os {
    set root='hd0,gpt2'
    linux /vmlinuz-6.2.0 root=/dev/sda3 ro quiet splash
    initrd /initrd.img-6.2.0
}

Each line does something specific:

  • set root='hd0,gpt2' tells GRUB which partition to read files from. hd0 is the first disk, gpt2 is the second GPT partition.
  • linux /vmlinuz-6.2.0 ... tells GRUB to load the kernel image from the specified path, and passes everything after the filename as kernel command-line parameters.
  • initrd /initrd.img-6.2.0 tells GRUB to load the initial RAM disk alongside the kernel.
Key term: initrd / initramfs An initial RAM filesystem loaded into memory alongside the kernel. It contains a minimal set of drivers and tools that the kernel needs to mount the real root filesystem. Without it, the kernel could not access a root partition on LVM, RAID, an encrypted volume, or any device requiring a driver not compiled into the kernel itself.

How GRUB Identifies Disks and Partitions

GRUB uses its own naming convention for storage devices. The first hard disk is hd0, the second is hd1, and so on. Partitions are numbered starting from 1: hd0,msdos1 for the first MBR partition on the first disk, or hd0,gpt1 for the first GPT partition. This naming is independent of how Linux names the same devices (/dev/sda1, /dev/nvme0n1p1, etc.).

GRUB resolves these names using its disk and partition modules. It reads partition tables directly -- it does not rely on the operating system, because the operating system is not running yet. GRUB carries its own partition table parsers (part_msdos.mod for MBR, part_gpt.mod for GPT) and its own filesystem drivers.

How GRUB Reads Filesystems

This is the capability that separates GRUB from the tiny Stage 1 code. Stage 1 can only read raw sectors by number. GRUB can read files by path.

GRUB includes filesystem driver modules for ext2/ext3/ext4, XFS, Btrfs, ZFS, FAT, NTFS, and others. When GRUB needs to read a file, it:

  1. Identifies the disk and partition from the device name.
  2. Reads the partition's superblock to determine the filesystem type.
  3. Loads the appropriate filesystem module if it is not already loaded.
  4. Navigates the filesystem's internal structures (inodes, directory entries, extent trees) to locate the file.
  5. Reads the file's data blocks into memory.

This is the same work that the Linux kernel does when you run cat /boot/vmlinuz, but GRUB does it with its own code, running before the kernel exists. GRUB's filesystem drivers are simpler than the kernel's -- they only need to read, never write -- but they must be correct. A bug in GRUB's ext4 driver means an unbootable system.

Fig. 09b -- GRUB reading a file from disk
GRUB Core linux /vmlinuz ext2.mod parse inode tree BIOS INT 13h read sectors sector data returned Memory at load address vmlinuz (kernel image) initrd.img (RAM disk)
GRUB uses its own filesystem driver to resolve file paths, reads the underlying sectors through BIOS services, and loads the kernel and initrd into specific memory addresses.

The Menu and the Timeout

When GRUB finishes loading its configuration, it displays a menu. If you have a single operating system, the menu might be hidden -- GRUB waits for a configurable timeout (often 5 or 10 seconds) and then boots the default entry automatically. Press Shift or Escape during this timeout to reveal the menu.

The menu lets you choose between different kernels (useful after a bad kernel upgrade), different operating systems (dual-boot setups), or recovery modes. Each menu entry is a menuentry block in grub.cfg containing the commands GRUB will execute when that entry is selected.

You can also press c at the menu to drop into GRUB's command line, where you can type commands manually. This is invaluable for recovery. If your grub.cfg is corrupt but you know where your kernel lives, you can type:

set root=(hd0,gpt2)
linux /vmlinuz root=/dev/sda3
initrd /initrd.img
boot

Those four commands do exactly what a menuentry block does, but typed by hand.

GRUB is a modular bootloader with its own filesystem drivers, command-line interpreter, and menu system. It reads a configuration file (grub.cfg) generated by your distribution's tools, loads the kernel and initramfs into memory, and then hands control to the kernel. If the configuration is broken, you can use GRUB's command line to boot manually.

Loading the Kernel and Initramfs

When you select a menu entry (or the timeout expires), GRUB executes the commands in that entry. The linux command is the critical one. It does several things:

  1. Opens the kernel image file (vmlinuz) from the specified partition and path.
  2. Reads the kernel's setup header, which is embedded in the first few kilobytes of the image. The header tells GRUB the kernel's version, required load address, command-line format, and other parameters.
  3. Copies the kernel image into memory at the address the header specifies.
  4. Stores the kernel command-line string (everything after the filename on the linux line) in a designated memory area.

The initrd command then loads the initial RAM filesystem image into another region of memory and records its address and size so the kernel can find it later.

Fig. 09c -- Memory layout after GRUB loads kernel and initrd
Physical Memory Real-mode kernel code + setup header 0x10000 Kernel command line ("root=/dev/sda3 ro quiet") ... Protected-mode kernel (compressed) loaded at 0x100000 (1 MB mark) ... initrd / initramfs (loaded at high memory)
After GRUB's linux and initrd commands execute, memory contains the kernel setup header at a low address, the compressed kernel at the 1 MB mark, and the initramfs image in high memory.

The Boot Command

After the linux and initrd commands have loaded their data, the boot command (usually implicit at the end of a menuentry block) triggers the actual handoff. GRUB fills in a data structure called the boot parameters (or "zero page") with everything the kernel needs to know: the address and size of the initrd, the command-line location, the video mode, the memory map from the BIOS, and more.

Then GRUB jumps to the kernel's entry point. At this moment, GRUB's job is done. It will never run again (until the next reboot). The kernel takes over, and the bootloader is gone.

GRUB on UEFI Systems

Everything described so far assumes legacy BIOS booting. On UEFI systems, the picture is different. UEFI firmware can read FAT-formatted partitions natively, so GRUB does not need the Stage 1 / Stage 1.5 chain. Instead, GRUB is compiled as a UEFI application -- an EFI executable stored on the EFI System Partition (usually at /EFI/ubuntu/grubx64.efi or similar).

The firmware loads this EFI application directly. There is no MBR boot code, no INT 0x13, no real mode. The UEFI version of GRUB uses UEFI boot services instead of BIOS interrupts for disk access and video output. But once GRUB is running, the user-facing experience is the same: same config file, same menu, same linux and initrd commands.

Key term: EFI System Partition (ESP) A FAT32-formatted partition that UEFI firmware can read directly. It contains bootloader executables (.efi files) and related configuration. On Linux systems, the ESP is usually mounted at /boot/efi or /efi.

When Things Go Wrong

GRUB failures are common enough that every Linux administrator encounters them. The most frequent scenarios:

"error: unknown filesystem" -- GRUB cannot read the partition containing its modules or configuration. This happens when a filesystem is corrupted, when you resize a partition without updating GRUB, or when a GRUB module for the filesystem type was not installed.

"error: file not found" -- GRUB can read the filesystem but cannot find grub.cfg or the kernel. This happens after a kernel upgrade that did not regenerate grub.cfg, or after moving files around in /boot.

Rescue shell -- GRUB loaded its core but could not load normal.mod. You get a grub rescue> prompt with minimal commands. The fix is usually set prefix=(hd0,gpt2)/boot/grub followed by insmod normal and then normal.

In all these cases, the fix involves booting from a live USB, mounting the installed system, and running grub-install and grub-mkconfig to rebuild GRUB from scratch.

GRUB's power comes from its modularity. It carries its own filesystem drivers, so it can read files by path -- not just by sector number. It reads grub.cfg to build a menu, loads the kernel and initramfs into specific memory addresses, fills in the boot parameter structure, and jumps to the kernel entry point. From that jump onward, the bootloader is finished and the kernel is in control.

What Happens Next

GRUB has loaded the kernel image and the initramfs into memory. It has passed the kernel command line and a block of boot parameters. Now the kernel needs to actually start running. But the kernel image on disk is not a simple executable -- it is compressed, and it contains multiple parts. GRUB has found it; now the kernel must find itself.

Next: Finding the Kernel