📷 Suggested Image for This Post

A vertical flowchart image with five labelled boxes: Firmware → GRUB2 → Linux Kernel → initramfs → systemd, each box a different shade of blue-green. Alt text: Linux x86 boot sequence diagram showing all stages from BIOS to systemd.

BIOS vs UEFI — Key Differences at a Glance

Step 1 — Power On and POST

The instant the power button is pressed, the CPU begins executing instructions from a fixed address in ROM. This is where the firmware (BIOS or UEFI chip) lives. The very first thing it runs is POST — Power-On Self Test.

POST checks that the CPU, RAM modules, and basic hardware are functioning. If something critical fails, the system halts — on older machines you hear beep codes that indicate which component failed.

After POST, the firmware initialises the keyboard controller, display, storage controllers, and PCI bus. It then scans the configured boot order (NVMe SSD, USB, network) looking for a bootable device.

Step 2 — Stage 1 Bootloader (MBR) or EFI Handoff

Step 3 — GRUB2 Runs

GRUB2 (Grand Unified Bootloader version 2) is the main bootloader used on virtually all x86 Linux systems. It reads its configuration from /boot/grub/grub.cfg and, if multiple kernels are installed, shows a menu.

GRUB’s main job is to load two files into RAM and jump to the kernel entry point:

• /boot/vmlinuz-6.x.y — the compressed kernel image
• /boot/initrd.img-6.x.y — the compressed initramfs archive

# What a GRUB2 menu entry looks like in grub.cfg:
menuentry "Ubuntu 24.04, Linux 6.8.0-48-generic" {
    linux  /boot/vmlinuz-6.8.0-48-generic root=UUID=xxxx ro quiet splash
    initrd /boot/initrd.img-6.8.0-48-generic
}

After loading both images, GRUB jumps to the kernel’s entry point. GRUB’s job is now done.

Step 4 — Kernel Takes Control and Initialises Hardware

The Linux kernel is now running. Its very first task is to decompress itself — the vmlinuz file is a self-extracting compressed archive. Once decompressed into RAM, the real kernel code starts executing.

A crucial design principle kicks in here: the kernel makes no assumptions about what the bootloader did. It re-initialises all hardware from scratch — CPU state, MMU (memory management unit), interrupt controllers, timers, PCI enumeration. This is what makes the kernel portable: it can boot correctly whether loaded by GRUB, U-Boot, or any other bootloader.

Step 5 — Kernel Detects and Unpacks initramfs

Once hardware initialisation is mostly done, the kernel checks whether CONFIG_BLK_DEV_INITRD=y is set (it always is on distribution kernels). It locates the initramfs archive that GRUB placed in RAM, decompresses the cpio archive, and mounts it as a temporary root filesystem in RAM.

At this moment the kernel’s / (root) is a tiny in-memory filesystem — not your hard drive. The kernel can now read files from it.

# Verify initramfs support in your running kernel:
grep CONFIG_BLK_DEV_INITRD /boot/config-$(uname -r)
# Output: CONFIG_BLK_DEV_INITRD=y

Step 6 — initramfs /init Script Runs, Loads Modules

The kernel executes /init inside the initramfs. This is a shell script (using busybox utilities) that does the heavy lifting:

• Loads the filesystem driver module — ext4.ko, btrfs.ko, etc. — from the initramfs itself
• If the disk is encrypted: runs cryptsetup to prompt for a passphrase and unlock the LUKS volume
• If LVM is used: activates volume groups with lvm vgchange -ay
• Locates the real root partition using the UUID or device label passed as a kernel parameter by GRUB
• Mounts the real root filesystem at /root inside the initramfs environment

Step 7 — switch_root Transitions to the Real Filesystem

Now that the real root filesystem is mounted and ready, the init script calls switch_root. This is the modern replacement for the older pivot_root system call.

switch_root atomically performs three actions:

• Makes the real disk filesystem the new / for the running kernel
• Unmounts and discards the initramfs tmpfs — freeing that RAM
• Execs /sbin/init on the real filesystem (which is systemd on modern systems)

After this point, the kernel is running with your real disk as its root — the initramfs is completely gone from memory.

Step 8 — systemd Starts as PID 1

The first process the kernel launches in the real userspace is always PID 1. On virtually all modern Linux systems — including most embedded distributions — this is systemd, which replaced the older SysV /sbin/init.

systemd reads unit files from /etc/systemd/system/ and /lib/systemd/system/ and starts all required services in parallel, respecting dependency declarations between them.

# Confirm what is running as PID 1 on your system:
ps -p 1 -o comm=
# Output: systemd

ls -la /sbin/init
# /sbin/init -> /lib/systemd/systemd

Step 9 — System Services Come Up, Login Appears

systemd works through its targets — sysinit.target, basic.target, multi-user.target, and optionally graphical.target. Services like networking, udev, SSH, and the display manager start in parallel where dependencies allow. When all required services reach their target, the login prompt or desktop appears.

# See how long each stage of boot took:
systemd-analyze

# See which services took the most time:
systemd-analyze blame | head -20

Options for Custom Kernel + Secure Boot