Understanding Linux Boot Process: From BIOS to Init

Linux Boot Process Overview

POST → BootLoader (MBR) → Kernel (hardware detection, driver loading, root filesystem mount, /sbin/init) → init (reads /etc/inittab, runs init scripts, starts/stops services, launches terminals)

Detailed Step‑by‑Step Analysis

Step 1:

1. POST – When the power button is pressed, the CPU loads the BIOS stored in CMOS into memory. BIOS probes and identifies all motherboard hardware, then follows the configured boot order (CD‑ROM, HDD, floppy, …). It scans each device for a bootable sector; if a device contains an MBR it boots from it, otherwise it continues searching. If no bootable device is found, the boot fails.

Step 2:

2. BIOS finds the hard‑disk MBR (located at cylinder 0, head 0, sector 0, 512 bytes). Inside the MBR it looks for a bootloader (commonly LILO or GRUB; LILO is now rare). The bootloader occupies 446 bytes of the MBR, followed by a 16‑byte partition table and a 2‑byte boot signature. The bootloader is loaded into memory and executed; its main job is to locate the kernel image on disk and load it into memory.

GRUB functions:

Select the kernel image or operating system to boot.

Pass boot parameters (e: edit mode, b: boot).

Optionally protect the boot menu with a password (using grub-md5-crypt).

The kernel image (e.g., vmlinuz-2.6.18-308.el5) resides in the /boot partition. Although the /boot partition is not yet mounted, GRUB knows its location from the root (hd0,0) entry in /boot/grub/grub.conf, where hd0,0 denotes the first hard‑disk’s first partition.

GRUB does not use a mounted filesystem to find the kernel; it directly accesses the first hard‑disk’s first partition (as recorded in the MBR partition table) to locate the kernel file.

GRUB then identifies the filesystem type of the partition using its built‑in modules (it cannot read LVM, so /boot must be a separate partition).

BIOS loads the MBR, which contains GRUB (stage 1). Because GRUB is limited to 446 bytes, it loads additional files from <code>/boot/grub</code> (stage 1.5) that contain filesystem drivers.

Stage 1.5 loads filesystem‑recognition code, enabling GRUB to read the <code>/boot</code> directory. Without this stage GRUB could not locate the kernel.

Stage 2 finally loads the kernel image and the initial RAM disk (<code>initrd‑2.6.18-308.el5.img</code>), then transfers control to the kernel.

Step 3:

GRUB loads the kernel and the initrd image into memory. The initrd is a compressed <code>cpio</code> archive that provides a temporary root filesystem containing essential drivers (e.g., <code>ext3.ko</code>) needed to mount the real root filesystem.

Typical commands to inspect the initrd:

# cp initrd-2.6.18-308.el5.img ~
# mv initrd-2.6.18-308.el5.img initrd-2.6.18-308.el5.img.gz
# gzip -d initrd-2.6.18-308.el5.img.gz
# file initrd-2.6.18-308.el5.img   # shows an ASCII cpio archive
# mkdir test && mv initrd-2.6.18-308.el5.img test/
# cd test
# cpio -id < initrd-2.6.18-308.el5.img   # extracts the archive
# ls lib/   # reveals driver modules such as ext3.ko

Using the drivers from the initrd, the kernel can access the hard‑disk, mount the real root filesystem, and later mount additional pseudo‑filesystems like /proc.

Finally, the kernel executes the first user‑space program /sbin/init, which reads /etc/inittab and performs the remaining system initialization.

Step 4 – Init Process

# Set the default runlevel (e.g., id:3:initdefault:)
# Execute system initialization script (/etc/rc.d/rc.sysinit)
# Start/stop services for the current runlevel (e.g., rc 3)
# Launch six virtual terminals (tty0‑tty5)
# Further details are described in the /etc/inittab documentation.