IEN-003 - Stage 2 — The Bootloader (GRUB)

At the end of the firmware stage, the computer has completed its hardware initialization and identified a bootable storage device.

However, the firmware still faces one fundamental problem:

It knows where the operating system is stored, but it does not know how to load it.

This is where the bootloader comes into play.

The bootloader acts as the bridge between the firmware and the operating system. Its primary responsibility is to locate the Linux kernel, load it into memory, provide the necessary boot parameters, load the initial RAM disk (initrd or initramfs), and finally transfer execution to the kernel.

Without a bootloader, the firmware has no knowledge of Linux-specific file formats, filesystem layouts, or kernel images.

The bootloader is therefore the first piece of software that understands how to start Linux.

---

Why Do We Need a Bootloader?

A common misconception is that the firmware could simply load the Linux kernel directly.

While this is technically possible in certain specialized systems, it is not how general-purpose computers are designed.

The firmware is intentionally kept generic. It can initialize hardware and locate a bootable device, but it does not understand:

• Linux kernels
• Windows boot managers
• FreeBSD kernels
• Multiple operating systems
• Kernel command-line arguments
• Recovery modes

Instead, the firmware loads a small program whose sole purpose is boot management.

That program is the bootloader.

Its responsibilities include:

• Presenting a boot menu.
• Selecting an operating system.
• Loading the kernel into memory.
• Loading the initial RAM disk.
• Passing boot parameters to the kernel.
• Supporting recovery and rescue modes.

---

The Boot Sequence So Far

At this point, the startup sequence looks like this:

Power On
    │
    ▼
Firmware (BIOS / UEFI)
    │
    ▼
POST
    │
    ▼
Boot Device Selected
    │
    ▼
Bootloader (GRUB)
    │
    ▼
Linux Kernel

Notice that Linux itself is still not running.

GRUB is responsible for preparing everything the kernel needs before handing over control.

---

A Brief History of Linux Bootloaders

Before GRUB became the de facto standard, Linux systems used several different bootloaders.

Some of the most well-known include:

Because much of the Infrastructure Engineering Notes series focuses on enterprise environments—including legacy systems such as RHEL 5—we will encounter both GRUB Legacy and GRUB2.

Understanding their differences is essential when performing recovery operations.

---

GRUB Legacy vs GRUB2

Although both bootloaders share the same goal, their internal design differs considerably.

One important point is that GRUB2 is not simply a newer version of GRUB Legacy. It is a complete redesign.

For example, on RHEL 5 you typically edit grub.conf directly. On modern systems, editing grub.cfg manually is discouraged because it is generated automatically from configuration templates.

This distinction becomes important during recovery scenarios.

---

Inside GRUB Legacy

Under legacy BIOS systems, GRUB is traditionally divided into multiple stages.

+----------------------+
| Stage 1              |
| (MBR)                |
+----------+-----------+
           │
           ▼
+----------------------+
| Stage 1.5            |
| Filesystem Support   |
+----------+-----------+
           │
           ▼
+----------------------+
| Stage 2              |
| Full GRUB            |
+----------+-----------+
           │
           ▼
Read grub.conf
           │
           ▼
Load Kernel
           │
           ▼
Load initrd

Let's examine each stage.

Stage 1

Stage 1 occupies the first 446 bytes of the Master Boot Record (MBR).

Its size is extremely limited, so it cannot understand filesystems or locate the Linux kernel directly.

Its only responsibility is to load the next stage.

---

Stage 1.5

Stage 1.5 resides immediately after the MBR in the so-called embedding area.

Unlike Stage 1, it contains basic filesystem drivers.

This allows GRUB to read files from partitions such as ext2 or ext3.

Without Stage 1.5, Stage 1 would have no way to locate the full GRUB program stored within the filesystem.

---

Stage 2

Stage 2 is the full bootloader.

It provides:

• Interactive command line.
• Boot menu.
• Configuration parsing.
• Filesystem access.
• Kernel loading.
• initrd loading.
• Recovery options.

When users refer to "GRUB," they are usually interacting with Stage 2.

---

The GRUB Configuration File

Once Stage 2 starts, GRUB searches for its configuration file.

On GRUB Legacy systems, this file is usually:

/boot/grub/grub.conf

or

/boot/grub/menu.lst

The configuration file defines:

• Available operating systems.
• Default boot entry.
• Boot timeout.
• Kernel image location.
• initrd image location.
• Kernel parameters.

A simplified example looks like this:

title Red Hat Enterprise Linux

root (hd0,0)

kernel /vmlinuz-2.6.18-128.el5 ro root=/dev/VolGroup00/LogVol00

initrd /initrd-2.6.18-128.el5.img

Each line has a specific purpose:

• root (hd0,0) tells GRUB where to find the /boot partition.
• kernel specifies the kernel image and its boot parameters.
• initrd points to the initial RAM disk required during early boot.

If any of these paths are incorrect, GRUB may fail before the Linux kernel even begins execution.

---

Engineering Insight

One of the most common production issues after restoring or cloning a server is that the kernel and initrd files no longer match the entries in grub.conf. GRUB itself is functioning correctly, but it is instructed to load files that no longer exist or belong to a different kernel version. The result can range from a simple "File not found" message to a kernel panic later in the boot process.

This is exactly the type of issue we encountered during our RHEL 5.2 recovery project, and we will revisit it in detail later in this series.

---

Loading the Linux Kernel

Once a boot entry is selected, GRUB performs one of its most important tasks: loading the Linux kernel into memory.

At this stage, the kernel is still just a compressed binary file stored on disk.

GRUB reads this file from the /boot filesystem, copies it into RAM, and prepares the execution environment.

Immediately afterward, it loads the corresponding initrd (or initramfs) image into memory as well.

Only when both components are ready does GRUB transfer control to the Linux kernel.

From that moment onward, the bootloader's job is complete.

The Linux kernel takes over, and the boot process enters its next stage.

---

Common Bootloader Failures

Understanding common failures helps quickly identify whether a problem belongs to the bootloader stage.

A key observation is that none of these errors originate from the Linux kernel. They occur before the kernel starts executing.

---

Summary

The bootloader is responsible for bridging the gap between firmware and the Linux kernel. It locates the kernel image, loads the initial RAM disk, passes kernel parameters, and transfers control to the operating system.

A failure at this stage prevents Linux from starting entirely, making it essential to distinguish bootloader issues from kernel or userspace problems.