What a computer does in the seconds before anything appears

The points below about the boot process are ordered by how much difference they make, not by how often they get repeated.

Something has to run before anything is loaded

At power-on the processor begins executing from a fixed address, which must contain code that already exists in non-volatile memory. That firmware is stored in a chip on the board, independent of any drive, and it is the only thing the machine can rely on.

Its first job is bringing up the minimum needed to do anything useful: clocks, voltage regulators and basic buses. Only a fraction of the hardware is usable at this point, and most of it does not yet respond to anything. Everything else in the boot sequence depends on this stage completing correctly, which is why firmware corruption is so serious.

Memory does not work until it is configured

Main memory requires timing parameters, voltages and calibration before it can reliably hold anything at all. The firmware reads a small descriptive chip on each memory module to learn what timings that module expects. It then runs a training routine, testing signal timing across the connections and choosing settings that work reliably.

This training is why a machine with newly changed memory can take noticeably longer to start the first time. Until it completes, the firmware has to run using only the processor's own cache as working space.

Finding something to hand control to

With memory available, the firmware looks for a bootloader in the places it has been configured to search. Older schemes read a fixed area at the start of a drive, while modern ones read a dedicated partition containing loader files.

The bootloader is small, and its role is to locate the operating system kernel and place it in memory correctly. It also assembles information about the hardware and passes it along, since the kernel cannot discover everything by itself. Multiple installed systems are handled here, which is why a boot menu appears before any operating system has started.

The kernel takes over an unfamiliar machine

Once running, the kernel enumerates buses to discover what devices are present and which drivers each one requires. Drivers for the storage containing the rest of the system must load first, which is a genuine ordering problem. Systems solve it with a small temporary filesystem loaded into memory alongside the kernel, containing exactly those drivers.

Mechanically, after the real storage is available, the kernel switches to it and starts the first ordinary process. Everything visible afterwards, including the login screen, is an ordinary program started by that process.

Each stage checks the next one

Secure boot arrangements have each stage verify a signature on the code it is about to run before handing over control. The chain begins in hardware with a key that cannot be replaced, which is what makes the rest of the chain meaningful.

This prevents malicious code inserting itself before the operating system, where it would be effectively invisible afterwards. It also constrains what can be installed, which is why alternative operating systems sometimes require enrolling additional keys. A measurement of each stage can be recorded in a dedicated chip, allowing later software to check what actually ran.

Why starting up got so much faster

Modern systems start many services simultaneously rather than in sequence, waiting only where a genuine dependency exists. Storage that responds in microseconds rather than milliseconds removed most of the waiting that dominated older machines.

At the protocol level, some systems skip the full sequence by saving a memory image and restoring it, which is closer to resuming than to starting. That shortcut means a machine can run for weeks without a genuine restart, and accumulated faults survive an apparent reboot. This is why a full restart still fixes problems that shutting down and starting up again did not.

Everything above, in order of what to do first

1. Something has to run before anything is loaded. At power-on the processor begins executing from a fixed address, which must contain code that already exists in non-volatile memory.
2. Memory does not work until it is configured. Main memory requires timing parameters, voltages and calibration before it can reliably hold anything at all.
3. Finding something to hand control to. With memory available, the firmware looks for a bootloader in the places it has been configured to search.
4. The kernel takes over an unfamiliar machine. Once running, the kernel enumerates buses to discover what devices are present and which drivers each one requires.
5. Each stage checks the next one. Secure boot arrangements have each stage verify a signature on the code it is about to run before handing over control.
6. Why starting up got so much faster. Modern systems start many services simultaneously rather than in sequence, waiting only where a genuine dependency exists.

The takeaway

Every stage exists to make the next one possible, and each one trusts less than you would expect.

Understanding the failure mode tells you more than the feature list does.