Boot Process Steps

Why This Matters

The boot process is the fundamental sequence that takes a computer from powered-off hardware to a fully functional operating system. Every step in this sequence demonstrates core OS concepts: firmware interfaces, bootloaders, kernel responsibilities, and process management.

Don't just memorize the order of steps. Know what each phase accomplishes, which component is responsible, and how failures at different stages look different from each other. Exam questions often ask you to identify where in the boot process a particular error occurred, or to compare legacy (BIOS/MBR) and modern (UEFI/GPT) approaches.

---

Firmware and Hardware Initialization

Before any software runs, the system must verify that hardware is functional and configure low-level settings. The firmware stored on the motherboard takes control immediately after power is applied. No operating system code is involved yet.

Power-On Self-Test (POST)

• Hardware verification: the CPU begins executing firmware code that checks RAM, storage controllers, and connected peripherals for basic functionality
• Error reporting uses beep codes or LED patterns to indicate failures before any display output is available. Different beep patterns correspond to different hardware failures (e.g., memory not detected vs. GPU failure).
• Device enumeration identifies and initializes hardware components, building a map of available resources for later stages

BIOS/UEFI Initialization

• Firmware interface loads configuration data and prepares hardware for the boot process. UEFI is the modern replacement for legacy BIOS.
• Boot configuration allows users to set device priority, enable/disable hardware features, and configure security options like Secure Boot
• Hardware abstraction provides standardized interfaces that bootloaders use to access storage and display devices

---

Boot Device and Partition Discovery

Once hardware is ready, the system must locate bootable media and understand its partition structure. The firmware reads just enough data from disk to hand off control to the bootloader stored there.

Boot Device Selection

• Boot order priority determines which devices (SSD, HDD, USB, network) the firmware checks first for bootable code
• Bootable media detection searches for a valid boot signature on each device in sequence until one is found
• Fallback behavior moves to the next device in the list if the primary boot device fails or contains no valid boot signature

Master Boot Record (MBR) or GUID Partition Table (GPT) Loading

• MBR stores partition information and a small bootloader in the first 512 bytes of the disk. It's limited to 4 primary partitions and a maximum disk size of 2TB.
• GPT uses a more robust structure with redundant headers, supporting disks well over 2TB and up to 128 partitions by default
• Partition table reading identifies the active/bootable partition so the firmware knows where to find the bootloader

---

Bootloader and Kernel Handoff

The bootloader is the first significant software component loaded from disk. Its job is narrow but critical: locate the kernel, load it into memory, and transfer control. On multi-boot systems, this is also where OS selection happens.

Bootloader Execution

1. The firmware loads the bootloader program (e.g., GRUB for Linux, Windows Boot Manager for Windows) from the active partition into memory.
2. If multiple operating systems or kernel versions are installed, the bootloader presents a selection menu.
3. The bootloader reads its configuration files to find the kernel image path and the initial RAM disk (initrd/initramfs) path.

Kernel Loading

1. The bootloader copies the compressed kernel image into RAM and decompresses it.
2. Boot arguments are passed to the kernel (e.g., root= to specify the root filesystem device) that configure its behavior.
3. The bootloader jumps to the kernel's entry point, and the bootloader's role ends entirely.

---

Kernel Initialization and System Setup

Once the kernel has control, it must initialize itself and prepare the environment for user-space programs. Memory management, process scheduling, and device drivers all come online during this phase.

Kernel Initialization

1. Core subsystem setup initializes the scheduler, memory manager, and interrupt handlers that form the OS foundation.
2. Device driver loading activates drivers for storage, network, and input devices. These are either compiled directly into the kernel or loaded as modules from the initial RAM disk.
3. Root filesystem mounting makes the primary filesystem accessible. It's typically mounted read-only at first so integrity checks (like fsck) can run safely before switching to read-write.

Init Process or systemd Startup

• PID 1 is assigned to the first user-space process. Traditionally this was init (SysVinit), but on most modern Linux systems it's systemd.
• Service management starts background daemons (networking, logging, cron) according to dependency graphs or runlevel configurations.
• Target/runlevel selection determines which services launch based on the desired system state: multi-user (no GUI), graphical (full desktop), or rescue mode (minimal recovery environment).

---

User Space and Session Initialization

The final boot phase prepares the system for human interaction. By this point, the kernel is running, essential services are active, and the system is ready to authenticate users and launch their environments.

User Space Initialization

• Daemon startup launches background services like sshd (remote access), cron (scheduled tasks), and network managers that run independently of any user session
• Configuration parsing reads system-wide settings from /etc/ and prepares default environments for incoming users
• IPC setup establishes inter-process communication channels (D-Bus, sockets) that desktop environments and applications rely on to communicate

Login Prompt or GUI Display

• Authentication interface presents either a text console (getty/login) or a graphical display manager (GDM, LightDM, SDDM)
• Credential verification checks the username and password against local files (/etc/passwd, /etc/shadow) or networked authentication services like LDAP
• Session initialization loads user-specific configurations (shell profile, desktop settings) and starts the user's default environment

---

Quick Reference Table

---

Self-Check Questions

1. Which two boot phases are handled entirely by motherboard firmware before any disk access occurs?

2. A system fails to boot and displays "No bootable device found." At which stage did the failure occur, and what are two possible causes?

3. Compare and contrast MBR and GPT: what limitations does MBR have that GPT addresses, and which firmware type is each associated with?

4. If a Linux system boots to a command prompt instead of a graphical desktop, which component likely failed or was misconfigured: the kernel, systemd, or the display manager? Explain your reasoning.

5. Trace the handoff of control during boot. List the four major components that sequentially take control from power-on to user login, and identify what each one loads or starts.