Linux Boot Process: From BIOS to systemd

1. Stage 1: BIOS/UEFI - The Hardware Handshake

When you press the power button, the first code that runs isn't part of the operating system. It's firmware embedded on the motherboard. This firmware can be the older BIOS (Basic Input/Output System) or the modern UEFI (Unified Extensible Firmware Interface).

Your ECE background gives you a head start here. Think of this stage as the system's own hardware diagnostic routine.

Key Functions:

• Power-On Self-Test (POST): The firmware quickly checks that essential components like the CPU, RAM, and storage controllers are present and functional.
• Device Initialization: It prepares the hardware for the next stage.
• Locating the Bootloader: Its final job is to find a bootable device (like a hard drive or USB stick) based on a configured boot order, and hand control over to the program in that device's boot sector—the bootloader.

How to Spot a Failure at This Stage:
If a system fails here, it's almost always a hardware problem. The symptoms are unmistakable because the operating system hasn't even begun to load.

• The system powers on (fans spin, lights are on), but there is no video output.
• The motherboard emits a series of beep codes.
• The system freezes on the vendor's logo screen (e.g., Dell, HP).

Troubleshooting at this stage involves checking physical connections, reseating components like RAM, or using the server's remote management interface (which we'll cover later) to check hardware logs.

2. Stage 2: GRUB - The Operating System Chooser

Once the BIOS/UEFI finds a bootable disk, it executes the GRUB (Grand Unified Bootloader). GRUB is the bridge between your hardware firmware and the Linux kernel.

Key Functions:

• Presents a Boot Menu: If you have multiple operating systems or multiple kernel versions installed, GRUB displays a menu to let you choose which one to boot.
• Loads the Kernel: GRUB's primary job is to load two critical files into memory: the Linux kernel and the initramfs. We'll discuss initramfs in the next section.

How to Spot a Failure at This Stage:
If the BIOS/UEFI ran successfully but GRUB fails, you'll see a very specific kind of error on the screen.

• The screen shows a minimal prompt, like grub>.
• You see an error message like error: no such partition followed by a grub rescue> prompt. This means GRUB was loaded but can't find its configuration files or the kernel.

Let's get practical. You can interact with GRUB during the boot process. This is the first step in troubleshooting many boot-related issues.

Knowing how to get into the GRUB menu is essential, as we'll see in the next section for recovering from a bad kernel update.

3. Stage 3: Kernel and initramfs - Starting the Core OS

After you select an option in GRUB (or it proceeds automatically), GRUB loads the Linux Kernel (vmlinuz) and an Initial RAM Filesystem (initramfs) into memory and hands control to the kernel.

• Kernel: This is the heart of Linux. It takes control of the CPU and memory and begins initializing all the hardware using its built-in drivers.
• initramfs: This is a clever part of the process. The kernel itself can't contain every possible driver for every piece of hardware. The initramfs is a small, temporary root filesystem loaded into RAM. It contains just enough drivers and tools (e.g., for your specific disk controller or LVM) needed for the kernel to mount your actual root filesystem. Once the real root filesystem is mounted, the initramfs is discarded.

How to Spot a Failure at This Stage:
This is where you might encounter the dreaded Kernel Panic.

• The screen fills with text and then freezes, with the last lines often including the words "Kernel panic - not syncing".
• Common messages include "VFS: unable to mount root fs" or errors about missing modules. This often means the initramfs doesn't have the right driver to access your main storage.

Practical Troubleshooting: Recovering from a Bad Kernel Update
A common cause for a kernel panic is a faulty update. The new kernel might have a bug or be incompatible with a driver. Linux automatically keeps older, working kernels for this exact situation.

4. Stage 4: systemd - Launching User Space

Once the kernel has mounted the root filesystem, its final job is to start the very first user-space process, which on all modern Linux systems is systemd. This process has a Process ID (PID) of 1.

From this point on, systemd is in charge. It reads its configuration and starts all the background services (daemons) needed for a functioning system, such as networking, logging, and the login prompt itself.

Key Functions:

• PID 1: It's the "mother of all processes." Every other process on the system is a child of systemd.
• Manages Services: It starts, stops, and monitors services.
• Achieves "Targets": Instead of old-fashioned runlevels, systemd works towards targets. The most common are:
  • multi-user.target: A command-line only environment.
  • graphical.target: A full desktop environment.

How to Spot a Failure at This Stage:
If the kernel loads but the system fails to become fully usable, the problem is likely with systemd.

• The boot process hangs while trying to start a specific service. You'll often see a message like "A start job is running for..." with a timer.
• The system boots to a login prompt, but a key service is not working (e.g., you can't get a network address, or you can't SSH in).
• The system drops you into an "emergency mode" or "rescue mode" shell.

Practical Investigation:
Let's use some commands to inspect systemd on a running system.

When a systemd-managed service fails, your main troubleshooting tools will be systemctl status <service-name> and journalctl -u <service-name> to check its status and logs.

Summary: A Troubleshooting Flowchart

You've now traced the entire boot process. Each stage hands off to the next, and each has its own unique failure signatures. This flowchart provides a fantastic summary and a mental model for troubleshooting.

Conclusion

You now have a structured framework for diagnosing one of the most critical failures a system can experience. Instead of guessing, you can systematically analyze the symptoms to pinpoint the problem's location.

Key Takeaways:

• Stage 1: BIOS/UEFI - Initializes hardware. Failures are usually hardware-related (no video, beep codes).
• Stage 2: GRUB - Loads the kernel. Failures result in a grub> or grub rescue> prompt.
• Stage 3: Kernel & initramfs - Starts the OS core. Failures often lead to a Kernel Panic. You can often recover by booting a previous kernel via the GRUB menu.
• Stage 4: systemd - Starts user-space services. Failures manifest as hangs during boot or non-functional services (like networking) after boot.

In our next lesson, we will put this knowledge to practical use. We'll learn how to boot from a live USB and use chroot to gain access to a broken system for repairs, which is the direct follow-up to diagnosing a problem at the GRUB or kernel stage.