GRUB, the GRand Unified Bootloader, is the bootloader that loads the Linux kernel and initial RAM disk from disk into memory, passes the kernel command line and hands control to the operating system. In system initialization, GRUB is the stage between the firmware and the kernel, followed by the init system, which on most distributions is systemd.
The version in use today is GRUB 2, a complete rewrite of the original GRUB Legacy. It reads common filesystems directly, offers a boot menu and a command shell, supports both BIOS and UEFI firmware and can boot several operating systems from one disk.
Where GRUB fits in the boot sequence
The firmware starts first and locates a bootloader; GRUB then loads its modules and configuration, shows the menu and loads the selected kernel and initramfs. The kernel unpacks the initramfs, which mounts the real root filesystem, and finally starts the init process. A failure at each stage produces different symptoms, which makes knowing the order essential for troubleshooting.
| Stage | Component | Main task |
|---|---|---|
| Firmware | BIOS or UEFI | Hardware initialization, locating the bootloader |
| Bootloader | GRUB | Menu, loading kernel and initramfs, command line |
| Kernel | Linux kernel | Driver setup, unpacking the initramfs |
| Early user space | initramfs | Finding and mounting the root filesystem |
| Init system | systemd | Starting services and targets |
How GRUB boots on BIOS and UEFI systems
On legacy BIOS systems, GRUB is split into stages. A tiny boot.img fits into the 446-byte code area of the master boot record and loads the larger core.img, which is stored in the gap after the MBR or, on GPT disks, in a small BIOS boot partition of about 1 MiB. core.img contains the drivers needed to read /boot/grub and load further modules.
On UEFI systems, GRUB is an EFI application, typically grubx64.efi, stored on the EFI system partition and registered in the firmware’s boot entries. With Secure Boot, the firmware first starts a signed shim, which verifies a signed GRUB, which in turn verifies the signed kernel, forming a chain of trust.
| Aspect | BIOS boot | UEFI boot |
|---|---|---|
| First code location | Master boot record | EFI system partition |
| GRUB image | boot.img plus core.img | grubx64.efi, often behind shim |
| Partition table | MBR or GPT with BIOS boot partition | GPT, MBR also possible |
| Secure Boot | Not available | Supported with signed components |
| Install command target | The disk, such as /dev/sda | The EFI directory and NVRAM entry |
GRUB loads functionality as modules, such as filesystem drivers, partition table readers and the LUKS decryption module. Modules needed before /boot can be read must be embedded in core.img or the EFI image at installation time, which is why grub-install must be rerun after major changes to the disk layout.
Configuring GRUB
GRUB reads a generated file, grub.cfg, which administrators should not edit by hand. Instead, settings go into /etc/default/grub and scripts in /etc/grub.d, and the file is regenerated with grub-mkconfig -o /boot/grub/grub.cfg, wrapped as update-grub on Debian and Ubuntu and named grub2-mkconfig on Fedora and related systems.
| Setting | Example value | Effect |
|---|---|---|
| GRUB_TIMEOUT | 5 | Seconds the menu waits before the default entry |
| GRUB_DEFAULT | 0 or saved | Which entry boots by default |
| GRUB_CMDLINE_LINUX | Kernel parameters | Options passed to every kernel |
| GRUB_CMDLINE_LINUX_DEFAULT | quiet splash | Options for normal, non-recovery entries |
| GRUB_DISABLE_OS_PROBER | true or false | Whether other operating systems are detected |
Kernel parameters are the most common reason to touch GRUB. They control console output, root device selection, security modules and the systemd target, for example systemd.unit=rescue.target to boot into a minimal maintenance mode. Fedora and related distributions add Boot Loader Specification entries, one small file per kernel, which grubby manages without regenerating the whole configuration.
Changes in /etc/default/grub take effect only after the configuration is regenerated. Forgetting this step is a frequent reason why a new kernel parameter seems to be ignored. On UEFI systems, the grub.cfg on the EFI system partition is often a short stub that loads the real configuration from /boot, so the file to regenerate depends on the distribution.
GRUB compared with other bootloaders
GRUB is the most feature-rich and portable option, but simpler alternatives exist, especially on UEFI systems where the firmware can already read FAT filesystems and load EFI applications.
| Bootloader | Firmware support | Strengths | Trade-offs |
|---|---|---|---|
| GRUB | BIOS and UEFI, several CPU architectures | Many filesystems, encryption, scripting, multiboot | Complex configuration and larger attack surface |
| systemd-boot | UEFI only | Simple, uses Boot Loader Specification entries | Kernels must sit on the ESP or an extended boot partition |
| EFI stub | UEFI only | Firmware loads the kernel directly | No menu, limited flexibility |
| rEFInd | UEFI only | Graphical menu, automatic detection | Less common on servers |
Common GRUB problems and recovery
Most GRUB failures follow disk changes, firmware updates or another operating system overwriting the boot entry. The prompt that appears indicates how far GRUB got: a normal grub prompt means modules loaded but the configuration did not, while grub rescue means GRUB could not even find its own files.
- Edit the entry at boot by pressing e in the menu to change kernel parameters for one boot only.
- Reinstall from a live system by mounting the root filesystem, entering it with chroot and running grub-install and grub-mkconfig.
- Restore the UEFI entry with efibootmgr when firmware updates remove it.
- Protect the menu with a password so physical users cannot add parameters that bypass authentication.
- Keep an older kernel entry so a faulty kernel update does not leave the system unbootable.
Encrypted systems add complexity. GRUB can unlock LUKS-encrypted /boot partitions, but support for newer LUKS2 key derivation functions arrived later than in the kernel, so many distributions keep /boot unencrypted and let the initramfs decrypt the root filesystem instead.
In everyday language
When a computer is switched on, the hardware knows how to start but not which operating system to load. It needs a short guide that finds the system on the disk and starts it.
GRUB is that guide for most Linux computers. It shows a small menu, lets you choose what to start, and then hands the computer over to Linux. If something breaks, GRUB also offers ways to start the system in a repair mode.
Seen in the real world
After a kernel update, a company file server stops at boot with a blank screen. The administrator connects to the remote console, interrupts the GRUB menu and selects the previous kernel from the advanced options, which boots normally. The new kernel is missing a storage driver in its initramfs.
To investigate safely, the administrator boots the new kernel once more after pressing e and adding systemd.unit=rescue.target to the kernel line. The fix is to regenerate the initramfs with the missing module and rerun update-grub. The administrator also sets GRUB_DEFAULT=saved together with GRUB_SAVEDEFAULT=true so the last working entry is remembered, and the server is back in service within an hour without reinstalling anything.