A bootloader is a small program that loads the operating system into memory and hands control to it. After the computer’s firmware finishes its power-on checks, it starts the bootloader, which locates the kernel on a storage device, loads it together with any initial files it needs, passes configuration parameters and then transfers execution to the kernel.
In operating systems, and specifically in the boot and firmware stage, the bootloader is the bridge between platform firmware (UEFI or legacy BIOS) and the operating system. It is also the place where users choose between several installed systems, where recovery options are offered and where Secure Boot checks that only trusted code is started.
Where the bootloader fits in the boot sequence
Starting a computer is a chain of increasingly capable programs. Each stage is small enough to be loaded by the previous one and capable enough to load the next. The bootloader occupies the middle of this chain, as the table shows.
| Stage | Component | Main task |
|---|---|---|
| 1. Power-on | Firmware (UEFI or BIOS) | Initializes CPU, memory and chipset |
| 2. POST | Firmware | Tests hardware and detects devices |
| 3. Boot device selection | Firmware boot manager | Follows the boot order or boot menu |
| 4. Bootloader | Program on the boot disk | Loads kernel and initial files |
| 5. Kernel start | Operating system kernel | Initializes drivers and mounts storage |
| 6. User space | Init system and services | Starts login screen and desktop |
The boot order stored in firmware decides which device is tried first, and a one-time boot menu, usually opened with a key such as F12, Esc or F8 during POST, overrides it for a single start. Only after this selection does the bootloader on the chosen device run.
How a bootloader works on UEFI and BIOS systems
On legacy BIOS systems, the firmware reads the first 512-byte sector of the disk, the Master Boot Record (MBR), and executes the code found there. Because only about 446 bytes are available for code, BIOS bootloaders are split into stages: a tiny first stage in the MBR loads a larger second stage from elsewhere on the disk, which understands file systems and can load the kernel.
On UEFI systems, the firmware itself understands the FAT-based EFI System Partition (ESP) and starts bootloaders as ordinary executable files with the .efi extension. Boot entries stored in firmware NVRAM variables point to these files, which removes the cramped multi-stage design and allows larger, more capable bootloaders.
| Aspect | Legacy BIOS | UEFI |
|---|---|---|
| Where code is stored | MBR sector and hidden gaps | Files on the EFI System Partition |
| Partition table | MBR, up to 2 TiB disks | GPT, very large disks |
| Boot entries | Fixed disk order | Named entries in NVRAM |
| Code verification | None | Secure Boot signatures |
| Multi-stage design | Required | Optional |
Many UEFI computers offer a Compatibility Support Module (CSM) that emulates a BIOS for older operating systems. Enabling CSM usually disables Secure Boot, and modern platforms are steadily removing CSM support, so new installations should use UEFI mode with GPT disks.
Common bootloaders and their roles
Each operating system family ships its own bootloader, and some third-party loaders can start several systems. The table compares the most widely used ones on desktop computers.
| Bootloader | Typical platform | Notable characteristics |
|---|---|---|
| Windows Boot Manager | Windows on UEFI | Reads the BCD store, starts winload.efi |
| GRUB 2 | Most Linux distributions | Scriptable menus, many file systems |
| systemd-boot | Some Linux distributions | Simple menu, UEFI only |
| shim | Linux with Secure Boot | Signed first stage that verifies GRUB |
| iBoot | Apple silicon Macs | Verified chain from the boot ROM |
Windows stores its boot configuration in the Boot Configuration Data (BCD) store, edited with bcdedit, while GRUB uses a generated configuration file. On Apple silicon Macs, the boot chain starts in a read-only boot ROM, and macOS controls startup security through recovery mode rather than a user-editable menu.
Secure Boot and the chain of trust
Because the bootloader runs before the operating system and its security software, it is an attractive target for bootkits, malware that hides below the OS. UEFI Secure Boot counters this by letting firmware start only bootloaders signed with keys in its trusted database.
Each verified stage then checks the next one, forming a chain of trust from firmware to kernel. A TPM can additionally record measurements of each stage, which lets features such as BitLocker release encryption keys only when the boot chain is unchanged. This is why modifying boot settings can trigger a recovery key prompt.
Bootloader problems and how to fix them
Bootloader faults are among the most alarming errors because the operating system never starts. Most are repairable without reinstalling, as long as the data partitions are intact.
| Symptom | Likely cause | Usual repair |
|---|---|---|
| No bootable device found | Wrong boot order or missing ESP entry | Correct boot order or recreate the entry |
| GRUB rescue prompt | Moved or deleted partition | Reinstall GRUB from live media |
| Windows disappears after Linux install | Default entry changed | Update menu or firmware boot order |
| Secure Boot violation message | Unsigned or revoked bootloader | Update bootloader or signed shim |
| Repeated automatic repair | Damaged BCD store | Rebuild BCD from recovery environment |
- Install Windows before Linux in dual-boot setups, because Windows setup tends to replace other boot entries.
- Keep a recovery USB drive to reach repair tools when the installed bootloader is broken.
- Suspend BitLocker before changing boot settings to avoid unexpected recovery key prompts.
In everyday language
A bootloader is the starter that gets the operating system running. When you press the power button, the computer only knows a few basic tricks. It runs the bootloader, which knows where Windows, macOS or Linux is stored and how to start it.
It works like a stage manager before a show: it checks the right performer is ready, opens the curtain and then steps aside. If the bootloader is missing or damaged, the computer turns on but cannot find anything to start.
Seen in the real world
A software developer installs Linux next to Windows on a laptop with a 1 TB SSD. After installation, the computer starts straight into Linux, and the GRUB menu lists Windows as a second option. Everything works until a Windows feature update resets the firmware boot order, and the laptop starts Windows without showing the menu.
Instead of reinstalling, the developer opens the firmware settings, moves the Linux boot entry back to the top of the UEFI boot order and confirms that Secure Boot remains enabled through the signed shim loader.
The dual-boot menu returns in under five minutes. The case shows that most startup problems in multi-system setups are bootloader configuration issues, not damaged operating systems.