From power on to a login prompt

Pressing the power button starts a chain where each stage knows just enough to find and start the next. Nothing in it is magic, and knowing the order is what makes a machine that will not boot diagnosable.

The chain

firmware (BIOS or UEFI)
   |  runs a power on self test, finds a bootable device
bootloader (GRUB, systemd-boot, Windows Boot Manager)
   |  loads the kernel image and an initial ramdisk into memory
kernel
   |  initialises memory, detects devices, mounts the real root filesystem
init process (PID 1, usually systemd)
   |  starts services in dependency order
login prompt

Why an initial ramdisk exists

The kernel must mount the root filesystem, but the driver for the disk it lives on may itself be a module stored on that filesystem. The initial ramdisk breaks the circle: a small filesystem loaded straight into memory containing just enough drivers to reach the real one.

PID 1 is special

The first process the kernel starts has process id 1 and two unusual properties. It adopts orphaned processes, so nothing is ever parentless. And if it exits, the kernel panics, because there is nothing left to run.

$ ps -p 1 -o pid,comm
  PID COMMAND
    1 systemd

This matters outside kernel work more than it sounds, because inside a container your application is usually PID 1, and if it does not reap the children it spawns they accumulate as zombies.

What starts, and in what order

Older systems ran numbered shell scripts in sequence, so a slow service delayed everything after it. Modern init systems build a dependency graph and start independent services in parallel, which is why a machine that took ninety seconds to boot now takes eight.

Reading which stage the message came from is most of the diagnosis.