# How Your Computer Boots

> What actually happens between pressing the power button and reaching a login screen - firmware, bootloader, and kernel handing off control in sequence.


---

# How Your Computer Boots

You press the power button. A few seconds later - sometimes a minute, if it's an old machine having a bad day - you're looking at a login screen or a desktop. In between, a surprising amount of handoff happens: firmware waking up the hardware, a small program finding and loading a much bigger program, and that bigger program taking over the entire machine. Each stage exists because the one before it *has to stop trusting itself* and hand control to something that knows more.

This guide walks that chain in order - each link only makes sense once you know what came before it.

## How to read this

Read it start to finish; the phases build on each other. Phase 1 covers the moment power arrives: firmware waking the hardware and finding something bootable. Phase 2 is the bootloader's one job - finding and loading a kernel. Phase 3 is the kernel taking over the machine and handing off to whatever puts a shell or desktop in front of you. The examples cover both the BIOS/GRUB world and the UEFI/Windows Boot Manager world, because the stages are the same shape either way.

## The phases

1. [Power to POST to firmware](01-power-to-post.md) - what BIOS/UEFI actually does before anything else can run.
2. [The bootloader's job](02-the-bootloader.md) - finding and loading the kernel, and what a dual-boot menu really is.
3. [Kernel init to login screen](03-kernel-init-to-login.md) - the kernel taking over hardware and handing off to init/systemd or Windows' session manager.


---

# Power to POST to firmware

The instant you press the power button, there is no operating system anywhere in the picture. No Windows, no Linux, no macOS - nothing has loaded yet, because nothing *can* load yet. RAM is empty. The CPU has no idea what program to run. The only thing that exists at this moment is a small chip on the motherboard holding a program that never goes away: the **firmware**.

That firmware is what you know as **BIOS** (Basic Input/Output System) on older machines, or **UEFI** (Unified Extensible Firmware Interface) on nearly everything made in the last decade or so. Same job, different generation of tooling. It's the first code the CPU ever executes, and its entire purpose is to get the machine into a state where an operating system *could* run - it doesn't run one itself.

## The first job: wake up the hardware

The moment the CPU gets power, it jumps to a fixed memory address that's wired to point at the firmware chip, not at RAM - RAM is empty and untested at this point, so nothing useful could live there yet. The firmware's first task is basic and unglamorous: figure out what hardware exists.

```text
1. CPU powers on, jumps to the firmware's entry point (not RAM - RAM is untested)
2. Firmware initializes the memory controller so RAM becomes usable
3. Firmware enumerates hardware: keyboard, storage controllers, GPU, USB
```

*What just happened:* before this point, the machine doesn't even know it has a keyboard or a hard drive attached. The firmware has to probe the hardware and initialize each piece enough that it responds - this is the literal meaning of "booting," pulling yourself up by your own bootstraps with nothing to stand on yet.

## POST: the self-test you never see unless something's wrong

Once hardware is minimally awake, the firmware runs the **Power-On Self-Test**, or **POST**. This is a quick health check: is RAM responding correctly, is a GPU present, are the storage controllers alive. You mostly never see this happen because it takes a fraction of a second on healthy hardware - the manufacturer's logo you glimpse on screen *is* POST finishing successfully.

You only notice POST when it fails. A stick of RAM seated wrong produces a series of beeps from the motherboard speaker instead of a boot - that's POST refusing to continue because a basic component didn't respond. No operating system, no error message on screen even, because the video output itself might not be confirmed working yet. Beep codes are POST's only language when the screen can't be trusted.

> POST isn't optional ceremony. It's the firmware refusing to hand control to a bootloader until it has some confidence the CPU, memory, and basic I/O work.

## Finding something to boot

With hardware confirmed alive, the firmware needs one more thing: a device to boot *from*. This is where BIOS and UEFI differ in mechanism, though not in intent.

**BIOS** walks a configured list of devices - hard drive, USB, network - in order, and for each one reads the very first sector of the disk (512 bytes, called the **Master Boot Record** or MBR). If that sector ends with a specific two-byte signature, BIOS treats it as bootable and hands control to whatever code lives there.

**UEFI** works differently: it reads a proper partition table (**GPT**, GUID Partition Table) and looks for a dedicated **EFI System Partition** - a small FAT-formatted partition containing `.efi` files, recognizable programs rather than a raw 512-byte blob. This is more structured, supports larger disks, and is part of why UEFI machines generally boot faster than old BIOS ones.

```text
BIOS + MBR:   read disk's first 512 bytes -> check for boot signature -> jump to it
UEFI + GPT:   read EFI System Partition -> find a .efi bootloader file -> execute it
```

*What just happened:* both approaches solve the identical problem - "where do I find the next program to run?" - but UEFI's answer is a filesystem with named files, while BIOS's answer is "whatever raw bytes happen to sit in a fixed disk location." That difference is why UEFI eventually replaced BIOS as the industry standard, though many people still say "BIOS" out of habit even when their machine runs UEFI.

## Secure boot, briefly

Modern UEFI firmware supports **secure boot**: before executing that `.efi` bootloader file, the firmware checks its cryptographic signature against keys it trusts. If the signature doesn't match - because the bootloader was tampered with, or it's an unsigned OS installer - firmware refuses to run it. It's a small trust check that closes a real attack window: malware that infects the boot chain before an OS (and its antivirus) ever loads. This guide won't go deeper, but the check exists at exactly this handoff point.

Once firmware finds a valid boot target, its job is done. It hands the CPU over to that code and steps out of the picture - which is exactly where the bootloader picks up.


---

# The bootloader's job

Firmware handed off control to a small program sitting on disk, and that program has exactly one job: find the operating system's **kernel** - the core piece of the OS that manages hardware, memory, and processes - load it into memory, and jump to it. That small program is the **bootloader**. On Linux machines it's usually **GRUB** (GRand Unified Bootloader); on Windows it's the **Windows Boot Manager**. Different names, same responsibility.

The bootloader is not the operating system, and it doesn't manage hardware or run programs. It's a loader, full stop - a program whose entire purpose is to get a bigger program into memory correctly and then get out of the way.

## Why you need a separate stage at all

Why doesn't firmware load the kernel directly, skipping the bootloader entirely? Two practical reasons. First, firmware is deliberately minimal and generic - it doesn't know how to parse a modern kernel image, decompress it, or set up the specific memory layout that kernel expects. Second, a bootloader can offer *choices*, and firmware can't reasonably do that job.

That second reason is where dual-boot menus come from.

## What a dual-boot menu is

If you've ever seen a menu at startup asking "Windows or Ubuntu?" - that's the bootloader, not firmware, presenting a list. GRUB, for instance, reads a configuration file listing every operating system it knows how to load, each entry pointing at a specific kernel file (and any parameters that kernel needs) on a specific partition.

```text
GRUB menu entries (conceptually):
  "Ubuntu"          -> /boot/vmlinuz-6.8.0  on partition 2
  "Windows Boot Mgr"-> bootmgfw.efi         on the EFI System Partition
```

*What just happened:* the bootloader isn't magically aware of every OS on your disk - it was configured (usually automatically, during OS installation) with an explicit list of entries. Install a second OS after the first, and its installer typically rewrites that configuration to add itself as a new menu entry, sometimes politely, sometimes overwriting the other bootloader entirely, which is the classic dual-boot horror story.

Pick an entry - or let the default one auto-select after a timeout, which is what happens the other 99% of the time you boot - and the bootloader moves on to loading that OS.

## Finding and loading the kernel

Once an entry is chosen, the bootloader has real work to do:

```text
1. Locate the kernel image file on disk (e.g. vmlinuz-6.8.0, or Windows' ntoskrnl.exe path)
2. Read it into memory at the address the kernel expects
3. Load an initial filesystem image if the kernel needs one (initramfs / initrd, on Linux)
4. Pass boot parameters (which disk is root, kernel flags, etc.)
5. Jump execution to the kernel's entry point
```

*What just happened:* step 3 deserves a second look. On Linux, the bootloader often loads a small temporary filesystem called an **initramfs** into memory alongside the kernel. Why? Because the kernel might need drivers to even *see* the real disk - imagine the root filesystem lives on a RAID array or an encrypted volume; the kernel needs some code loaded first to understand how to read that. The initramfs is a minimal, temporary environment that carries just enough drivers and tools to mount the real root filesystem, at which point it's discarded. Windows solves a similar problem differently, but the underlying need - "the kernel can't read its own home yet" - is the same.

> The bootloader's only real skill is finding a specific file on disk and getting it into memory intact. Everything else - dual-boot menus, parameters, fallback options - exists to make that one lookup configurable.

## The handoff

Once the kernel image sits in memory and the bootloader jumps to its entry point, the bootloader's job is complete. It doesn't stick around, doesn't run alongside the kernel, doesn't get called again until the next reboot. Control passes entirely and permanently (until next boot) to the kernel, which is a different kind of program - one built to manage hardware directly rather than find and load a single file.

That handoff is where Phase 3 begins.


---

# Kernel init to login screen

The bootloader jumped to the kernel's entry point and stepped out of the picture. What runs now is fundamentally different from everything before it. Firmware and the bootloader were both temporary - programs whose entire purpose was to get something else running, then disappear. The kernel doesn't disappear. It's going to run continuously, in the background, for the entire time the machine is on, quietly managing every piece of hardware and every process that ever runs.

## The kernel takes over hardware

The kernel's first moments are spent setting up its own view of the machine, independent of whatever firmware had already done:

```text
1. Initialize CPU-level features: interrupt handling, memory management (paging)
2. Detect and initialize devices via drivers: disk controllers, network cards, GPU
3. Set up virtual memory, so every process gets its own private address space
4. Start the scheduler, the part that decides which process runs on the CPU next
```

*What just happened:* the kernel isn't reusing firmware's hardware setup - it re-initializes things its own way, with its own drivers, because it needs far more sophisticated control than firmware ever provided. Firmware only needed to read a few files off a disk; the kernel needs to manage that disk, the network, the GPU, and every process that will ever touch them, for hours or days at a stretch.

## Mounting the root filesystem

Somewhere early in this sequence, the kernel needs to find and mount the **root filesystem** - the `/` on Linux, or the `C:\` on Windows - the filesystem holding the rest of the operating system: system libraries, configuration, every program you'll ever run. Until this mount happens, the kernel is running with nothing but what the bootloader handed it in memory (recall the initramfs from Phase 2, on Linux systems that need one).

```text
kernel finds root filesystem (e.g. on /dev/sda2) -> mounts it at /
kernel switches from temporary initramfs to the real, permanent filesystem
```

*What just happened:* this is the moment the "real" operating system installation, sitting on disk, becomes reachable. Before this, the kernel was working from a minimal, temporary environment; after this, every file the OS ships with is available.

## Handing off to init

With hardware managed and the root filesystem mounted, the kernel does something it's done at every boot since Unix in the 1970s: it starts exactly one process, by convention given process ID 1. That process is called **init**.

On most modern Linux distributions, init is **systemd**. Its job is to bring the rest of userspace to life in the right order: start system services (networking, logging, the display manager), mount any remaining filesystems, and eventually launch whatever presents a login prompt - a text login on a server, or a graphical login manager on a desktop.

```text
kernel starts PID 1 (systemd)
  -> systemd starts targets/services in dependency order
     -> networking, logging, disk services...
     -> display manager (e.g. GDM, SDDM) -> graphical login screen
```

*What just happened:* the kernel deliberately does the absolute minimum here - start one process - and then delegates all the complexity of "what services does a running system need" to that process. This is a deliberate architectural boundary: the kernel manages hardware and processes; init and everything it starts manages *policy* about what a running system should look like.

Windows draws the same boundary with different names. After its kernel (`ntoskrnl.exe`) initializes, it starts the **Session Manager Subsystem** (`smss.exe`), which sets up the environment and hands off to `winlogon.exe` and the services subsystem - eventually presenting the sign-in screen. Same shape as the Linux path: kernel does hardware and process management, then delegates to a small set of processes responsible for getting a user-facing session running.

> Every stage in this whole boot sequence follows the same rule: do the minimum needed to get the next stage running, then step aside. Firmware doesn't run an OS. The bootloader doesn't manage hardware. The kernel doesn't decide which services your desktop needs. Each layer trusts the next one to know its own job.

## Reaching the login screen

Once the display manager (or, on a server, a plain text login prompt) is running, you finally see something asking for a username and password. That single visible screen is the end product of firmware initializing hardware, a bootloader finding and loading a kernel, and that kernel bootstrapping an entire running system underneath it - all of it invisible by design, all of it happening in the handful of seconds after you pressed the power button.

Watch it animated: [how a computer boots](/explainers/Boot.dc.html)

```quiz
[
  {
    "q": "What is the firmware's job in the boot sequence?",
    "choices": [
      "Run the operating system directly",
      "Initialize hardware, run POST, and find something bootable to hand control to",
      "Manage every process for the life of the session",
      "Mount the root filesystem"
    ],
    "answer": 1,
    "explain": "Firmware (BIOS/UEFI) wakes up hardware, self-tests it, and locates a bootloader - then gets out of the way."
  },
  {
    "q": "What does a dual-boot menu actually represent?",
    "choices": [
      "A feature built into the firmware itself",
      "A list of kernels compiled together into one file",
      "Entries the bootloader was configured with, each pointing at a specific OS's kernel",
      "A choice the CPU makes based on which disk is faster"
    ],
    "answer": 2,
    "explain": "The bootloader (like GRUB) reads a configuration file listing known OS entries - it isn't discovering them fresh at every boot."
  },
  {
    "q": "After the kernel initializes hardware and mounts the root filesystem, what does it do next?",
    "choices": [
      "Directly draws the login screen itself",
      "Hands control back to the bootloader",
      "Starts a single init process (like systemd), which brings up the rest of the system",
      "Re-runs POST to double-check hardware"
    ],
    "answer": 2,
    "explain": "The kernel deliberately does the minimum: start PID 1. That init process handles starting services and eventually the login screen."
  }
]
```