Skip to Content
Docs100 Days of AWS CloudLinux FundamentalsThe Linux Boot Process

The Linux Boot Process

The Linux boot process is the sequence of operations that a computer performs from the moment it is powered on until a fully functional operating system is ready for user interaction. It’s the journey from a dead machine to a live system.

Understanding these steps is incredibly valuable for a Cloud and DevOps professional. This knowledge enables you to:

  • Troubleshoot effectively: Diagnose startup failures, identify bottlenecks, and resolve issues related to system initialization.
  • Optimize performance: Tailor the boot sequence to your specific needs, whether for speed, security, or resource utilization.
  • Deepen your system understanding: Gain insight into how a Linux system fundamentally comes to life, a critical skill for managing servers and infrastructure.

While the boot process can be technically intricate, this guide will break it down into a clear, step-by-step chain of events.

Learning Tip: You can begin using Linux without knowing every detail of the boot process. However, for those aiming for deep system administration or advanced Cloud/DevOps roles, mastering these concepts will set you apart.

Boot Process

Terminology to Know

Before diving in, let’s clarify some key terms you’ll encounter:

  • POST: Power-On Self Test, a diagnostic testing sequence run by the computer’s firmware to check hardware components.
  • BIOS/UEFI: Firmware interfaces that initialize hardware during the booting process before handing control to the bootloader.
  • MBR/GPT: Partitioning schemes for storage devices. MBR (Master Boot Record) is older, while GPT (GUID Partition Table) is the modern standard.
  • Bootloader: A small program (like GRUB) that loads the operating system kernel into memory and starts it.
  • Kernel: The core component of the operating system (vmlinuz) that manages hardware and system resources.
  • initramfs: An “initial RAM filesystem” that contains temporary drivers needed by the kernel to mount the real root filesystem.
  • Init System: The first process (PID 1) started by the kernel, responsible for initializing the user space and managing system services (e.g., systemd).

The Boot Process Steps

The entire process can be thought of as a chain of handoffs: Firmware -> Bootloader -> Kernel -> Init System.

BIOS/UEFI Initialization (Firmware)

When you power on your computer, the BIOS (Basic Input/Output System) or UEFI (Unified Extensible Firmware Interface) firmware takes control. It is stored on a chip on the motherboard.

Its first job is to run the POST (Power-On Self Test), which initializes the hardware (like the screen and keyboard) and checks that critical components (like CPU, RAM, and storage) are present and functional.

BIOS vs. UEFI

  • BIOS is the legacy firmware. It is stored in ROM and uses the MBR (Master Boot Record) partitioning scheme, which can only handle disks up to 2TB.

  • UEFI is the modern replacement. It is stored in flash memory (NVRAM) and uses the GPT (Globally Unique Identifier Partition Table) partitioning scheme, which supports disks larger than 2TB and many more partitions.

Boot Process

Loading the Bootloader

After the POST, the firmware’s job is to find and load the bootloader. This process differs significantly between BIOS and UEFI.

Legacy BIOS / MBR Path:

  1. BIOS checks the configured boot order (e.g., Hard Drive, USB).
  2. It reads the first 512-byte sector of the boot device, the Master Boot Record (MBR).
  3. This MBR contains a tiny “bootstrapper” program and the partition table.
  4. The BIOS executes this bootstrapper. The bootstrapper then reads the partition table, finds the “active” (bootable) partition, and loads the main bootloader (like GRUB) from it into RAM.

Modern UEFI / GPT Path:

  1. UEFI consults its boot manager configuration (stored in NVRAM).
  2. Because UEFI has its own drivers, it can understand filesystems (like FAT32). It directly looks for the EFI System Partition (ESP), a special partition formatted with FAT32.
  3. It finds the bootloader application (a .efi file) by following a path stored in its boot manager (e.g., \EFI\ubuntu\grubx64.efi or \EFI\redhat\grubx64.efi) and executes it. This is a much more robust and flexible method.

Bootloader Phase (GRUB)

Now the main bootloader, most commonly GRUB (GRand Unified Bootloader), takes control. It is a small “mini-OS” with one main purpose.

The bootloader’s primary tasks are to:

  • Present a menu: If configured, GRUB shows you a list of available operating systems or kernel versions to choose from.
  • Load the Kernel: It loads the selected Linux kernel (often a compressed file named vmlinuz-...) into RAM.
  • Load the initramfs: It also loads the Initial RAM Filesystem (initramfs-...img) into RAM. This is a temporary root filesystem that the kernel will use to start itself.

Once these are loaded, GRUB hands control over to the kernel.

initramfs

Kernel Initialization

The kernel is now in memory and takes over. It decompresses itself and immediately mounts the initramfs that GRUB provided.

The initramfs is a critical temporary filesystem. The kernel itself can’t possibly contain every driver for every piece of hardware (especially storage controllers).

The initramfs image contains just enough programs and drivers to get the real system started.

  1. It provides the kernel with drivers needed for the specific filesystem (like ext4, XFS).
  2. It uses udev (user device system) to detect the hardware, find the drivers for the mass storage controllers, and load them.
  3. Once the drivers are loaded, it can find and mount the real root filesystem.

With the initramfs mounted, the kernel performs its initialization:

  1. Load Drivers: Using the initramfs, the kernel loads the necessary drivers to see the system’s real hard drives.
  2. Mount Real Root FS: It finds and mounts the real root filesystem (e.g., from /dev/sda1) in read-only mode.
  3. Pivot Root: The kernel “pivots,” unmounting the temporary initramfs and switching to the real root filesystem.
  4. Execute PID 1: The kernel’s final job is to start the very first user-space process: the init system. It executes the program at /sbin/init (which on modern systems is a link to systemd). This process is given Process ID 1 (PID 1).

Init System (systemd)

The kernel’s job is now complete, and the rest of the boot process is handled by the init system (PID 1). On virtually all modern Linux distributions, this is systemd.

systemd is responsible for bringing the system to a usable state:

  1. Remount Root FS: It remounts the real root filesystem (/) in read-write mode.
  2. Read Configuration: It reads its unit files from /usr/lib/systemd/system/ (default) and /etc/systemd/system/ (customizations).
  3. Start Services: It starts all the necessary system services (called “units”) in parallel, respecting their dependencies. This includes services for networking, sshd (for remote login), user login prompts, and much more.
  4. Reach Target: systemd works to achieve a specific “target” (like multi-user.target for a server or graphical.target for a desktop).

Once the target is reached, the system is fully booted and ready for you to log in.

From Power to Prompt

And that’s the complete journey! From the first jolt of electricity, the process moves in a clear chain:

Firmware (BIOS/UEFI) -> Bootloader (GRUB) -> Kernel (+ initramfs) -> Init System (systemd)

Understanding this chain—and where each handoff occurs—is the key to diagnosing almost any boot-related problem in a Linux environment.

Last updated on
The GNU/Linux ArchitectureLinux Filesystems