| GNU GRUB | |
|---|---|
 | |
 GRUB v2.12 running in text mode | |
| Original author | Erich Boleyn |
| Developer | GNU Project |
| Initial release | 1995; 31 years ago (1995) |
| Stable release | 2.14[1]  / 14 January 2026 |
| Written in | Assembly,C[2] |
| Operating system | Linux,GNU/Hurd,macOS,BSD, (Solaris/illumos (x86 port)), andWindows (through chainloading) |
| Platform | IA-32,x86-64,IA-64,ARM,PowerPC,Power ISA,s390x,MIPS,RISC-V,LoongArch andSPARC |
| Available in | English and others |
| Type | Bootloader |
| License | 2007:GPL-3.0-or-later[a][4] 1999:GPL-2.0-or-later[b] |
| Website | www |
| Repository | |
GNU GRUB (short forGNU GRand Unified Bootloader, commonly referred to asGRUB) is aboot loader package from theGNU Project. GRUB is thereference implementation of theFree Software Foundation'sMultiboot Specification, which provides a user the choice to boot one of multipleoperating systems installed on a computer set up formulti-booting or select a specifickernel configuration available on a particular operating system's partitions.
GNU GRUB was developed from a package called theGrand Unified Bootloader (a play onGrand Unified Theory[5]). It is predominantly used forUnix-like systems.
 | This sectionmay be too technical for most readers to understand. Pleasehelp improve it tomake it understandable to non-experts, without removing the technical details.(August 2021) (Learn how and when to remove this message) |
boot.img) can alternatively be written into one of thepartition boot sectors.
When anIBM PC compatible computer with aBIOS is turned on, the BIOS finds the primary bootable device (usually the computer's hard disk) and runs the initialbootstrap program from themaster boot record (MBR). The MBR is the firstsector of the hard disk. This bootstrap program must be small because it has to fit in a single sector. For a long time, the size of a sector has been 512 bytes. Since 2009 there are hard disks available with a sector size of 4096 bytes, calledAdvanced Format disks, but as of October 2013,[update] such hard disks are still accessed in 512-byte sectors, using the512e emulation.[6]The legacyMBR partition table supports a maximum of four partitions and occupies 64 bytes, combined. Together with the optionaldisk signature (four bytes) anddisk timestamp (six bytes), this leaves between 434 and 446 bytes available for themachine 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 multiplefile systems, menu-driven selection of boot choices, etc. Boot loaders with bigger footprints are therefore split into pieces, where the smallest piece fits in the MBR, while one or more larger pieces are stored in other locations such as empty sectors between the MBR and the first partition. The code in the MBR then does little more than starting the second part.
The purpose of the remaining part(s) of the boot loader is to actually boot an operating system by configuring it and starting thekernel. Kernels are in most cases stored as 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 theRAM and executed.
One possible approach for boot loaders is to load kernel images by directly accessing hard disk sectors without understanding the underlying file system. Usually, an additional level ofindirection is required, in form ofmaps ormap 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 actualfile 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 kernel images are added or moved around. The 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. Thus, fewer things can go wrong during system updates. As a downside, such boot loaders are larger and more complex.[8]
GNU GRUB uses the second approach, by understanding the underlying file systems. The boot loader itself is split into multiplestages so that it fits in the MBR boot scheme.
Two major versions of GRUB are in common use: GRUB version 0, calledGRUB legacy, is only prevalent in older releases of Linux distributions.GRUB 2 was written from scratch and intended to replace its predecessor, and is now used by a majority of Linux distributions.
GRUB 0.x follows a two-stage approach. The master boot record (MBR) usually contains GRUBstage 1, or can contain a standard MBR implementation whichchainloads GRUBstage 1 from the activepartition's boot sector. 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 loadstage 2 directly, but it is normally set up to load thestage 1.5., located in the first 30KiB 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 orLVM disk) the install ofstage 1.5 will fail. Thestage 1.5 image contains file system drivers, enabling it to directly loadstage 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 (stage 1) is written to the first 440 bytes of theMaster Boot Record (MBR boot code in sector 0), or optionally in apartition boot sector (PBR). It addressesdiskboot.img by a 64-bit LBA address. The actual sector number is written bygrub-install.diskboot.img is the first sector ofcore.img with the sole purpose to load the rest ofcore.img identified by LBA sector numbers also written bygrub-install.core.img (stage 1.5) is stored in the empty sectors (if available) between the MBR and the first partition. Recent operating systems suggest a 1 MiB gap here for alignment (2047 512-byte, or 255 4KiB, sectors). This gap used to be 62 sectors (31 KiB) as a reminder of the sector number limit ofCylinder-Head-Sector (C/H/S) addressing used byBIOS before 1996, thereforecore.img is designed to be smaller than 32 KiB.core.img is written to its own partition which must be flagged "BIOS_grub", must not beformatted and can be as tiny as 1 MiB.core.img loads/boot/grub/i386-pc/normal.mod from the partition configured bygrub-install. If the partition index has changed, GRUB will be unable to find thenormal.mod, and presents the user with the GRUB Rescue prompt./boot/grub/ is either in theroot partition of the Linux distribution, or in the separate/boot partition.normal.mod parses/boot/grub/grub.cfg, optionally loads modules (eg. for graphical UI and file system support) and shows the menu./efi/<distro>/grubx64.efi (forx64 UEFI systems) is installed as a file in theEFI System Partition, and booted by the firmware directly, without aboot.img in MBR sector 0. This file is like stage1 and stage1.5./boot/grub/ can be installed on the EFI System Partition or the separate/boot partition, among others./boot/grub/x86_64-efi/normal.mod file and other/boot/grub/ files.GRUB presents a menu where the user can choose from operating systems (OS) found by grub-install. GRUB can be configured to automatically load a specified OS after a user-defined timeout. If the timeout is set to zero seconds, pressing and holding⇧ Shift, or in some modern GRUB versions loaded using UEFI, pressingEsc rapidly while the computer is booting makes it possible to access the boot menu.[10]
In the operating system selection menu GRUB accepts a couple of commands:
nvidia-current, one could appendmodprobe.blacklist=nvidia-current at the end of the kernel parameters.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, usingchain loading. This is the method used to load operating systems that do not support theMultiboot Specification or are not supported directly by GRUB.
A computer can have multiple hard disks connected to it. These could be identified via their SATA port. Each time the computerPOSTs, the hard disk connected to a specific motherboard portcould be assigned the same identifier, for examplehd0, hd1, …. But what if such consistency cannot be guaranteed? What if the constellation of connected hard disks changed from one start up to another? What if a hard disk will be connected to another computer?
By enteringls into either theGRUB rescue console (available after loadingcore.img ) or theGRUB console (available after loadingnormal.mod) a list of all available hard disks and partitions can be obtained. For example,ls (hd0,5)/) will show numbers that can be assigned to actual hard disks and partitions.
As it cannot be guaranteed that the "hd0"style numbering of hard disks via device numbers is consistent, GNU GRUB can use aUniversally Unique Identifier (UUID) to identify partitions (actually file system instances).
The file systems ext2, ext3, ext4 and xfs use a UUID to uniquely identify an instance. The UUID is created when a partition is formatted. The UUID is part of the file system and written to thesuperblock. All operations other than formatting should leave the UUID unaltered. It is possible to change the UUID or duplicate it by usingdd to clone an entire partition.
The filegrub.cfg is used to configure GRUB. It contains commands to be executed during each start-up. Without an existing and validgrub.cfg, GRUB will present a prompt.
An absolute minimalgrub.cfg might contain only the following two commands (cf.initial ramdisk):
linux (hd0,1)/kernel/vmlinuz-3.20.1-4 ro # use the file named "vmlinuz-…" located in the directory /kernel on the first partition of the first hard disk as linux kernel imageinitrd (hd0,1)/boot/initrd.img-3.20.1-4 # use the file named "initrd.img–…" located in the directory /boot on the first partition of the first hard disk as initial ramdisk
A fanciergrub.cfg will describe a menu to be presented, use multiple colors, and may specify a background picture.
GRUB was initially developed by Erich Boleyn as part of work on booting theoperating systemGNU/Hurd, developed by theFree Software Foundation.[12] In 1999, Gordon Matzigkeit and Yoshinori K. Okuji made GRUB an official software package of theGNU Project and opened thedevelopment process to the public.[12] By 2014, the majority of Linux distributions have adopted GNU GRUB 2.[citation needed]
GRUB version 0 (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] acomplete rewrite with goals including making GNU GRUB cleaner, more robust, more portable and more powerful. GRUB 2 started under the namePUPA. 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.
Some of the goals of the GRUB 2 project include support for non-x86platforms,internationalization and localization, non-ASCII characters, dynamic modules,memory management, a scriptingmini-language, migrating platform specific (x86) code to platform specific modules, and an object-oriented framework. GNU GRUB version 2.00 was officially released on June 26, 2012.[15][16]
Three of the most widely usedLinux 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]Buildroot also uses GNU GRUB forx86 andx86_64 targets.
In late 2015, the exploit of pressing backspace 28 times to bypass the login password was found and quickly fixed.[24][25]
GNU GRUB isfree software, so several variants have been created. Some notable ones, which have not been merged into GRUB mainline:
The setup tools in use by various distributions often include modules to set up GRUB. For example,YaST2 onSUSE Linux andopenSUSE distributions andAnaconda onFedora/RHEL distributions. StartUp-Manager and GRUB Customizer are graphical configuration editors for Debian-based distributions. The development of StartUp-Manager stopped on May 6, 2011, after the lead developer cited personal reasons for not actively developing the program.[35] GRUB Customizer is also available for Arch-based distributions.
For GRUB 2 there are KDE Control Modules.[36][37]
GRLDR ICE is a tiny tool for modifying the default configuration of grldr file for GRUB4DOS.[38]
Boot-Repair is a simple graphical tool for recovering from frequent boot-related problems with GRUB andMicrosoft Windows bootloader. This application is available underGNU GPL license. Boot-Repair can repair GRUB on multiple Linux distributions including, but not limited to, Debian, Ubuntu,Mint, Fedora, openSUSE, andArch Linux.
Grub2Win is a Windows open-source software package. It allows GNU GRUB to boot from a Windows directory. The setup program installs GNU GRUB version 2.12 to an NTFS partition. A Windows GUI application is then used to customize the GRUB boot menu, themes, UEFI boot order, scripts etc. All GNU GRUB scripts and commands are supported for both UEFI and legacy systems. Grub2Win can configure GRUB for multiboot of Windows, Ubuntu, openSUSE, Fedora and many other Linux distributions. It is freely available underGNU GPL License atSourceForge.
The strength of GRUB is the wide range of supported platforms, file systems, and operating systems, making it the default choice for distributions and embedded systems.
However, there are boot managers targeted at the end user that give more friendly user experience, graphical OS selector and simpler configuration:
Non-graphical alternatives:
Distribution wikis have many solutions for common issues and custom setups that might help you:
| Processes |  | ||||||
|---|---|---|---|---|---|---|---|
| Bootingfirmware |
| ||||||
| Hybrid firmware bootloader | |||||||
| Bootloaders |
| ||||||
| Partition layouts | |||||||
| Partitions | |||||||
| Utilities |
| ||||||
| Network boot | |||||||
| ROM variants | |||||||
| Related | |||||||
