JOVANA
Explore Library Glossary Getting Started Three Levels Fields How it works Mission
Join the mission
All guides

From Power-On to First Process: The Boot Sequence

There is a chicken-and-egg puzzle at the heart of every computer: who loads the OS before any OS exists to do the loading? This is the relay race from a tiny firmware program to the kernel, the root file system, and the very first process.

The bootstrapping puzzle

By now, climbing this ladder, you have met the kernel as the building manager with the master key, and you know that a program only becomes a process once it is loaded into memory and running. But that raises a genuinely strange question: when you press the power button, RAM is empty and nothing is running. There is no kernel in memory to load the kernel. So who lifts the very first program off the disk? This is the bootstrapping problem, and its name comes from the absurd image of pulling yourself up by your own bootstraps.

The trick is to start from something that does not need loading at all. A small program is permanently baked into a chip on the motherboard — the firmware — so that the instant power arrives, the CPU can begin executing it directly from that chip. Firmware is to a computer what a building's emergency lighting is to a power cut: it does not wait for anything else to come up, because it is wired to be there first. The whole boot sequence is then a relay race, each runner just powerful enough to wake the next, slightly larger one and hand off the baton.

First runner: firmware and UEFI

On modern PCs, that firmware is UEFI (older machines used a simpler firmware called BIOS). When power arrives, the CPU jumps to a fixed address inside the firmware chip and starts running. Its job is to do a quick roll-call of the hardware — is there working memory? a keyboard? which disks are attached? — a self-test that catches a dead stick of RAM before anything tries to use it. Think of UEFI as the night-shift security guard who arrives before everyone else, switches on the lights, walks the building to check every door, and only then unlocks the front entrance for the day's real work.

Once the hardware checks out, UEFI must find a program to launch. Older BIOS firmware simply read the very first sector of the disk — the boot block — and ran whatever code sat there, a brutally simple convention. UEFI is more civilised: it understands a small file system and looks for boot programs as ordinary files in a known directory, which is far easier to manage. Either way, the firmware's last act is to load the next runner and jump into it.

Second runner: the bootloader and loading the kernel

The program the firmware launches is the bootloader — on Linux this is most often GRUB. Why a separate stage at all? Because the firmware is deliberately ignorant of operating systems; the bootloader is the specialist that actually knows where the kernel lives, how to read it off the disk, and how to start it correctly. It is the airport ground crew between the runway (firmware) and the aircraft (kernel): it presents the boot menu you sometimes see, picks which kernel to start, finds that kernel as a file, and copies it into memory.

Loading the kernel is more than a copy. The kernel image on disk is compressed to save space, so the bootloader (or a small stub at the front of the kernel) decompresses it into memory in the right layout. The bootloader also hands the kernel a parcel of information it cannot easily discover for itself — how much memory exists, where the firmware found the devices, and a line of boot parameters telling the kernel things like which disk holds the root file system. Then comes the moment of handover: the bootloader jumps to the kernel's entry point. From this single instruction onward, the kernel is in charge, running in full kernel mode, and the firmware and bootloader have finished their leg of the race for good.

Third runner: the kernel wakes, then mounts the root

Now the kernel runs for the first time, and it has a delicate startup of its own. It sets up the structures every later guide in this rung depends on: it builds its memory map so it can allocate memory safely, installs the table that lets the CPU find a handler for every interrupt and exception, and detects and initialises devices. Only after this groundwork is the machine a place where ordinary processes can safely live.

Here a familiar chicken-and-egg returns. The kernel needs to mount the root file system — make the disk's directory tree appear at "/", the top of the file hierarchy — so it can read the real programs. But to read a particular disk it may need a driver that itself lives on that disk. The escape hatch is the initramfs: a tiny, complete file system that the bootloader loaded into memory alongside the kernel. The kernel mounts this in-memory file system first, runs the few drivers it contains to reach the real disk, mounts the actual root on top, and then steps off the temporary one. It is the rope ladder you throw down to climb up to the real staircase.

The baton lands: the first process

With the real root mounted, the kernel performs its final act of the boot, and it is a beautiful one. It starts the very first user-mode program — the init process, traditionally given process id 1. This is the moment the machine stops being only a kernel and becomes a running system you can use. Every other process you will ever run — your shell, your browser, every background service — is a descendant of this one, created by it or by its children through the fork-and-exec pattern you met earlier. The init process is the root of the entire process tree, the single ancestor of all the rest.

On most Linux systems, the program playing the role of init is systemd. Its job is to bring the rest of the system to life: it reads its configuration and starts the services that make the machine actually useful — the network, the logging system, the login screen — and, cleverly, it can start independent services in parallel rather than one slow line, which is part of why modern machines boot quickly. Here is the whole relay, end to end.

  1. Power on. The CPU begins executing firmware (UEFI or BIOS) straight from a chip on the motherboard, with RAM still empty.
  2. The firmware self-tests the hardware, then finds and loads the bootloader (from a boot file or the boot block), and jumps into it.
  3. The bootloader (such as GRUB) locates the kernel on disk, decompresses it into memory along with the initramfs, hands over boot parameters, and jumps to the kernel.
  4. The kernel initialises itself — memory map, interrupt table, device drivers — then mounts the initramfs, reaches the real disk, and mounts the actual root file system on top.
  5. The kernel starts the first user process, init (pid 1, usually systemd), which launches every other service. The system is now ready for you.

Notice the recurring shape of the whole sequence: tiny-and-trusted starts big-and-flexible, fixed firmware reaches for a swappable kernel, and each runner hands off cleanly to the next. The same kernel that now sits at the center will, in the rest of this rung, reveal how it answers a system call, fields an interrupt, hands out memory, and protects shared data — but it all begins here, with the one program that needed no other program to start it. The boot sequence is the answer to bootstrapping, written in machine code. There is even a satisfying choice of kernel structure hidden inside step four: a monolithic kernel does almost all of that initialisation in one big privileged program, while a microkernel would push much of it out to separate user-mode services — a trade-off the final guide in this rung explores in full.