Walk through what happens on an x86-64 Linux server from power-on until the first long-lived user-space process is running: which component hands off to which, and what is each stage responsible for?

middlemust knowfreq 72%

answer

four handoffs, four owners
firmware, bootloader, kernel, init
two files loaded into RAM
switch_root execs, PID 1 survives
/sbin/init symlinks to systemd

basics

~20 s

Firmware initialises the hardware and loads a bootloader; the bootloader loads the compressed kernel plus an initramfs into memory; the kernel unpacks itself, runs the initramfs to reach the real root filesystem, switches onto it, and execs the system's init as PID 1.

solid answer

~50 s

Four handoffs. First the firmware — legacy BIOS or UEFI — initialises hardware and loads a bootloader: on BIOS that is the boot code in the first disk sector chaining to GRUB2's later stages, on UEFI the firmware itself reads a .efi binary from the FAT-formatted EFI System Partition. Second, GRUB2 reads its generated config, shows the menu, and loads two files into RAM: vmlinuz-<version> and the initramfs, along with the kernel command line containing root=. Third, the kernel decompresses itself, brings up memory management, CPUs and built-in drivers, unpacks the initramfs into a RAM-backed root, and runs its /init. That early user space loads whatever it needs to reach the real root device, mounts it, and switch_roots onto it — exec'ing the real /sbin/init, which on current distributions is a symlink to systemd. PID 1 is never re-created; it is inherited across that exec.

Four handoffs. First the firmware — legacy BIOS or UEFI — initialises hardware and loads a bootloader: on BIOS that is the boot code in the first disk sector chaining to GRUB2's later stages, on UEFI the firmware itself reads a `.efi` binary from the FAT-formatted EFI System Partition. Second, GRUB2 reads its generated config, shows the menu, and loads two files into RAM: `vmlinuz-<version>` and the initramfs, along with the kernel command line containing `root=`. Third, the kernel decompresses itself, brings up memory management, CPUs and built-in drivers, unpacks the initramfs into a RAM-backed root, and runs its `/init`. That early user space loads whatever it needs to reach the real root device, mounts it, and `switch_root`s onto it — exec'ing the real `/sbin/init`, which on current distributions is a symlink to systemd. PID 1 is never re-created; it is inherited across that exec.

code

bash · 10 lines

bash

# what the bootloader actually handed this kernel
cat /proc/cmdline

# the two files loaded into RAM for this boot (RHEL-style, then Debian-style)
ls -l /boot/vmlinuz-"$(uname -r)" /boot/initramfs-"$(uname -r)".img 2>/dev/null ||
  ls -l /boot/vmlinuz-"$(uname -r)" /boot/initrd.img-"$(uname -r)"

# what ended up as PID 1
ls -l /sbin/init
ps -p 1 -o comm=

go deeper

for a junior

Be able to name the four stages in order — firmware, bootloader, kernel, init — and say that the bootloader loads both the kernel and an initramfs into memory before the kernel runs.

for a middle

Explain each handoff mechanically: what the firmware reads, that the command line carries root=, that the initramfs is unpacked into RAM, and that switch_root execs the real init while keeping PID 1.

for a senior

Show you can localise a failure to a stage from what you see on a console, and know which artefacts to inspect — /proc/cmdline, the generated grub config, the kernel ring buffer — rather than reinstalling blindly.

for a principal

Own the boot path as a reliability surface: how many known-good kernel entries you keep, whether /boot has headroom for a regenerated initramfs, and how a fleet recovers when the newest entry is broken.

The chain in one line

Firmware → bootloader → kernel → initramfs → PID 1. Each link only knows enough to start the next one, and each handoff is a point where a broken machine can stop. Being able to name the stage a machine died in is most of the diagnostic value of knowing this chain.

Stage 1 — firmware

At power-on the CPU executes firmware from flash. Legacy BIOS runs POST, then reads the first 512-byte sector (the MBR) of the boot disk and jumps into its 440 bytes of boot code. Almost nothing fits in 440 bytes, so that code only chains to a larger bootloader stage stored elsewhere on disk. UEFI firmware is much bigger: it contains a FAT driver and a boot manager, reads boot entries out of NVRAM, and loads a .efi application from the EFI System Partition. Either way the firmware's responsibility ends the instant it transfers control, and it has no idea what Linux is.

Stage 2 — the bootloader

On most distributions this is GRUB2. It carries filesystem drivers of its own so it can read /boot, and it does three things: presents the menu, loads the kernel image and the initramfs into memory, and passes the kernel command line. Its running config is a generated file — /boot/grub2/grub.cfg on RHEL-family systems, /boot/grub/grub.cfg on Debian/Ubuntu — which you do not hand-edit; the persistent sources are /etc/default/grub and /etc/grub.d/, regenerated with grub2-mkconfig -o … or Debian's update-grub wrapper. RHEL 9 keeps each menu entry in /boot/loader/entries/*.conf per the Boot Loader Specification, edited with grubby. Pressing e at the menu edits the command line for this boot only, which is exactly what makes it a recovery tool.

Stage 3 — the kernel

vmlinuz is not a plain executable: it is a compressed kernel with a small self-decompressing stub. The stub unpacks the real kernel, which then sets up page tables and memory management, starts the scheduler, brings the other CPUs online, and initialises drivers that were built in rather than compiled as modules. It creates an in-memory root filesystem and unpacks the initramfs — a compressed cpio archive — into it. At this point no disk-based filesystem is mounted at all. The kernel then executes /init from that RAM filesystem, and that process is PID 1.

Stage 4 — initramfs and the root pivot

The initramfs exists because a distribution kernel is generic: it cannot have every storage controller and filesystem built in, and the root device may need assembling (software RAID, an encrypted volume, a network-attached disk) before it can be mounted at all. Early user space loads what it needs, waits for the device named by root= (usually root=UUID=…) to appear, mounts it read-only at /sysroot, and then runs switch_root: it moves the /proc, /sys and /dev mounts across, frees the RAM filesystem, chroots into the real root, and execs the real init. Because it is an exec rather than a fork, the process keeps PID 1.

Stage 5 — PID 1

With no initramfs the kernel itself execs the first user process, trying /sbin/init, /etc/init, /bin/init and /bin/sh in turn, and panicking with No working init found if all fail. On current distributions /sbin/init is a symlink to systemd. PID 1 is special to the kernel: it does not receive signals it has no handler for, it inherits and must reap orphaned processes, and if it ever exits the kernel panics with Attempted to kill init!.

bash

ls -l /sbin/init          # -> /lib/systemd/systemd or /usr/lib/systemd/systemd
cat /proc/cmdline         # exactly what the bootloader handed the kernel

Reading the seams

/proc/cmdline is the authoritative record of what the bootloader passed — check it before believing any config file. The kernel ring buffer shown by dmesg begins at decompression, so if you get no kernel messages at all on a console, the failure is at stage 1 or 2, before Linux was ever running.

Where each stage fails

No firmware output or "no bootable device": stage 1, wrong boot mode or dead disk. A GRUB rescue prompt: stage 2, the bootloader cannot find its config or /boot. VFS: Unable to mount root fs: stage 3–4, wrong or missing root=, or an initramfs that lacks the driver for the disk. A shell that never appears after the pivot: stage 5, PID 1 or the services it starts.

## The chain in one line Firmware → bootloader → kernel → initramfs → PID 1. Each link only knows enough to start the next one, and each handoff is a point where a broken machine can stop. Being able to name the stage a machine died in is most of the diagnostic value of knowing this chain. ## Stage 1 — firmware At power-on the CPU executes firmware from flash. **Legacy BIOS** runs POST, then reads the first 512-byte sector (the MBR) of the boot disk and jumps into its 440 bytes of boot code. Almost nothing fits in 440 bytes, so that code only chains to a larger bootloader stage stored elsewhere on disk. **UEFI** firmware is much bigger: it contains a FAT driver and a boot manager, reads boot entries out of NVRAM, and loads a `.efi` application from the EFI System Partition. Either way the firmware's responsibility ends the instant it transfers control, and it has no idea what Linux is. ## Stage 2 — the bootloader On most distributions this is GRUB2. It carries filesystem drivers of its own so it can read `/boot`, and it does three things: presents the menu, loads the kernel image and the initramfs into memory, and passes the **kernel command line**. Its running config is a generated file — `/boot/grub2/grub.cfg` on RHEL-family systems, `/boot/grub/grub.cfg` on Debian/Ubuntu — which you do not hand-edit; the persistent sources are `/etc/default/grub` and `/etc/grub.d/`, regenerated with `grub2-mkconfig -o …` or Debian's `update-grub` wrapper. RHEL 9 keeps each menu entry in `/boot/loader/entries/*.conf` per the Boot Loader Specification, edited with `grubby`. Pressing `e` at the menu edits the command line for **this boot only**, which is exactly what makes it a recovery tool. ## Stage 3 — the kernel `vmlinuz` is not a plain executable: it is a compressed kernel with a small self-decompressing stub. The stub unpacks the real kernel, which then sets up page tables and memory management, starts the scheduler, brings the other CPUs online, and initialises drivers that were built in rather than compiled as modules. It creates an in-memory root filesystem and unpacks the initramfs — a compressed cpio archive — into it. At this point no disk-based filesystem is mounted at all. The kernel then executes `/init` from that RAM filesystem, and that process is PID 1. ## Stage 4 — initramfs and the root pivot The initramfs exists because a distribution kernel is generic: it cannot have every storage controller and filesystem built in, and the root device may need assembling (software RAID, an encrypted volume, a network-attached disk) before it can be mounted at all. Early user space loads what it needs, waits for the device named by `root=` (usually `root=UUID=…`) to appear, mounts it read-only at `/sysroot`, and then runs `switch_root`: it moves the `/proc`, `/sys` and `/dev` mounts across, frees the RAM filesystem, chroots into the real root, and **execs** the real init. Because it is an exec rather than a fork, the process keeps PID 1. ## Stage 5 — PID 1 With no initramfs the kernel itself execs the first user process, trying `/sbin/init`, `/etc/init`, `/bin/init` and `/bin/sh` in turn, and panicking with `No working init found` if all fail. On current distributions `/sbin/init` is a symlink to systemd. PID 1 is special to the kernel: it does not receive signals it has no handler for, it inherits and must reap orphaned processes, and if it ever exits the kernel panics with `Attempted to kill init!`. ```bash ls -l /sbin/init # -> /lib/systemd/systemd or /usr/lib/systemd/systemd cat /proc/cmdline # exactly what the bootloader handed the kernel ``` ## Reading the seams `/proc/cmdline` is the authoritative record of what the bootloader passed — check it before believing any config file. The kernel ring buffer shown by `dmesg` begins at decompression, so if you get no kernel messages at all on a console, the failure is at stage 1 or 2, before Linux was ever running. ## Where each stage fails No firmware output or "no bootable device": stage 1, wrong boot mode or dead disk. A GRUB rescue prompt: stage 2, the bootloader cannot find its config or `/boot`. `VFS: Unable to mount root fs`: stage 3–4, wrong or missing `root=`, or an initramfs that lacks the driver for the disk. A shell that never appears after the pivot: stage 5, PID 1 or the services it starts.

Where does the kernel command line for a normal boot actually come from, and how would you verify what was really used?
GRUB2 embeds it in the generated `grub.cfg` (or the BLS entry under `/boot/loader/entries/`), built from `GRUB_CMDLINE_LINUX` in `/etc/default/grub` when you run `grub2-mkconfig`/`update-grub`. Editing `grub.cfg` directly is lost on the next regeneration. The authoritative record of what the running kernel received is `/proc/cmdline`, which also shows one-off edits made at the GRUB menu.
What does the kernel do if the process it execs as PID 1 exits?
It panics — `Attempted to kill init!` — and stops. The kernel has no way to continue without a PID 1 to reap orphans and own the process tree, so it treats init's death as unrecoverable. That is why booting with `init=/bin/bash` for recovery means you must not simply type `exit`: sync the filesystems and force a reboot instead.
Can a Linux system boot without an initramfs at all?
Yes, if the kernel has the disk controller and root filesystem drivers built in rather than modular, and the root device needs no assembly. Custom and embedded kernels are often built this way, and the kernel then execs `/sbin/init` directly. Distribution kernels ship generic and modular precisely so one image boots any hardware, which is why they always pair with an initramfs.

saying these in an interview costs you the question

Says GRUB starts systemd directly, skipping the kernel
Thinks the BIOS reads ext4 to find the kernel
Believes the initramfs is loaded by the kernel from disk
Claims a new PID 1 is forked after the root pivot
Cannot say where the root= parameter comes from

Walk through what happens on an x86-64 Linux server from power-on until the first long-lived user-space process is running: which component hands off to which, and what is each stage responsible for?

§ answer

basics

solid answer

code

§ go deeper

▾level notes4 levels

▾deep dive~4 min

The chain in one line

Stage 1 — firmware

Stage 2 — the bootloader

Stage 3 — the kernel

Stage 4 — initramfs and the root pivot

Stage 5 — PID 1

Reading the seams

Where each stage fails

▾common follow-ups3 questions

▾red flags5 flags

§ context

▾related questions8 questions

▾related topics4 topics

The chain in one line

Stage 1 — firmware

Stage 2 — the bootloader

Stage 3 — the kernel

Stage 4 — initramfs and the root pivot

Stage 5 — PID 1

Reading the seams

Where each stage fails

answer

go deeper

context