Booting is a sequence of handoffs. Each stage exists because the previous one cannot see far enough to do the next job, and each loads something more capable than itself before stepping aside.
Knowing which stage owns which responsibility turns most boot failures from a blank screen into a specific question.
The stages
| Stage | Runs from | Hands off to |
|---|---|---|
| Firmware | Flash on the board | Bootloader |
| Bootloader | Boot partition | Kernel |
| Kernel | Memory, loaded by bootloader | Initial ramdisk |
| Initial ramdisk | Memory | Real root filesystem |
| Init system | Real root filesystem | Nothing, it stays |
Each row can only address hardware the row above has made available, which is why the order cannot be rearranged.
Firmware finds something to run
Firmware initialises memory and enough of the hardware to read a storage device, then looks for a bootloader. Modern systems read a filesystem on a dedicated partition and execute a file from it, which is why bootloaders can be updated like ordinary software.
Secure boot verifies signatures at this point. A failure here appears before any operating system message, which is a useful diagnostic, because nothing on the disk has been trusted yet.
The bootloader has one difficult job
It must load a kernel image and an initial ramdisk into memory using only firmware services, then transfer control with a set of parameters describing where the real root filesystem is.
Those parameters are where most recoverable problems are fixed. Booting with an alternative kernel, adding a debug option, or requesting a single user shell are all edits to that line, and the ability to edit it at boot is why physical access is equivalent to administrative access unless the bootloader is locked.
Why an initial ramdisk exists
The kernel must mount the root filesystem, and that may require a driver for the storage controller, a filesystem module, decryption, or assembly of a volume across several devices. Those things live on the root filesystem, which is not yet available.
The initial ramdisk breaks that circle. It is a small filesystem loaded into memory containing exactly the modules and tools needed to reach the real root, and once the real root is mounted it is discarded.
This is why a kernel update that omits regenerating the ramdisk produces a machine that stops with an inability to find its own root filesystem, despite the disk being present and healthy.
The first process
Once the real root is mounted, the kernel starts one process with identifier one, and every other process descends from it. If that process exits, the kernel panics, because there is nothing left to schedule.
From here the sequence is ordinary software. Filesystems are mounted, devices are configured, services are started in dependency order, and a login prompt appears when the targets required for it are reached.
Reading a failure by stage
No output at all points at firmware or the bootloader. A kernel message followed by a panic about the root filesystem points at the ramdisk or the parameters. Reaching the init system and stopping there points at a service or a mount that is failing, which is ordinary troubleshooting with logs available.
The distinction matters because the tools differ completely. The first two are fixed from firmware settings or a boot menu, and the third is fixed from a shell.
Note: a system that boots after an update but fails after the next reboot is usually a ramdisk that was never regenerated. The running kernel was already in memory, so the omission is invisible until the machine tries to start from disk again.