Understanding the Linux Boot Process: From Power-On to User Login

Linux boot process can be divided into three stages

Linux boot flowchart

Step 1: Power On

In x86 systems, the top 64 KB of the first megabyte (0xF0000‑0xFFFFF) is mapped to ROM. When the computer is powered on, the CPU resets CS to 0xFFFF and IP to 0x0000, so execution starts at 0xFFFF0, which lies inside the ROM. A JMP instruction in ROM jumps to initialization code, and the BIOS begins its own initialization.

Step 2: BIOS/UEFI Boot

Firmware initialization: after power‑on, the UEFI firmware performs hardware initialization, self‑test, and loads its drivers. Boot device selection: the firmware scans for bootable devices (disk, CD, USB) and chooses one based on the boot order or user settings. UEFI driver loading: drivers on the selected device are loaded to enable further hardware interaction. UEFI application loading: the firmware loads a UEFI application such as a bootloader (e.g., GRUB, rEFInd) from the EFI system partition. Bootloader execution: the loaded bootloader takes control and loads the operating system kernel or other components.

Step 3: Linux Boot

Linux boot – bootloader (MBR)

The BIOS discovers an OS on a disk via the Master Boot Record (MBR), which occupies the first 512 bytes of the disk. MBR consists of two parts: the primary boot code (446 bytes) and the partition table (64 bytes).

Linux boot – EBR/VBR

After locating the MBR, the next steps depend on where the OS resides. (1) If the OS is in a primary partition, the MBR’s bootloader loads the boot code from that partition’s Volume Boot Record (VBR) and transfers control. (2) If the OS is in a logical partition, the MBR’s bootloader follows the extended partition chain to the appropriate Extended Boot Record (EBR) and hands control to its bootloader.

Linux boot – GRUB2 introduction

GNU GRUB (GRand Unified Bootloader) is a multi‑OS boot manager from the GNU project. It implements the multiboot specification, allowing users to select among several operating systems and kernels at startup. Generate configuration: grub2-mkconfig -o /boot/grub2/grub.cfg Install to disk: grub2-install /dev/sda

Linux boot – GRUB2 loading

GRUB2 first loads boot.img into memory at 0x7c00; boot.img loads core.img . On disk boot, diskboot.img loads the rest of core.img , which includes lzma_decompress.img , kernel.img , and module images. Note that this kernel is GRUB’s own kernel, not the Linux kernel. Because the 1 MB real‑mode address space is insufficient, lzma_decompress.img switches the CPU to protected mode (real_to_prot) before decompressing larger components.

Linux boot – PID 0 and PID 1 processes

set_task_stack_end_magic(&init_task) defines init_task as struct task_struct init_task = INIT_TASK(init_task) . This is the first process (PID 0), created without fork or kernel_thread . Initialization steps include: trap_init() – interrupt setup mm_init() – memory subsystem sched_init() – scheduler vfs_caches_init() – rootfs setup start_kernel() → rest_init() – other initializations rest_init creates the second process (PID 1) via kernel_thread(kernel_init, NULL, CLONE_FS) . PID 1 is crucial for the OS.

Linux boot – ramdisk

The init program resides on a filesystem, which itself resides on a storage device. Accessing storage requires drivers; embedding all drivers in the kernel would bloat it. Therefore a memory‑based filesystem (ramdisk) is used initially as the root filesystem because it needs no driver. The ramdisk runs /init , which loads the appropriate storage drivers, mounts the real root filesystem, and then executes the real /sbin/init (or equivalents).

Linux boot – init introduction

PID 1 is the user‑space init process. The kernel tries to execute one of the following in order: <code>if (ramdisk_execute_command) { ret = run_init_process(ramdisk_execute_command); } if (!try_to_run_init_process("/sbin/init") || !try_to_run_init_process("/etc/init") || !try_to_run_init_process("/bin/init") || !try_to_run_init_process("/bin/sh")) return 0; </code> Init system types: SysV (CentOS 5 and earlier) – configuration in /etc/inittab Upstart (CentOS 6) – /etc/inittab , /etc/init/*.conf systemd (CentOS 7) – configuration in /usr/lib/systemd/system , /etc/systemd/system

Linux boot – runlevels

Linux boot – /etc/fstab

After hardware is detected, Linux must mount devices. The /etc/fstab file records automatic mount information, similar to Windows’ auto‑mount. Each line contains six fields: device (or UUID/label), mount point, filesystem type, mount options, dump flag, and fsck order.

Linux boot – user login

Login methods include command‑line login, SSH, and graphical login. Linux is multi‑user; each user must authenticate. The console terminal ( /dev/console ) receives kernel messages, while user programs use virtual terminals ( /dev/ttyN ) or pseudo‑terminals ( /dev/pts/N ). Summary of devices: /dev/console – system console /dev/ttyN – virtual terminals (Ctrl+Alt+F1‑F6) /dev/ttySN – serial terminals /dev/pts/N – pseudo‑terminals (used by SSH, graphical terminals)

Linux boot – user switching

Linux provides six virtual terminals by default (tty1‑tty6). The first is used for the initial login; you can switch between them with Ctrl+Alt+F1‑F6. On some VMs, Ctrl+Alt+F1 opens a graphical terminal, while F2‑F6 open command‑line terminals.

Linux boot process mind map