Pressing a power button starts a chain of events that takes a machine from completely inert hardware to a running operating system with services, networking, and a login prompt. Each stage has a clear job and passes control to the next. Understanding this sequence turns boot failures from mysterious black boxes into diagnosable problems.

Stage 1: Firmware (BIOS or UEFI)

The first thing that runs on a PC after power-on is not Linux — it is firmware stored in a chip on the motherboard. This firmware initialises the CPU, memory, and hardware buses, then locates a bootable device.

BIOS (legacy)

BIOS (Basic Input/Output System) is the original firmware standard. It:

1. Runs a Power-On Self-Test (POST) to check hardware
2. Scans configured boot devices in order (disk, USB, network)
3. Reads the first 512 bytes of the chosen device (the Master Boot Record, MBR)
4. Executes the code it finds there

The MBR contains the first stage of the bootloader and the partition table. Its 512-byte size limit is why early GRUB required a multi-stage loading process.

UEFI (modern)

UEFI (Unified Extensible Firmware Interface) replaces BIOS on hardware manufactured since roughly 2012. It:

1. Runs POST and hardware initialisation
2. Reads the GPT partition table to find the EFI System Partition (ESP)
3. Looks in the ESP for a bootloader application (a .efi file)
4. Loads and executes that application

# Check whether your system uses BIOS or UEFI
ls /sys/firmware/efi               # exists on UEFI systems, absent on BIOS

# See the EFI boot order
efibootmgr -v

# List the EFI System Partition
lsblk -o name,fstype,mountpoint | grep -i efi
ls /boot/efi/EFI/

# See UEFI variables
ls /sys/firmware/efi/efivars/

UEFI’s Secure Boot feature verifies that the bootloader is signed by a trusted key before running it. On most distributions, the GRUB binary is signed by the distribution’s key, which the firmware trusts.

Stage 2: Bootloader (GRUB)

GRUB (GRand Unified Bootloader) is the standard bootloader for Linux. On BIOS systems, it is installed in the MBR and a gap after it. On UEFI systems, it is an .efi file on the ESP.

GRUB’s jobs:

1. Present a boot menu (or boot the default after a timeout)
2. Load the selected Linux kernel into memory
3. Load the initramfs image into memory
4. Pass the kernel parameters to the kernel
5. Jump to the kernel’s entry point

GRUB configuration

# The generated GRUB configuration
cat /boot/grub/grub.cfg

# The settings that control grub-mkconfig
cat /etc/default/grub

# Key settings in /etc/default/grub:
# GRUB_DEFAULT=0                    # which menu entry to boot by default
# GRUB_TIMEOUT=5                    # seconds to show menu before auto-boot
# GRUB_CMDLINE_LINUX=""             # extra kernel parameters (all boots)
# GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"  # extra params for normal boot

# After changing /etc/default/grub, regenerate the config:
sudo update-grub                    # Debian/Ubuntu
sudo grub2-mkconfig -o /boot/grub2/grub.cfg   # Fedora/RHEL

# Install GRUB to a disk (repair or reinstall)
sudo grub-install /dev/sda          # BIOS
sudo grub-install --target=x86_64-efi --efi-directory=/boot/efi   # UEFI

# List available menu entries
grep -E "^menuentry|submenu" /boot/grub/grub.cfg

The GRUB menu

When GRUB shows a menu, you can:

• Select a kernel version with arrow keys and Enter
• Press e to edit the boot parameters for this boot only
• Press c to enter the GRUB command line

The most common rescue intervention: press e on the default entry, find the linux line, and add single or change ro quiet splash to rw init=/bin/bash to get a root shell when the system will not boot normally.

Kernel parameters

Parameters passed on the GRUB kernel line control kernel behaviour:

# See the parameters the running kernel was booted with
cat /proc/cmdline

# Common useful kernel parameters
# quiet          suppress most boot messages
# splash         show Plymouth graphical boot screen
# single         boot to single-user (rescue) mode
# nomodeset      disable kernel mode setting (for GPU problems)
# init=/bin/bash start bash instead of systemd (for recovery)
# rd.break       drop into a shell inside the initramfs
# systemd.unit=rescue.target   boot to rescue target
# mem=4G         limit visible RAM (for testing or broken hardware)

Stage 3: Kernel loading

The kernel is a compressed image at /boot/vmlinuz-version. GRUB decompresses it and loads it into memory, then passes control to the kernel’s entry point.

The kernel initialises immediately:

1. Sets up memory management (paging, virtual address space)
2. Detects and initialises CPU features
3. Detects and initialises hardware: PCI bus, interrupt controllers, timers
4. Mounts the initramfs as a temporary root filesystem
5. Runs the init process inside the initramfs

# See the current kernel version
uname -r
uname -a                           # full info: kernel, hostname, arch

# See all installed kernels (Debian/Ubuntu)
ls /boot/vmlinuz*
dpkg -l | grep linux-image

# See kernel boot messages from the current boot
dmesg
dmesg | grep -i error
dmesg | less

# See kernel messages from a previous boot
journalctl -k -b -1

# See when specific hardware was initialised
dmesg -T | grep -i eth0
dmesg -T | grep -i nvme
dmesg -T | grep -i usb

Stage 4: initramfs

The initramfs (initial RAM filesystem) is a compressed cpio archive at /boot/initrd.img-version. The kernel unpacks it into a tmpfs and treats it as the root filesystem for the early stages of boot.

The initramfs contains:

• Essential kernel modules for storage controllers, filesystems, and encryption
• udev rules for device discovery
• Tools like fsck for filesystem checking
• Scripts to set up LVM, RAID, or LUKS encryption before the real root is available
• The pivot process that switches from the temporary root to the real root

# See the initramfs file
ls -lh /boot/initrd.img-$(uname -r)

# Inspect the contents of the initramfs
lsinitramfs /boot/initrd.img-$(uname -r) | head -30

# Rebuild the initramfs (after adding a module, for example)
sudo update-initramfs -u            # Debian/Ubuntu (update current kernel)
sudo update-initramfs -u -k all     # update for all installed kernels
sudo dracut -f                      # Fedora/RHEL
sudo mkinitcpio -P                  # Arch

# Add a module to the initramfs (Debian/Ubuntu)
# Add the module name to /etc/initramfs-tools/modules
echo "dm-crypt" | sudo tee -a /etc/initramfs-tools/modules
sudo update-initramfs -u

The rd.break kernel parameter drops you into a shell inside the initramfs before the real root is mounted. This is the recovery entry point when the root filesystem itself is the problem.

Stage 5: systemd (PID 1)

Once the real root filesystem is mounted, the initramfs runs /sbin/init (or whatever the init= parameter specifies). On modern systems this is systemd.

systemd then:

1. Reads its configuration from unit files in /lib/systemd/system/ and /etc/systemd/system/
2. Determines the default target (multi-user.target or graphical.target)
3. Resolves the dependency graph for that target
4. Starts units in parallel, respecting After= and Requires= constraints
5. Activates the login manager or getty processes for user login

# See the default target
systemctl get-default

# See what is being started and in what order
systemctl list-dependencies multi-user.target

# Find what is slowing down boot
systemd-analyze
systemd-analyze blame
systemd-analyze critical-chain

# See a timeline plot of boot (outputs SVG)
systemd-analyze plot > /tmp/boot.svg

systemd-analyze output

Startup finished in 3.201s (firmware) + 2.455s (loader) + 1.843s (kernel) + 887ms (initrd) + 8.321s (userspace) = 16.707s
graphical.target reached after 8.293s in userspace

The four phases are:

• firmware: UEFI/BIOS initialisation
• loader: GRUB
• kernel: kernel initialisation and initramfs
• userspace: systemd and service startup

systemd-analyze blame lists the services that took the most time, which is where to look first when boot is slow.

The full picture

Power on
  |
  v
Firmware (BIOS/UEFI)
  - POST
  - Locate bootable device
  - Load GRUB
  |
  v
GRUB
  - Show menu (or auto-boot)
  - Load kernel (/boot/vmlinuz-...)
  - Load initramfs (/boot/initrd.img-...)
  - Pass kernel parameters
  - Jump to kernel
  |
  v
Kernel
  - CPU and memory init
  - Hardware detection (dmesg)
  - Decompress and mount initramfs
  - Run /init inside initramfs
  |
  v
initramfs
  - Load storage and filesystem modules
  - Set up LVM/RAID/LUKS if needed
  - Run fsck on root filesystem
  - Mount real root filesystem
  - Pivot root (switch to real /)
  - Exec /sbin/init (systemd)
  |
  v
systemd (PID 1)
  - Read unit files
  - Resolve dependency graph
  - Start services in parallel
  - Reach default.target
  |
  v
Login prompt

Boot failure recovery

Can not get past GRUB

# Boot from a live USB
# Mount the root filesystem
sudo mount /dev/sda2 /mnt
sudo mount /dev/sda1 /mnt/boot/efi   # if UEFI

# Chroot into the system
sudo mount --bind /dev /mnt/dev
sudo mount --bind /proc /mnt/proc
sudo mount --bind /sys /mnt/sys
sudo chroot /mnt

# Reinstall GRUB
grub-install /dev/sda
update-grub

Root filesystem is read-only or corrupted

# At GRUB, press e and add to the kernel line:
# rw init=/bin/bash

# At the resulting shell:
fsck -fy /dev/sda2
mount -o remount,rw /
# Fix whatever is broken
# Then:
exec /lib/systemd/systemd

Service is preventing boot from completing

# At GRUB, press e and change quiet splash to:
# systemd.unit=rescue.target

# Or to get to a minimal shell:
# systemd.unit=emergency.target

# From rescue or emergency mode, disable the offending service
systemctl disable problematic-service
journalctl -u problematic-service -b -1

Understanding the boot sequence means knowing exactly which log to read and which tool to use when each stage fails.

Frequently Asked Questions

What is the Linux boot process?

The Linux boot process has five main stages. First, the firmware (BIOS or UEFI) runs hardware initialisation and locates a bootable device. Second, the bootloader (almost always GRUB) is loaded from that device and presents a menu to select a kernel. Third, the selected kernel is loaded into memory and begins executing, initialising hardware and the memory management subsystem. Fourth, the kernel mounts an initial RAM disk (initrd or initramfs) to access the tools needed to mount the real root filesystem. Fifth, the kernel hands control to PID 1 (systemd on modern systems), which starts all services and brings the system to the desired target.

What is the difference between BIOS and UEFI?

BIOS (Basic Input/Output System) is the original PC firmware standard. It runs a 16-bit environment, searches for a bootable MBR (Master Boot Record) at the start of a disk, and has a 2 TB disk size limit. UEFI (Unified Extensible Firmware Interface) is the modern replacement. It supports larger disks (GPT partition tables), 64-bit execution, Secure Boot (which verifies bootloader signatures), a built-in shell, network booting, and a more organised firmware menu. Most computers manufactured after 2012 use UEFI, though many support a legacy BIOS compatibility mode.

What is GRUB?

GRUB (GRand Unified Bootloader) is the bootloader used by most Linux distributions. Its job is to load the Linux kernel and initramfs into memory and pass control to the kernel. GRUB presents a boot menu where you can select a kernel version, pass additional kernel parameters, or boot into recovery mode. Its configuration lives at /boot/grub/grub.cfg, which is generated by the grub-mkconfig command from templates in /etc/grub.d/ and settings in /etc/default/grub.

What is initramfs?

initramfs (initial RAM filesystem) is a small compressed filesystem image that the kernel unpacks into a temporary root filesystem immediately after loading. It contains the minimal tools and drivers needed to mount the real root filesystem: storage drivers, filesystem tools, device mapper for LVM or RAID, and decryption tools for encrypted disks. Once the real root is mounted, the kernel pivots to it and discards the initramfs. The initramfs image lives at /boot/initrd.img-kernel-version.

What is a kernel panic?

A kernel panic is a fatal error from which the Linux kernel cannot recover. The kernel halts execution, prints a panic message to the console, and (depending on configuration) either hangs indefinitely or reboots automatically. Common causes include a corrupted root filesystem, a missing or damaged initramfs, a hardware failure the kernel cannot work around, or a bug in a kernel module. The panic message usually identifies the cause and the call stack. /proc/sys/kernel/panic controls whether the system reboots automatically (0 = hang, positive number = seconds to wait before rebooting).