You press the power button and, on the surface, everything happens in an instant: a logo, a loading bar and the desktop. But in those seconds the machine runs a remarkably orderly protocol involving the electronics, a micro operating system you never even see, and a process manager that organises hundreds of tasks in parallel. This is what really happens, layer by layer, until your desktop appears.
The firmware that wakes up first: UEFI
When you switch the computer on, the CPU begins its life by executing its very first instruction from a fixed memory address that points to a flash memory chip. There lives the firmware (the software burned into hardware) that replaced the old BIOS: UEFI (Unified Extensible Firmware Interface). Think of it as a tiny operating system of its own, stored on the motherboard, which has no idea what Linux or Windows is: it only knows how to wake the hardware up.
Its first job is the POST (Power-On Self Test), a battery of self-checks that verifies the CPU, RAM and essential components respond. If something critical fails, you will not see it on screen: it warns you with beep sequences or motherboard LEDs. Then it reads the partition table — on modern machines a GPT (GUID Partition Table), the successor to the old MBR scheme — and locates the boot partition using boot entries, which you can manage with efibootmgr.
Security comes in here too. With Secure Boot enabled, UEFI uses the TPM chip to build a cryptographic chain of trust: it will only load bootloaders and kernels signed with keys it considers legitimate. It is the first link in a chain that, in theory, stops malicious code from sneaking in before your system does.
The bootloader: master of ceremonies
When UEFI finishes, it hands control to a bootloader; the most common one on Linux is GRUB. It reads its configuration (grub.cfg), shows you the classic menu, and decides which kernel to load and with which parameters. It is a go-between that connects firmware and operating system: it does not boot anything by itself, it only prepares the ground so the kernel can take over.
The kernel unpacks and builds a temporary scaffold
The kernel, the heart of the OS that manages memory, processes and devices, decompresses itself into RAM and needs to load the drivers for disks and controllers. But that is a chicken-and-egg problem: without drivers it cannot read the disk, yet the drivers live on the disk. The solution is the initramfs (initial RAM filesystem), a small compressed filesystem — a cpio archive — that the bootloader loads into RAM and which holds just the drivers needed to mount the real system. Once the actual disk is mounted, the kernel does a pivot_root and switches to the real filesystem as its root.
PID 1: systemd orchestrates a parallel boot
With the filesystem available, the kernel launches the first userspace process, PID 1, which on modern distributions is systemd. This is the great conductor: it reads its units (units of work describing services, mounts and targets), orders their startup, and groups them into targets, the modern equivalent of the old runlevels. Reaching graphical.target means arriving at the graphical environment.
Unlike the old SysV init, which started services one after another in series, systemd starts them in parallel when they have no dependencies on each other, speeding up the boot enormously. It also places each service in its own cgroup (control group), the kernel mechanism for grouping processes and limiting their CPU or memory usage. At the same time, systemd-udevd detects and configures connected devices, while user-session management is handled by logind.
The desktop: the final stop
With the essential services up, a display manager (GDM on GNOME, SDDM on KDE) shows the login screen. Behind the scenes, a graphics server — traditionally X11, increasingly Wayland — and a compositor take care of drawing windows on screen. Userspace processes talk to each other through D-Bus, the message bus by which applications request services from the system.
A boot that feels like magic because of its speed
The fascinating part is that every link in this chain — firmware, POST, Secure Boot, bootloader, kernel, initramfs, PID 1, graphics manager — is a safety valve: if any one of them fails, the next one never runs and the system stops right there, protecting everything already built. That it all fits together in a few seconds, without you seeing any of it, is the surest sign the protocol is doing its job.
