What actually happens when a computer boots
512 bytes, one magic number, and a chain of handoffs from firmware to kernel — traced step by step on a machine you can pause.
Booting is a bootstrapping problem in the literal sense: a computer that can only run programs loaded into memory has to load a program into memory without running a program. The solution is a chain of increasingly capable loaders, each just clever enough to fetch the next.
1. The processor wakes up in 1978
An x86 processor comes out of reset in real mode: 16-bit, no memory protection, and able to address about a megabyte. This is for compatibility with the original 8086, and every modern PC still starts this way before climbing out of it. The first instruction is fetched from a fixed address near the top of memory, which the chipset maps to the firmware ROM.
2. The BIOS takes stock
The BIOS counts memory, initialises the interrupt table, brings up the video card and enumerates disks. Then it does the only interesting thing it does: it walks the boot order, and for each device reads the first 512 bytes into memory at address 0x7C00.
3. Two bytes decide everything
The BIOS checks the last two bytes of those 512. If they are 0x55 0xAA, it considers the sector bootable and jumps to 0x7C00. If not, it moves to the next device. That is the entire contract — no signatures, no verification, no filesystem. A disk is bootable if two bytes say so.
4. 512 bytes is not enough
Half a kilobyte cannot hold a kernel loader that understands filesystems, so real bootloaders are split. The boot sector is stage one: its only job is to locate and load stage two, which is big enough to read a filesystem, show a menu and find the kernel. GRUB, SYSLINUX and the rest all work this way.
5. The kernel takes over
The bootloader loads the kernel, hands it a command line and jumps in. The kernel switches the processor into protected mode — 32-bit, with memory protection and virtual memory — sets up its own interrupt handling, and from that point stops using the BIOS entirely. It drives the hardware itself.
6. Process one
Finally the kernel mounts a root filesystem and starts a single userland process, traditionally /sbin/init. Everything else on the machine descends from it. If that process cannot start, the kernel panics — which is why "unable to mount root filesystem" is such a common and such a final error.
Watching it happen
Boot Buildroot and you skip stages two through four entirely — the emulator loads the kernel directly, so the first thing you see is step five. Boot FreeDOS from a floppy and you get the classic chain in miniature. Boot BootROM and you never leave step three. Three machines, three different depths into the same process.