When a computer is turned on, BIOS finds the configured primary bootable device (usually the computer's hard disk) and loads and executes the initial bootstrap program from the master boot record (MBR). The MBR is the first sector of the hard disk, with zero as its offset (sectors counting starts at zero). For a long time, the size of a sector has been 512 bytes, but since 2009 there are hard disks available with a sector size of 4096 bytes, called Advanced Format disks. As of October 2013[update], such hard disks are still accessed in 512-byte sectors, by utilizing the 512e emulation.[6]

The legacy MBR partition table supports a maximum of four partitions and occupies 64 bytes. Together with the optional disk signature (four bytes) and disk timestamp (six bytes), this leaves between 434 and 446 bytes available for the machine code of a boot loader. Although such a small space can be sufficient for very simple boot loaders,[7] it is not big enough to contain a boot loader supporting complex and multiple file systems, menu-driven selection of boot choices, etc. Boot loaders with bigger footprints are thus split into pieces, where the smallest piece fits into and resides within the MBR, while larger piece(s) are stored in other locations (for example, into empty sectors between the MBR and the first partition) and invoked by the boot loader's MBR code.

Operating system kernel images are in most cases files residing on appropriate file systems, but the concept of a file system is unknown to the BIOS. Thus, in BIOS-based systems, the duty of a boot loader is to access the content of those files, so it can be loaded into the RAM and executed.

One possible approach for boot loaders to load kernel images is by directly accessing hard disk sectors without understanding the underlying file system. Usually, additional level of indirection is required, in form of maps or map files – auxiliary files that contain a list of physical sectors occupied by kernel images. Such maps need to be updated each time a kernel image changes its physical location on disk, due to installing new kernel images, file system defragmentation etc. Also, in case of the maps changing their physical location, their locations need to be updated within the boot loader's MBR code, so the sectors indirection mechanism continues to work. This is not only cumbersome, but it also leaves the system in need of manual repairs in case something goes wrong during system updates.[8]

Another approach is to make a boot loader aware of the underlying file systems, so kernel images are configured and accessed using their actual file paths. That requires a boot loader to contain a driver for each of the supported file systems, so they can be understood and accessed by the boot loader itself. This approach eliminates the need for hardcoded locations of hard disk sectors and existence of map files, and does not require MBR updates after the kernel images are added or moved around. Configuration of a boot loader is stored in a regular file, which is also accessed in a file system-aware way to obtain boot configurations before the actual booting of any kernel images. As a result, the possibility for things to go wrong during various system updates is significantly reduced. As a downside, such boot loaders have increased internal complexity and even bigger footprints.[8]

GNU GRUB uses the second approach, by understanding the underlying file systems. The boot loader itself is split into multiple stages, allowing for itself to fit within the MBR boot scheme.

Two major versions of GRUB are in common use: GRUB version 1, called GRUB legacy, is only prevalent in older releases of Linux distributions, some of which are still in use and supported, for example CentOS 5. GRUB 2 was written from scratch and intended to replace its predecessor, and is now used by a majority of Linux distributions.

The master boot record (MBR) usually contains GRUB stage 1, but can contain another bootloader which can chain boot GRUB stage 1 from another boot sector such as a partition's volume boot record. Given the small size of a boot sector (512 Bytes), stage 1 can do little more than load the next stage of GRUB by loading a few disk sectors from a fixed location near the start of the disk (within its first 1024 cylinders).

Stage 1 can load stage 2 directly, but it is normally set up to load the stage 1.5., located in the first 30 KiB of hard disk immediately following the MBR and before the first partition. In case this space is not available (unusual partition table, special disk drivers, GPT or LVM disk) the install of stage 1.5 will fail. The stage 1.5 image contains file system drivers, enable it to directly load stage 2 from any known location in the filesystem, for example from /boot/grub. Stage 2 will then load the default configuration file and any other modules needed.

boot.img has the exact size of 446 bytes and is written to the MBR (sector 0). core.img is written to the empty sectors between the MBR and the first partition, if available (for legacy reasons the first partition starts at sector 63 instead of sector 1, but this is not mandatory). The /boot/grub directory can be located on an distinct partition, or on the root partition.

Stage 1: boot.img is stored in the master boot record (MBR) or optionally in any of the volume boot records (VBRs), and addresses the next stage by an LBA48 address (thus, the 1024-cylinder limitation of GRUB legacy is avoided); at installation time it is configured to load the first sector of core.img.

Stage 1.5: core.img is by default written to the sectors between the MBR and the first partition, when these sectors are free and available. For legacy reasons, the first partition of a hard drive does not begin at sector 1 (counting begins with 0) but at sector 63, leaving 62 sectors of empty space not part of any partition or file system, and therefore not prone to any problems related with it. Once executed, core.img will load its configuration file and any other modules needed, particularly file system drivers; at installation time, it is generated from diskboot.img and configured to load the stage 2 by its file path.

Stage 2: files belonging to the stage 2 are all being held in the /boot/grub, which is a subdirectory of the /boot directory specified by the Filesystem Hierarchy Standard (FHS).

Once GRUB stage 2 has loaded, it presents a TUI-based operating system selection (kernel selection) menu, where the user can select which operating system to boot. GRUB can be configured to automatically load a specified kernel after a user-defined timeout; if the timeout is set to zero seconds, pressing and holding ⇧ Shift while the computer is booting makes it possible to access the boot menu.[9]

If files or the partition become unavailable, or if the user wishes to take direct control, stage 2 will drop the user to the GRUB command prompt, where the user can then manually specify the boot parameters.

In the operating system selection menu GRUB accepts a couple of commands:

By pressing e, it is possible to edit parameters for the selected operating system before the operating system is started. Typically, this is used to change kernel parameters for a Linux system. The reason for doing this in GRUB (i.e. not editing the parameters in an already booted system) can be an emergency case: the system has failed to boot. Using the kernel parameters line it is possible, among other things, to specify a module to be disabled (blacklisted) for the kernel. This could be required if the specific kernel module is broken and thus prevents boot-up. For example, to blacklist the kernel module nvidia-current, append modprobe.blacklist=nvidia-current at the end of the kernel parameters.[citation needed]

By pressing c, the user enters the GRUB command line. The GRUB command line is not a regular Linux shell, like e.g. bash, and accepts only certain GRUB-specific commands, documented by various Linux distributions.[10]

Once boot options have been selected, GRUB loads the selected kernel into memory and passes control to the kernel. Alternatively, GRUB can pass control of the boot process to another boot loader, using chain loading. This is the method used to load operating systems such as Microsoft Windows, that do not support the Multiboot Specification or are not supported directly by GRUB.

GRUB version 1 (also known as "GRUB Legacy") is no longer under development and is being phased out.[13] The GNU GRUB developers have switched their focus to GRUB 2,[14] a complete rewrite with goals including making GNU GRUB cleaner, more robust, more portable and more powerful. GRUB 2 started under the name PUPA. PUPA was supported by the Information-technology Promotion Agency (IPA) in Japan. PUPA was integrated into GRUB 2 development around 2002, when GRUB version 0.9x was renamed GRUB Legacy.

Three of the most widely used Linux distributions use GRUB 2 as their mainstream boot loader.[17][18][19]Ubuntu adopted it as the default boot loader in its 9.10 version of October 2009.[20]Fedora followed suit with Fedora 16 released in November 2011.[21]openSUSE adopted GRUB 2 as the default boot loader with its 12.2 release of September 2012.[22]Solaris also adopted GRUB 2 on the x86 platform in the Solaris 11.1 release.[23]

In late 2015 the exploit of pressing backspace 28 times to bypass the login password was found and quickly fixed.[24][25]

TrustedGRUB extends GRUB by implementing verification of the system integrity and boot process security, using the Trusted Platform Module (TPM).[30]

The Intel BIOS Implementation Test Suite (BITS) provides a GRUB environment for testing BIOSes and in particular their initialization of Intel processors, hardware, and technologies. BITS supports scripting via Python, and includes Python APIs to access various low-level functionality of the hardware platform, including ACPI, CPU and chipset registers, PCI, and PCI Express.[31]

The setup tools in use by various distributions often include modules to set up GRUB. For example, YaST2 on SUSE and openSUSE distributions and Anaconda on Fedora/RHEL distributions. StartUp-Manager and GRUB Customizer are graphical configuration editors for Debian-based distributions.