Understanding the Boot Process: From Power-On to Kernel Loading

1. The First Spark: Firmware (BIOS and UEFI)

When you power on a computer, before any operating system even begins to load, a special piece of software stored on a chip on the motherboard kicks in. This is called firmware. Its job is to perform initial hardware checks and then find and start the operating system's bootloader.

There are two main types of firmware you'll encounter:

• BIOS (Basic Input/Output System): The older, traditional firmware that has been used for decades.
• UEFI (Unified Extensible Firmware Interface): The modern replacement for BIOS, offering more features, better security, and support for larger hard drives.

Regardless of the type, the first thing the firmware does is run a POST (Power-On Self-Test) to make sure critical hardware like the CPU, memory (RAM), and storage devices are working correctly.

To understand the roles of BIOS and UEFI and their key differences, let's watch a segment from a video designed specifically for the Linux+ exam.

As the video explained, a critical difference between BIOS and UEFI is how they locate the next stage of the boot process on a hard drive:

• BIOS systems typically use a disk partitioned with a Master Boot Record (MBR). The BIOS looks for executable code in the first 512 bytes of the disk (the MBR) and runs it.
• UEFI systems use a more modern partitioning scheme called GUID Partition Table (GPT). The UEFI firmware looks for a special EFI System Partition (ESP) which contains bootloader files (as .efi files).

This diagram provides a simple visual comparison of the two boot paths.

2. The Hand-off: The Bootloader (GRUB)

Once the firmware (BIOS or UEFI) has done its job, it hands over control to a bootloader. The bootloader is a small but powerful program whose main responsibility is to load the operating system's kernel into memory.

For the vast majority of modern Linux distributions, the bootloader is GRUB 2 (GRand Unified Bootloader, version 2).

The key functions of GRUB are:

• Providing a menu: If you have multiple operating systems (e.g., Linux and Windows) or multiple Linux kernels installed, GRUB displays a menu allowing you to choose which one to boot.
• Loading the kernel: Once a selection is made (or after a timeout), GRUB locates the chosen Linux kernel file on the disk.
• Loading the initial RAM disk: Along with the kernel, GRUB also loads a crucial file called the initial RAM disk. We'll cover this in the next step.
• Executing the kernel: Finally, GRUB places these files into memory (RAM) and passes control to the kernel, effectively starting Linux.

To get a more detailed look at the role of GRUB 2, let's return to the video from Shawn Powers.

While GRUB's function is the same on both BIOS and UEFI systems, its technical implementation differs. For a practical look at how GRUB is stored on MBR vs. GPT disks, the following resource is very helpful.

3. The Core Awakens: Kernel and initramfs

At this point, GRUB has loaded the Linux kernel into memory and handed over control. The kernel is now running! The kernel file is typically named something like vmlinuz-version. The 'z' at the end indicates that it is compressed to save space, so its first action is to decompress itself.

Now, the kernel faces a classic chicken-and-egg problem: to finish booting, it needs to access files on the main hard drive (the "root filesystem"). To do that, it needs the correct drivers for the storage hardware (e.g., SATA, NVMe, etc.). But those drivers are files located on the very drive it can't yet read!

The solution is the initial RAM filesystem (initramfs).

The initramfs is a small, temporary root filesystem that GRUB loads into memory alongside the kernel. It contains just the essential kernel modules (drivers) needed to access the actual storage devices.

The process is as follows:

1. GRUB loads the kernel (vmlinuz) and the initramfs file into RAM.
2. The kernel starts and uses the initramfs as its temporary root filesystem.
3. Using the drivers from initramfs, the kernel can now "see" and mount the real root filesystem from your hard disk.
4. Once the real filesystem is available, the kernel switches over to it and discards the temporary initramfs. The boot process can now continue by loading all other system services.

This final video segment provides a clear, exam-focused explanation of this critical step.

Summary and Visual Guide

We have covered the entire sequence from power-on to the point where the kernel is in charge. This flowchart provides an excellent visual summary of the steps we've discussed.

Conclusion

In this lesson, we have traced the critical initial moments of a Linux system's startup. Understanding this chain of events is not just theoretical; it's the foundation for diagnosing why a system might fail to boot.

Key Takeaways:

• The boot process begins with the system's firmware (either BIOS or UEFI), which performs a POST.
• The firmware's job is to locate and execute the bootloader, which is GRUB 2 on most Linux systems.
• GRUB presents a menu and then loads the Linux kernel (e.g., vmlinuz) and a temporary filesystem called initramfs into RAM.
• The initramfs contains the necessary drivers for the kernel to mount the real root filesystem, after which the boot process can continue.

So, the kernel is loaded and has access to all the system's files. What happens next? The kernel's very first task is to start a single, special process with Process ID 1. This process is responsible for starting all the other services and programs that make up a running system. In our next lesson, we will explore this crucial next step: explaining the role of the init system (systemd) in initializing the system.