Linux Boot Process: From BIOS/UEFI to Your Shell (Systemd, Initramfs, Runlevels)

When a computer turns on, the journey from a blank screen to an interactive shell is orchestrated by several layers of software. Understanding this chain—BIOS or UEFI firmware, bootloader, kernel, initramfs, systemd units, and runlevels—lets you debug boot failures, tune performance, and design custom distributions. This guide walks through each stage, explains the key components, and shows how they fit together in a typical modern Linux installation.

1. Firmware: BIOS or UEFI

The firmware is the first code executed after power‑on. It initializes hardware, performs POST (Power‑On Self Test), and hands control to the bootloader.

1.1 Legacy BIOS

• Boot order: BIOS checks devices in a configured priority list (e.g., HDD → CD/DVD → USB).
• MBR (Master Boot Record): The first sector of the disk contains a tiny bootstrap loader that reads the partition table and loads the bootloader from the active partition.

1.2 UEFI

• Secure Boot: Verifies signatures on the EFI binary before executing it, protecting against tampering.
• UEFI variables: Store configuration such as boot order, firmware settings, and secure‑boot keys.
• Boot Manager: Reads a list of .efi files from the EFI System Partition (ESP) and presents them in the UEFI menu.

1.3 Transition to Bootloader

In both cases the firmware locates the first-stage bootloader—GRUB, systemd‑boot, LILO, etc.—and transfers control. The loader’s job is to load the Linux kernel into memory.

2. Bootloader: GRUB as a Typical Example

The bootloader presents a menu, loads kernel images and initramfs, sets kernel parameters, and finally jumps to the kernel entry point.

GRUB supports advanced features like encrypted disks, network boot (PXE), or graphical themes. Its configuration (/boot/grub/grub.cfg) is usually generated automatically by tools like update-grub.

3. Kernel: The Core of the System

When the kernel starts, it performs several tasks before handing control to userspace:

1. Hardware Detection
   * Parses ACPI tables, PCI devices, and BIOS/UEFI data to discover hardware capabilities.

2. Device Drivers
   * Loads built‑in drivers or requests modules from the initramfs if needed.

3. Memory Management
   * Sets up paging structures and reserves memory for kernel use.

4. Filesystem Support
   * Mounts the root filesystem only after it is ready; otherwise, the kernel defers to initramfs.

5. System Call Interface
   * Exposes system calls to user processes once initramfs finishes.

The kernel stops at a point where it can invoke an init program (traditionally /sbin/init). In modern distributions this is often systemd, but alternatives like SysVinit or OpenRC still exist.

4. Initramfs: Early Userspace

initramfs (initial RAM filesystem) is a temporary, read‑only filesystem loaded into memory by the bootloader. Its purpose is to provide minimal tools and drivers needed before the real root filesystem can be mounted.

4.1 Structure

/   <-- initrd.cpio archive extracted here
├─ bin/
│  ├─ busybox      (minimal shell, utilities)
├─ lib/
├─ sbin/
├─ etc/
└─ scripts/
    └─ init         <-- entry point for the initramfs

4.2 Typical Tasks

Once these tasks finish, the initramfs executes pivot_root to replace itself with the real root filesystem, then runs /sbin/init.

5. Systemd: The Modern Init System

Most mainstream Linux distributions use systemd as the init process (/sbin/init). It replaces the single init binary with a collection of unit files that describe services, sockets, timers, and targets (analogous to runlevels).

5.1 Boot Sequence in systemd

1. systemd‑init starts at PID 1.
2. Reads /etc/systemd/system/ and /usr/lib/systemd/system/.
3. Activates the default target (multi-user.target on most servers, graphical.target on desktops).
4. Starts dependencies in parallel where possible.

5.2 Units vs Runlevels

systemd’s targets replace the old SysV runlevels but retain compatibility through symbolic links (e.g., /etc/rc[0-6].d).

5.3 Common Unit Types

• Service (*.service) – daemon processes.
• Socket (*.socket) – socket activation for on‑demand services.
• Timer (*.timer) – cron‑like scheduling.
• Target (*.target) – grouping of units (runlevels).

5.4 Troubleshooting Boot with systemd

6. The Shell: From /bin/sh to Your Desktop Environment

After systemd finishes starting all necessary services, it launches the login manager (e.g., GDM, LightDM) or a getty on a virtual console. User authentication then spawns:

1. Login shell – typically Bash, Zsh, or Fish.
2. Session startup scripts (~/.bashrc, ~/.profile, /etc/profile.d/*.sh).
3. Desktop environment – GNOME, KDE, XFCE, etc., which in turn starts window manager and applications.

The shell is the final human‑interactable layer; its configuration determines aliases, PATH, prompt, and more.

7. Putting It All Together: A Step‑by‑Step Flow

1. Power‑on → Firmware
   * BIOS/UEFI performs POST, reads boot order, loads bootloader.

2. Bootloader (GRUB)
   * Presents menu, loads vmlinuz + initrd.img, passes cmdline, jumps to kernel.

3. Kernel
   * Detects hardware, mounts initramfs, loads drivers, prepares root filesystem.

4. Initramfs
   * Runs /scripts/init, resolves root device (handles encryption/network), pivots to real root.

5. systemd (PID 1)
   * Reads unit files, activates default target, starts services in parallel.

6. Login Manager / getty → Shell
   * User logs in, shell starts, session scripts run, desktop environment loads.

7. Interactive Session
   * User interacts with the system via terminal or GUI.

8. Common Pitfalls and How to Fix Them

9. Customizing the Boot Process

Advanced users often tweak one or more layers:

• Firmware: Enable Secure Boot, change boot order, adjust POST settings.
• Bootloader: Add custom kernel parameters (nomodeset, acpi=off), create recovery entries.
• Kernel: Build a custom kernel with specific modules or patches.
• Initramfs: Include additional tools (e.g., vim) or scripts for automation.
• systemd: Write drop‑in files to override defaults, set environment variables, or change start order.

Each modification should be documented and version‑controlled (e.g., using Git) so you can revert if something breaks.

10. Conclusion

The Linux boot process is a well‑structured chain of software layers, each with its own responsibilities:

1. Firmware boots the machine and loads the bootloader.
2. Bootloader hands off to the kernel and provides an initramfs.
3. Kernel initializes hardware and launches init.
4. Initramfs prepares the real root filesystem.
5. systemd orchestrates services and targets.
6. Shell/desktop gives the user a working environment.

Understanding these components—and how they interact—empowers you to diagnose boot problems, tailor performance, or create custom distributions. Whether you’re a system administrator, developer, or hobbyist, mastering the boot process is foundational to effective Linux administration.

Frequently Asked Questions (FAQ)

What is the difference between BIOS and UEFI during boot?

BIOS uses a legacy MBR scheme where the first sector contains a small bootstrap that loads the bootloader, while UEFI stores boot entries in an EFI System Partition and can enforce Secure Boot by verifying signatures before execution.

Why does the kernel need an initramfs to mount the root filesystem?

The kernel may lack drivers for storage or filesystems required to access the real root partition; the initramfs supplies those drivers and tools, mounts the actual root, then pivots into it so normal userspace can start.

How does systemd replace the traditional init process?

Systemd starts as PID 1 after the kernel invokes /sbin/init. It reads unit files to launch services, manages dependencies, sets runlevels (targets), and provides a unified journal and socket activation, effectively consolidating many legacy init scripts into a single daemon.

Can I skip using initramfs on a simple system?

If your kernel contains all necessary storage drivers and the root filesystem is directly accessible, you can disable initramfs; however, this limits flexibility (e.g., encrypted disks) and may prevent booting if hardware changes or new modules are required.

Related Articles

• Linux Process Management: Signals, Daemons, and Background Jobs (Practical Guide with Examples)
• Service Crashed – How to Diagnose and Restart Failed Services Gracefully: Root Cause Analysis Guide
• Critical PHP Vulnerabilities (PHP2Shell): CVE-2026-109618 & CVE-2026-109619