What happens when you press a computer’s power button?

You press the power button. A light comes on, perhaps a fan starts, then a logo appears. Before you reach the login screen, several layers of hardware and software have already done their part.

The operating system is stored on a drive, but the computer first needs enough working hardware to read it. Firmware starts the processor’s early setup, makes memory usable and prepares the devices needed to load the next program.

This walkthrough follows a typical UEFI PC from power-on to login, then explains how other systems differ and what a stalled startup can tell you.

What counts as a boot?

Not every press of the power button starts from the same state. That distinction matters when explaining a fault or comparing startup times.

• A cold boot builds a fresh operating-system session from a powered-down state instead of restoring one. The previous session's volatile state is no longer relied upon.
• A restart, or warm boot, resets the system while power remains available. Firmware and devices are reinitialised, but some hardware may retain state and some checks may take a shorter path.
• Sleep preserves the running session, usually in RAM, while most of the machine uses little power. Waking resumes that session; it is not a fresh boot.
• Hibernation writes restorable system state to storage and powers down. The next start restores that state instead of building every layer from nothing.
• Hybrid or fast startup combines parts of shutdown and hibernation. On Windows, for example, Fast Startup can restore a saved kernel session while a restart takes the fuller initialisation path.

A complete power-off may clear controller state that survives a restart. A fault that happens only when waking from sleep points towards a different part of the startup process. Record which kind of start fails.

Which parts make startup possible?

Four groups of components work together during startup:

• Power and control. The power subsystem creates stable voltages. The motherboard or system-on-chip distributes them and carries the clocks, reset signals and interconnects through which the machine coordinates.
• Compute and working memory. The CPU executes instructions. Registers, processor caches and RAM hold the code and data it is actively using.
• Persistent code and configuration. Storage keeps the operating system and data while power is absent. Platform firmware keeps the first executable code and non-volatile boot configuration the machine needs before storage is under OS control.
• Input and output. Controllers connect displays, storage, USB devices and networks. Some are required to reach a usable system; others can fail without stopping the core boot.

Each group needs something from the others. Startup puts those dependencies in an order the machine can follow.

How instructions and data move

The CPU does not normally fetch every instruction directly from an SSD. Modern processors typically look first in small, nearby caches, then farther cache levels and RAM. The precise cache arrangement is specific to the processor. The broad trade-off is stable: locations closest to a core are faster and smaller; RAM is larger working space; storage is larger and persistent but much slower to access.

Booting moves code into places where it can be used. Early firmware may execute from boot ROM or flash with temporary processor-local resources. Firmware establishes DRAM, then loads the next program into it. The operating-system loader eventually places the kernel and its supporting data in memory, while the cache hierarchy fills as the CPU executes instructions.

Devices sit behind interconnects and controllers: PCI Express may connect an NVMe SSD, while SATA or USB follows a different path. A capable controller can transfer data directly to or from RAM using direct memory access, then raise an interrupt to tell the CPU that work completed. Firmware controls enough of this machinery to find the next stage. Operating-system drivers later take over the same hardware.

From the power button to the first instruction

The power button sends a request to the machine’s power-control circuitry.

Power, reset and clocks

On an ATX-style desktop, standby power is available while the machine is plugged in. Pressing the button signals motherboard control logic, which requests the main supply rails. When regulated outputs are ready, a power-good signal allows the startup sequence to continue. A laptop or system-on-chip uses different power-management circuitry, often coordinated by an embedded controller, but the responsibility is similar: sequence the required power domains safely.

The rails do not become usable at exactly the same instant. Clocks have to settle and reset signals keep processors and controllers in a known state until their prerequisites are ready. Only then is the main processor released to execute.

The reset vector

A processor does not wake with knowledge of Windows, Linux or a file path. Its architecture defines a reset state and a first location from which execution begins. On a conventional x86 PC, that reset path leads into platform firmware stored in non-volatile flash. Many systems-on-chip begin in immutable on-chip Boot ROM, which verifies or locates a later firmware stage.

If there are no lights, fans or display output, begin with power and early hardware setup. The main operating system is unlikely to be involved yet. Lights or fans alone do not show that the CPU, memory or display is working.

Firmware builds a usable platform

Modern PCs generally use UEFI-based platform firmware. Legacy PCs used BIOS firmware, and “BIOS” remains a colloquial name for the firmware settings screen. UEFI is more precise: it standardises the interface and boot environment that firmware presents to loaders and operating systems. It does not prescribe every internal step a manufacturer uses to initialise the board.

Memory training and hardware discovery

Many PC implementations follow the related UEFI Platform Initialization architecture. Its early work establishes a trusted execution context and temporary resources. Pre-EFI Initialization then brings up permanent memory. A later driver environment performs much of the processor, chipset and platform initialization, discovers buses and devices, and constructs the services the boot manager can use.

DRAM is not immediately ready merely because it has power. Firmware has to configure the memory controller and train timing and signal parameters for the installed modules. It also enumerates important controllers, builds a map of usable memory and makes enough display, storage and input capability available, where needed, to select and launch the next program.

What POST does, and does not, prove

Power-On Self-Test, or POST, is a familiar umbrella term for checks around this work, not one universal test suite. The platform vendor decides what to test, what a fast path may skip, and how failure is reported. A successful logo or firmware screen proves that enough of the platform worked to produce it. It does not prove that every device is healthy or that an operating system can load.

If firmware cannot establish working memory or another essential dependency, it may stop before normal display output exists. Diagnostic lights, beep codes and repeated reset attempts give the platform another way to report where it stopped.

UEFI chooses what to run

Once the platform is usable, the UEFI boot manager applies firmware policy. Variables held in non-volatile configuration storage describe boot options. BootOrder gives their normal order; BootNext can request a one-time choice. Each Boot#### entry contains attributes and a device or file path telling firmware what to try.

A typical local operating-system entry points to an .efi executable on the EFI System Partition, a small FAT-formatted partition used by firmware and OS boot components. That is not the only route. Firmware can use removable-media fallback paths, network sources, platform recovery applications or another configured device path. If one option fails, policy may try another.

The selected executable may be another boot manager, a compatibility shim, a recovery application or the first-stage OS loader. These names describe different responsibilities. Firmware chooses an acceptable boot option; an OS-aware loader knows how to prepare a particular operating system. Linux can even present its kernel as a UEFI executable through the EFI stub, so a separate GRUB-like loader is not universal.

The operating system takes ownership

Loader and early userspace

The selected loader uses UEFI Boot Services to read files, obtain the platform memory map and access devices before the full operating system is available. It locates the kernel, places the required code and data in RAM, supplies configuration and prepares whatever early environment that operating system needs.

Linux commonly uses an initramfs: a small, in-memory filesystem containing early drivers and scripts. It can assemble storage, find the real root filesystem and prompt for or obtain an encryption key. Windows packages the responsibilities differently: Windows Boot Manager selects an entry, the OS Loader loads the kernel and required early drivers, and the kernel continues the startup. The names vary; the need to reach the system volume before ordinary services exist does not.

The firmware-to-kernel boundary

On UEFI, ExitBootServices() marks a concrete ownership change. Before a successful call, firmware still owns Boot Services resources and the loader can use them. Afterwards, Boot Services are gone and the operating system is responsible for continued platform operation. A limited set of UEFI Runtime Services can remain available for tasks such as reading firmware variables or the real-time clock, but it is not a general device-management layer.

The kernel configures virtual memory, interrupts and process scheduling. It activates operating-system drivers, discovers or rechecks hardware and opens the system volume or root filesystem. Devices that firmware accessed through its drivers and services now come under a different software owner.

User space makes the machine recognisable

The kernel hands off to the first system and user-space processes. On Linux, an init or service-manager process starts the rest. Windows and other systems use different process trees, but the boundary is similar: privileged kernel code manages hardware and isolation, while user space starts services, networking, authentication and the desktop or shell.

Reaching the login screen means the machine has passed through power setup, firmware, a loader, the kernel and much of user space. A service or peripheral can still fail after that point.

How other computers differ

The six-stage sequence is a model, not a claim that every computer contains the same firmware or files. A legacy x86 PC uses BIOS conventions and may start code from a disk boot sector. A current PC normally uses UEFI. Windows, Linux and BSD systems attach different loaders and early environments to that interface.

Apple silicon begins from immutable Boot ROM and a hardware root of trust, then verifies Apple-specific loader stages before the kernel collection runs. Other ARM and system-on-chip platforms use their own chains, sometimes with several trusted firmware stages. A virtual machine presents virtual firmware and devices supplied by a hypervisor. A network-booted machine may obtain its loader or system image without local storage.

Across these systems, follow the same questions: where does execution begin, how does memory become usable, which program loads next and when does the operating system take over?

Why one startup takes longer than another

Boot time is not a pure measure of CPU speed. Firmware may retrain memory, enumerate many devices, wait for a network path or retry a slow controller. The loader may have to unlock encrypted storage. The kernel may rebuild system caches, check a filesystem or initialise drivers. User space may apply updates and start services before showing a login screen.

A resume or hybrid start can skip much of that work because it restores saved state. A restart can be slower because it deliberately takes a more complete path. Firmware “fast boot” settings may also skip device discovery or diagnostics. Faster is not automatically healthier; it often means that more assumptions were reused.

A failed boot tells you where to look

When startup stops, note the last thing you can see. A firmware menu, loader error, recovery screen and failed desktop point to different stages.

The stage narrows the investigation without proving the cause. Faulty power or memory can cause errors later in startup, and a broken display can hide a machine that is still running.

Record exact messages, diagnostic lights and beep codes. Check whether firmware sees the expected amount of memory and the storage device. Compare a restart with complete power removal. Disconnect non-essential peripherals. If only resume fails, focus on the power-state transition and the firmware and drivers involved. Each observation removes some possible owners from the problem.

Security begins before login

Early startup code runs before the protections people normally associate with a computer: login controls, application permissions, endpoint security and most monitoring. If that code is replaced, it can shape what the operating system sees before the OS can defend itself.

One less obvious detail: the early trust boundary can extend beyond the motherboard. An expansion device such as a graphics card or network adapter may expose a UEFI driver or option ROM before operating-system drivers load, while storage devices and controllers run firmware of their own. Secure Boot policy can authorise UEFI images, but an authorised signature is not a vulnerability scan.

Several controls are often discussed together, but they answer different questions.

• Secure Boot asks: may this code run? With it enabled, UEFI authorises each image it loads against the platform's allowed hashes and certificates and its revocation policy. A valid signature supports provenance and integrity under that policy; it does not prove the code has no vulnerabilities. Secure Boot itself does not require a TPM.
• Measured Boot asks: what startup events occurred? On supported PC platforms, boot components hash defined events and extend cumulative values into protected TPM Platform Configuration Registers. A separate event log provides the detail a verifier needs to reconstruct and assess that evidence. Measurement usually does not block a changed component by itself.
• Disk encryption asks: who may read stored data? It conceals data while the volume is locked. It does not validate the bootloader, and it cannot protect data from authorised software after the volume is unlocked.
• Firmware resiliency asks: can the platform protect, detect and recover? Authorised update mechanisms, write protection, change detection and a secure recovery path matter because a compromised or damaged firmware image can prevent the normal OS recovery tools from running.

The controls reinforce one another without becoming interchangeable. An encryption key can be sealed to expected TPM measurements, so a changed boot state triggers a recovery-key prompt instead of automatic release. The prompt protects a boundary, but only if the recovery key was stored safely. A platform can enforce Secure Boot without measuring to a TPM, or measure an event that policy still allows to run.

Some bootkits tamper with early OS loading; firmware implants sit lower and can be more persistent. Firmware updates, Secure Boot policy, TPM-backed recovery information and disk-encryption keys therefore need the same operational care as operating-system patches.

# Read timing for the current boot.
systemd-analyze time
# Inspect the time-critical chain of unit activation.
systemd-analyze critical-chain

# Read the kernel's recorded boot time.
sysctl kern.boottime
# Show elapsed uptime (and current load information).
uptime

# Read only the recorded operating-system boot timestamp.
Get-CimInstance -ClassName Win32_OperatingSystem |
  Select-Object -ExpandProperty LastBootUpTime

Follow the last successful step

Power makes the hardware ready. Firmware prepares the platform. A loader starts the operating system, and services make it usable.

When something fails, start with the last step that completed. Record its message, identify what should happen next and check that stage’s dependencies.

You do not need to memorise every boot file to use this approach. Knowing whether the problem appears before firmware, during loading or after the kernel starts gives you a much better place to investigate.

If you want to carry that boundary-and-handoff view into software, start by modelling the responsibilities, then use views such as the C4 model to explain how the larger system fits together.