Linux - Booting Process

What's the Linux Booting Process?

1. BIOS/UEFI Initialization:

   • When you power on the computer, the BIOS (Basic Input/Output System) or UEFI (Unified Extensible Firmware Interface) firmware runs first.
   • It performs hardware checks (POST - Power-On Self-Test), initializes basic hardware, and identifies the boot device (e.g., hard drive, SSD, USB drive, network).

2. Bootloader Takes Over:

   • The BIOS/UEFI loads the first stage of the bootloader (like GRUB, systemd-boot, LILO) from the boot device's Master Boot Record (MBR) or EFI System Partition (ESP).
   • The bootloader's primary job at this stage is to locate and load the Linux kernel image and the initial RAM disk (initrd or initramfs) into memory (RAM).
   • Finding the Kernel: The bootloader reads its configuration file (e.g., grub.cfg) which tells it where the kernel image (e.g., /boot/vmlinuz-5.15.0-generic) and the initrd file (e.g., /boot/initrd.img-5.15.0-generic) are located on the disk.
   • Loading into Memory: The bootloader copies the entire kernel image and the initrd image from the disk into specific locations in RAM.

3. Kernel Image Execution Begins (Initial Phase):

   • Once loaded, the bootloader transfers control to the kernel image by jumping to its entry point in RAM.
   • Decompression (Often): Kernel images (vmlinuz) are usually compressed (using gzip, bzip2, lzma, zstd, etc.) to save disk space and potentially speed up loading from slower devices. The very first thing the loaded kernel code often does is decompress itself into a different area of RAM.
   • Basic Hardware Setup: The kernel performs essential, low-level hardware setup: initializing the CPU(s), setting up basic memory management (like page tables), and initializing the console so boot messages can be displayed.
   • Parsing Boot Parameters: The kernel parses the command-line arguments passed to it by the bootloader (defined in the bootloader config). These arguments control kernel behavior (e.g., root=/dev/sda2, quiet, splash, nomodeset).

4. Mounting the Initial RAM Disk (initrd/initramfs):

   • The kernel locates the initrd/initramfs image (which the bootloader also loaded into RAM).
   • It mounts this image as a temporary root filesystem directly in memory.
   • Purpose of initrd: The initrd contains essential kernel modules (drivers) and utilities needed to mount the actual root filesystem. This is crucial because the drivers for the storage controller (SATA, NVMe, RAID, LVM) or the specific filesystem type (ext4, XFS, Btrfs, encrypted filesystems) might not be built directly into the main kernel image itself (to keep it smaller and modular).

5. Loading Essential Drivers:

   • The kernel executes an initial program (often /init) from the initrd.
   • This program uses utilities within the initrd to detect hardware and load the necessary kernel modules (drivers) from the initrd into the running kernel (e.g., using modprobe).

6. Mounting the Real Root Filesystem:

   • Once the drivers for the storage device containing the actual root filesystem are loaded, the /init script (or program) within the initrd mounts the real root filesystem (specified by the root= kernel parameter) onto a temporary mount point (like /sysroot).

7. Pivoting the Root Filesystem:

   • The kernel performs a critical operation called pivot_root. This switches the root filesystem (/) from the temporary in-memory initrd to the actual filesystem just mounted from the disk (e.g., /sysroot becomes the new /).
   • The initrd is then typically unmounted, and its memory is freed.

8. Executing the Real Init System:

   • The kernel now executes the primary init process from the real root filesystem (usually /sbin/init, which is often a symbolic link to systemd, SysVinit, OpenRC, etc.).

9. Kernel's Ongoing Role:

   • From this point on, the kernel image isn't being "loaded" anymore; it is the running core of the operating system.
   • The init system takes over user-space initialization (starting services, mounting other filesystems, setting up networking, providing login prompts).
   • The kernel continues to run in the background, managing hardware, scheduling processes, managing memory, handling system calls from user applications, and enforcing security.

In essence, the kernel image is loaded by the bootloader, sets itself up, uses the initrd to load drivers needed for the real filesystem, switches to that real filesystem, and then hands off control of user-space initialization to the init system while continuing its core OS duties.

What is vmlinuz?

vmlinuz is the compressed image of the kernel. It gets uncompressed, loaded into memory, and executed at boot.

Kernel image isn't an executable kernel, but a "compressed file" of the kernel instead, compressed into either zImage or bzImage formats with zlib.

What is initrd?

The "rd" in initrd stands for RAM Disk.

So, initrd breaks down as:

• init: Initial (referring to the early stage of the boot process)
• rd: RAM Disk (a disk drive simulated in the computer's RAM)

Purpose:

The initrd is a temporary root filesystem loaded into memory during the Linux boot process. Its main job is to contain the necessary kernel modules (drivers) required to mount the actual root filesystem. This is crucial when the drivers needed for the storage controller (SATA, SCSI, NVMe) or filesystem type (LVM, encrypted volumes, network filesystems) are not built directly into the kernel itself.

Once the kernel loads the drivers from the initrd and successfully mounts the real root filesystem, it discards the initrd and continues the boot process using the real filesystem.

Note: While technically initrd refers to an actual block device image, modern Linux systems mostly use initramfs (initial RAM filesystem), which is a cpio archive unpacked into memory (tmpfs). However, the term initrd is often still used colloquially to refer to this initial RAM-based filesystem concept. The purpose remains the same.

What is a generic Linux kernel image?

The one that the distribution's developers create specifically to boot on a wide variety of hardware; the device drivers for this generic kernel image are included as loadable kernel modules.