What happens when a server boots: BIOS/UEFI, POST and the handoff to your OS
Quick answer
Powering on a server sets off a fixed sequence: firmware runs a Power-On Self-Test (POST) to check the core hardware, BIOS or UEFI firmware initialises that hardware and hands control to a bootloader, the bootloader loads the operating system's kernel, and the kernel takes it from there, starting drivers and the services that make the OS usable. Each stage hands off to the next only once it succeeds, which is why a boot failure often points straight at the stage where it stalled.
Step 1: POST, the hardware's own health check
The moment a server is powered on, before any operating system is involved, the firmware runs the Power-On Self-Test. POST checks that the hardware a system depends on to boot at all is actually present and functioning: the CPU, memory, and enough of the storage and peripheral bus to continue. If POST finds something seriously wrong, a missing memory module, an unresponsive CPU, it typically halts right there, often signalled with a beep code or a POST error code on a diagnostic display, because there's no safe way to proceed further without that hardware.
Step 2: firmware initialises the platform (BIOS or UEFI)
Assuming POST passes, the system firmware, either legacy BIOS or its modern successor UEFI, takes over initialising the rest of the platform: configuring the chipset, enumerating storage and network controllers, and working out what's connected before anything resembling an operating system is involved. Once that's done, firmware's job is to find a valid boot target and hand control to it.
UEFI vs. legacy BIOS, briefly
UEFI is the modern standard and has effectively replaced legacy BIOS on current server and desktop hardware. A few practical differences explain why:
- Boot speed. UEFI generally initialises hardware and hands off to the OS faster than legacy BIOS's more sequential, 16-bit-era boot process.
- Drive size. Legacy BIOS boots from disks partitioned with the older MBR scheme, which caps a boot drive at 2TB. UEFI works with GPT partitioning, which removes that ceiling, relevant on any server with large boot volumes.
- Secure Boot. UEFI supports Secure Boot, which checks that the bootloader and kernel being loaded are cryptographically signed by a trusted authority before letting them run, a protection legacy BIOS has no equivalent for.
Step 3: the bootloader loads the kernel
Firmware doesn't load an operating system directly. It locates a small program, the bootloader, stored in a known location on the boot drive, and hands control to it. On Linux systems that's typically GRUB; on Windows it's the Windows Boot Manager. The bootloader's job is narrow but essential: find the operating system kernel, load it into memory, pass it any boot parameters it needs, and jump to it. On a system with more than one installed OS or kernel version, this is also the stage where a boot menu lets you choose between them.
Step 4: the kernel takes over
Once the kernel is running, firmware and bootloader step out of the picture. The kernel initialises the drivers for the hardware it now has direct control over, mounts the root filesystem, and starts the initial system process, which in turn brings up the services, networking, and everything else that makes the OS actually usable. From the moment that first userspace process starts, the machine is running the operating system you installed rather than executing firmware.