How does Linux boot process works?

Ever wondered what actually happens behind the scenes when you press the “power” button on your computer? We are so used to this process that we never give it a second thought. However, in this post, I’ll try to explain how something that looks so simple on the outside is actually so complex and beautiful when you dig a little deeper.

In this post

The process begins

The Linux boot process is a sequence of steps that takes our system from power-on to a fully usable operating system. When we press the power button, the Power Supply Unit (PSU) initializes and stabilizes its output voltages, while the CPU is kept in a reset state. In this state, the CPU’s internal state is initialized to a known condition, ensuring it can safely execute instructions when correct voltages become available. Once the voltages are within specification, the PSU sends the Power-Good signal, indicating that the system power is stable. At this point, the CPU is released from reset and begins execution from a fixed reset vector, which maps to the firmware code.

Executing the firmware and Power-On Self Test

Firmware is a small piece of software that is stored on the motherboard’s non-volatile storage (ROM/Flash) and can be either BIOS (legacy) or UEFI (modern). These are the instructions that initialize and verify the availability of critical hardware components required to continue the boot process. It initializes the RAM, GPU, I/O, chipset, performs a basic device discovery, and sets up a minimal execution environment. The firmware’s next responsibility is to locate something that can continue the boot process – this “something” is the bootloader.

Loading the bootloader

As mentioned already, the firmware can be either a BIOS or UEFI, and based on that, the process of locating the bootloader can differ. I won’t go into the details explaining how these two firmwares actually find the bootloader, but it would be worth mentioning that if it’s BIOS then it will look for a disk, reads the first 512 bytes (the MBR) off of it, checks for a valid boot signature and assumes the code found there knows how to continue the rest of the booting process. However, UEFI is a little different; it doesn’t read the MBR, instead, it requires a separate FAT partition of its own residing on the disk and looks for an EFI executable. In both cases, the firmware is effectively asking: “Which program should I run next to load an operating system?”

Once a suitable bootloader is identified – either via code in the MBR or an EFI executable- the firmware reads the bootloader, loads it into the RAM, and prepares the CPU state according to the firmware rules. This is a hard boundary in the boot process where the firmware hands over control to the bootloader to take up the remaining responsibility to load the kernel/OS, from this point onward, the bootloader takes control of the system, although on UEFI systems, certain firmware services may remain available temporarily.