a bootloader

There is a gap in the boot story: the firmware knows how to start something small, but it does not know where your kernel is, what file system it lives on, or how to set up the handoff. A bootloader is the small program that fills that gap — its one job is to find the operating system kernel, load it into memory, and start it. Think of it as a stagehand between two scenes: the firmware lowers the curtain on its part, the bootloader quietly moves the right props into place, and then it raises the curtain on the kernel.

Concretely, a bootloader runs in a few stages because it starts in a very limited environment. A first tiny stage (small enough to fit in a boot sector or be loaded by UEFI) does little more than locate and load a larger second stage. The second stage (in GRUB, the part that draws the menu) understands real file systems, so it can read the kernel image and an initramfs from an ordinary disk path, present a menu of installed operating systems, apply any boot options you set, load the kernel into memory, decompress it if it is compressed, place the initramfs alongside it, and finally jump to the kernel's entry point — passing along information such as where the initramfs sits and what the command line says. After the jump, the bootloader's work is over; it never runs again until the next boot.

It matters because the bootloader is what makes choice and configuration possible at boot: dual-booting Windows and Linux, picking an older kernel when a new one fails, or booting into recovery mode all happen here, before any OS controls the machine. A common misconception is that the bootloader is part of the operating system; it is a separate program with its own code, which is why a broken bootloader can leave a perfectly good OS unbootable, and why repairing GRUB is a distinct task from reinstalling the OS.