Permission is granted to copy, distribute and/or modify this documentunder the terms of the GNU Free Documentation License, Version 1.2 orany later version published by the Free Software Foundation; with noInvariant Sections.
Briefly, a boot loader is the first software program that runs whena computer starts. It is responsible for loading and transferringcontrol to an operating system kernel software (such as Linux orGNU Mach). The kernel, in turn, initializes the rest of the operatingsystem (e.g. a GNU system).
GNU GRUB is a very powerful boot loader, which can load a wide varietyof free operating systems, as well as proprietary operating systems withchain-loading1. GRUB is designed toaddress the complexity of booting a personal computer; both theprogram and this manual are tightly bound to that computer platform,although porting to other platforms may be addressed in the future.
One of the important features in GRUB is flexibility; GRUB understandsfilesystems and kernel executable formats, so you can load an arbitraryoperating system the way you like, without recording the physicalposition of your kernel on the disk. Thus you can load the kerneljust by specifying its file name and the drive and partition where thekernel resides.
When booting with GRUB, you can use either a command-line interface(see Command-line interface), or a menu interface (see Menu interface). Using the command-line interface, you type the drivespecification and file name of the kernel manually. In the menuinterface, you just select an OS using the arrow keys. The menu isbased on a configuration file which you prepare beforehand(see Configuration). While in the menu, you can switch to thecommand-line mode, and vice-versa. You can even edit menu entriesbefore using them.
In the following chapters, you will learn how to specify a drive, apartition, and a file name (see Naming convention) to GRUB, how toinstall GRUB on your drive (see Installation), and how to boot yourOSes (see Booting), step by step.
Erich then began modifying the FreeBSD boot loader so that it wouldunderstand Multiboot. He soon realized that it would be a lot easierto write his own boot loader from scratch than to keep working on theFreeBSD boot loader, and so GRUB was born.
Erich added many features to GRUB, but other priorities prevented himfrom keeping up with the demands of its quickly-expanding user base. In1999, Gordon Matzigkeit and Yoshinori K. Okuji adopted GRUB as anofficial GNU package, and opened its development by making the latestsources available via anonymous CVS. See Obtaining and Building GRUB, for more information.
Over the next few years, GRUB was extended to meet many needs, but itquickly became clear that its design was not keeping up with the extensionsbeing made to it, and we reached the point where it was very difficult tomake any further changes without breaking existing features. Around 2002,Yoshinori K. Okuji started work on PUPA (Preliminary Universal ProgrammingArchitecture for GNU GRUB), aiming to rewrite the core of GRUB to make itcleaner, safer, more robust, and more powerful. PUPA was eventually renamedto GRUB 2, and the original version of GRUB was renamed to GRUB Legacy.Small amounts of maintenance continued to be done on GRUB Legacy, but thelast release (0.97) was made in 2005 and at the time of writing it seemsunlikely that there will be another.
GRUB 2 is a rewrite of GRUB (see History), although it shares manycharacteristics with the previous version, now known as GRUB Legacy. Usersof GRUB Legacy may need some guidance to find their way around this newversion.
Except for specific compatibility modes (chain-loading and the Linuxpiggyback format), all kernels will be started in much the samestate as in the Multiboot Specification. Only kernels loaded at 1 megabyteor above are presently supported. Any attempt to load below thatboundary will simply result in immediate failure and an error messagereporting the problem.
Support a human-readable text configuration file with preset bootcommands. You can also load another configuration file dynamically andembed a preset configuration file in a GRUB image file. The list ofcommands (see Commands) are a superset of those supported on thecommand-line. An example configuration file is provided inConfiguration.
A menu interface listing preset boot commands, with a programmabletimeout, is available. There is no fixed limit on the number of bootentries, and the current implementation has space for several hundred.
A fairly flexible command-line interface, accessible from the menu,is available to edit any preset commands, or write a new boot commandset from scratch. If no configuration file is present, GRUB drops tothe command-line.
The list of commands (see Commands) are a subset of those supportedfor configuration files. Editing commands closely resembles the Bashcommand-line (see Command Line Editing in Bash Features), with TAB-completion of commands,devices, partitions, and files in a directory depending on context.
Can decompress files which were compressed by gzip orxz3. This function is both automatic and transparent to the user(i.e. all functions operate upon the uncompressed contents of the specifiedfiles). This greatly reduces a file size and loading time, aparticularly great benefit for floppies.4
GRUB can generally find all the installed RAM on a PC-compatiblemachine. It uses an advanced BIOS query technique for finding allmemory regions. As described on the Multiboot Specification (see Motivation in The MultibootSpecification), not all kernels make use of this information, but GRUBprovides it for those who do.
followed by a TAB, and GRUB will display the list of drives,partitions, or file names. So it should be quite easy to determine thename of your target partition, even with minimal knowledge of thesyntax.
Note that GRUB does not distinguish IDE from SCSI - it simplycounts the drive numbers from zero, regardless of their type. Normally,any IDE drive number is less than any SCSI drive number, although thatis not true if you change the boot sequence by swapping IDE and SCSIdrives in your BIOS.
In order to install GRUB as your boot loader, you need to firstinstall the GRUB system and utilities under your UNIX-like operatingsystem (see Obtaining and Building GRUB). You can do this eitherfrom the source tarball, or as a package for your OS.
But all the above examples assume that GRUB should put images underthe /boot directory. If you want GRUB to put images under a directoryother than /boot, you need to specify the option--boot-directory. The typical usage is that you create a GRUBboot floppy with a filesystem. Here is an example:
The root device will be set up appropriately on entering yourgrub.cfg configuration file, so you can refer to file names on the CDwithout needing to use an explicit device name. This makes it easier toproduce rescue images that will work on both optical drives and USB massstorage devices.
Historically, the device map file was used because GRUB device names had tobe used in the configuration file, and they were derived from BIOS drivenumbers. The map between BIOS drives and OS devices cannot always beguessed correctly: for example, GRUB will get the order wrong if youexchange the boot sequence between IDE and SCSI in your BIOS.
Unfortunately, even OS device names are not always stable. Modern versionsof the Linux kernel may probe drives in a different order from boot to boot,and the prefix (/dev/hd* versus /dev/sd*) may change dependingon the driver subsystem in use. As a result, the device map file requiredfrequent editing on some systems.
GRUB avoids this problem nowadays by using UUIDs or file system labels whengenerating grub.cfg, and we advise that you do the same for anycustom menu entries you write. If the device map file does not exist, thenthe GRUB utilities will assume a temporary device map on the fly. This isoften good enough, particularly in the common case of single-disk systems.
The partition table format traditionally used on PC BIOS platforms is calledthe Master Boot Record (MBR) format; this is the format that allows up tofour primary partitions and additional logical partitions. With thispartition table format, there are two ways to install GRUB: it can beembedded in the area between the MBR and the first partition (called byvarious names, such as the "boot track", "MBR gap", or "embedding area", andwhich is usually at least 1000 KiB), or the core image can be installed in afile system and a list of the blocks that make it up can be stored in thefirst sector of that partition.
Historically many tools left only 31 KiB of space. This is not enough toparse reliably difficult structures like Btrfs, ZFS, RAID or LVM, or touse difficult disk access methods like ahci. Hence GRUB will warn if attemptedto install into small MBR gap except in a small number of configurationsthat were grandfathered. The grandfathered config must:
MBR gap has few technical problems. There is no way to reserve space inthe embedding area with complete safety, and some proprietary software isknown to use it to make it difficult for users to work around licensingrestrictions. GRUB works around it by detecting sectors by other software andavoiding them and protecting its own sectors using Reed-Solomon encoding.
Should it not be possible, GRUB has support for a fallback solution which isheavily recommended against. Installing to a filesystem means that GRUB isvulnerable to its blocks being moved around by filesystem features such astail packing, or even by aggressive fsck implementations, so this approachis quite fragile; and this approach can only be used if the /bootfilesystem is on the same disk that the BIOS boots from, so that GRUB doesnot have to rely on guessing BIOS drive numbers.
The GRUB development team generally recommends embedding GRUB before thefirst partition, unless you have special requirements. You must ensure thatthe first partition starts at least 1000 KiB (2000 sectors) from the start ofthe disk; on modern disks, it is often a performance advantage to alignpartitions on larger boundaries anyway, so the first partition might start 1MiB from the start of the disk.
6022c96aab