1 Introduction to GRUB ********************** 1.1 Overview ============ Briefly, a "boot loader" is the first software program that runs when a computer starts. It is responsible for loading and transferring control to an operating system "kernel" software (such as Linux or GNU Mach). The kernel, in turn, initializes the rest of the operating system (e.g. a GNU system). GNU GRUB is a very powerful boot loader, which can load a wide variety of free operating systems, as well as proprietary operating systems with chain-loading(1) (*note Overview-Footnote-1::). GRUB is designed to address the complexity of booting a personal computer; both the program 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 understands filesystems and kernel executable formats, so you can load an arbitrary operating system the way you like, without recording the physical position of your kernel on the disk. Thus you can load the kernel just by specifying its file name and the drive and partition where the kernel resides. When booting with GRUB, you can use either a command-line interface (*note Command-line interface::), or a menu interface (*note Menu interface::). Using the command-line interface, you type the drive specification and file name of the kernel manually. In the menu interface, you just select an OS using the arrow keys. The menu is based on a configuration file which you prepare beforehand (*note Configuration::). While in the menu, you can switch to the command-line mode, and vice-versa. You can even edit menu entries before using them. In the following chapters, you will learn how to specify a drive, a partition, and a file name (*note Naming convention::) to GRUB, how to install GRUB on your drive (*note Installation::), and how to boot your OSes (*note Booting::), step by step. (1) "chain-load" is the mechanism for loading unsupported operating systems by loading another boot loader. It is typically used for loading DOS or Windows. 1.2 History of GRUB =================== GRUB originated in 1995 when Erich Boleyn was trying to boot the GNU Hurd with the University of Utah's Mach 4 microkernel (now known as GNU Mach). Erich and Brian Ford designed the Multiboot Specification (*note Multiboot Specification: (multiboot)Top.), because they were determined not to add to the large number of mutually-incompatible PC boot methods. Erich then began modifying the FreeBSD boot loader so that it would understand Multiboot. He soon realized that it would be a lot easier to write his own boot loader from scratch than to keep working on the FreeBSD boot loader, and so GRUB was born. Erich added many features to GRUB, but other priorities prevented him from keeping up with the demands of its quickly-expanding user base. In 1999, Gordon Matzigkeit and Yoshinori K. Okuji adopted GRUB as an official GNU package, and opened its development by making the latest sources available via anonymous CVS. *Note Obtaining and Building GRUB::, for more information. Over the next few years, GRUB was extended to meet many needs, but it quickly became clear that its design was not keeping up with the extensions being made to it, and we reached the point where it was very difficult to make any further changes without breaking existing features. Around 2002, Yoshinori K. Okuji started work on PUPA (Preliminary Universal Programming Architecture for GNU GRUB), aiming to rewrite the core of GRUB to make it cleaner, safer, more robust, and more powerful. PUPA was eventually renamed to 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 the last release (0.97) was made in 2005 and at the time of writing it seems unlikely that there will be another. By around 2007, GNU/Linux distributions started to use GRUB 2 to limited extents, and by the end of 2009 multiple major distributions were installing it by default. 1.3 Differences from previous versions ====================================== GRUB 2 is a rewrite of GRUB (*note History::), although it shares many characteristics with the previous version, now known as GRUB Legacy. Users of GRUB Legacy may need some guidance to find their way around this new version. * The configuration file has a new name ('grub.cfg' rather than 'menu.lst' or 'grub.conf'), new syntax (*note Configuration::) and many new commands (*note Commands::). Configuration cannot be copied over directly, although most GRUB Legacy users should not find the syntax too surprising. * 'grub.cfg' is typically automatically generated by 'grub-mkconfig' (*note Simple configuration::). This makes it easier to handle versioned kernel upgrades. * Partition numbers in GRUB device names now start at 1, not 0 (*note Naming convention::). * The configuration file is now written in something closer to a full scripting language: variables, conditionals, and loops are available. * A small amount of persistent storage is available across reboots, using the 'save_env' and 'load_env' commands in GRUB and the 'grub-editenv' utility. This is not available in all configurations (*note Environment block::). * GRUB 2 has more reliable ways to find its own files and those of target kernels on multiple-disk systems, and has commands (*note search::) to find devices using file system labels or Universally Unique Identifiers (UUIDs). * GRUB 2 is available for several other types of system in addition to the PC BIOS systems supported by GRUB Legacy: PC EFI, PC coreboot, PowerPC, SPARC, and MIPS Lemote Yeeloong are all supported. * Many more file systems are supported, including but not limited to ext4, HFS+, and NTFS. * GRUB 2 can read files directly from LVM and RAID devices. * A graphical terminal and a graphical menu system are available. * GRUB 2's interface can be translated, including menu entry names. * The image files (*note Images::) that make up GRUB have been reorganised; Stage 1, Stage 1.5, and Stage 2 are no more. * GRUB 2 puts many facilities in dynamically loaded modules, allowing the core image to be smaller, and allowing the core image to be built in more flexible ways. 1.4 GRUB features ================= The primary requirement for GRUB is that it be compliant with the "Multiboot Specification", which is described in *note Multiboot Specification: (multiboot)Top. The other goals, listed in approximate order of importance, are: * Basic functions must be straightforward for end-users. * Rich functionality to support kernel experts and designers. * Backward compatibility for booting FreeBSD, NetBSD, OpenBSD, and Linux. Proprietary kernels (such as DOS, Windows NT, and OS/2) are supported via a chain-loading function. Except for specific compatibility modes (chain-loading and the Linux "piggyback" format), all kernels will be started in much the same state as in the Multiboot Specification. Only kernels loaded at 1 megabyte or above are presently supported. Any attempt to load below that boundary will simply result in immediate failure and an error message reporting the problem. In addition to the requirements above, GRUB has the following features (note that the Multiboot Specification doesn't require all the features that GRUB supports): Recognize multiple executable formats Support many of the "a.out" variants plus "ELF". Symbol tables are also loaded. Support non-Multiboot kernels Support many of the various free 32-bit kernels that lack Multiboot compliance (primarily FreeBSD, NetBSD(1) (*note Features-Footnote-1::), OpenBSD, and Linux). Chain-loading of other boot loaders is also supported. Load multiples modules Fully support the Multiboot feature of loading multiple modules. Load a configuration file Support a human-readable text configuration file with preset boot commands. You can also load another configuration file dynamically and embed a preset configuration file in a GRUB image file. The list of commands (*note Commands::) are a superset of those supported on the command-line. An example configuration file is provided in *note Configuration::. Provide a menu interface A menu interface listing preset boot commands, with a programmable timeout, is available. There is no fixed limit on the number of boot entries, and the current implementation has space for several hundred. Have a flexible command-line interface A fairly flexible command-line interface, accessible from the menu, is available to edit any preset commands, or write a new boot command set from scratch. If no configuration file is present, GRUB drops to the command-line. The list of commands (*note Commands::) are a subset of those supported for configuration files. Editing commands closely resembles the Bash command-line (*note Bash: (features)Command Line Editing.), with -completion of commands, devices, partitions, and files in a directory depending on context. Support multiple filesystem types Support multiple filesystem types transparently, plus a useful explicit blocklist notation. The currently supported filesystem types are "Amiga Fast FileSystem (AFFS)", "AtheOS fs", "BeFS", "BtrFS" (including raid0, raid1, raid10, gzip and lzo), "cpio" (little- and big-endian bin, odc and newc variants), "Linux ext2/ext3/ext4", "DOS FAT12/FAT16/FAT32", "exFAT", "F2FS", "HFS", "HFS+", "ISO9660" (including Joliet, Rock-ridge and multi-chunk files), "JFS", "Minix fs" (versions 1, 2 and 3), "nilfs2", "NTFS" (including compression), "ReiserFS", "ROMFS", "Amiga Smart FileSystem (SFS)", "Squash4", "tar", "UDF", "BSD UFS/UFS2", "XFS", and "ZFS" (including lzjb, gzip, zle, mirror, stripe, raidz1/2/3 and encryption in AES-CCM and AES-GCM). *Note Filesystem::, for more information. Support automatic decompression Can decompress files which were compressed by 'gzip' or 'xz'(2) (*note Features-Footnote-2::). This function is both automatic and transparent to the user (i.e. all functions operate upon the uncompressed contents of the specified files). This greatly reduces a file size and loading time, a particularly great benefit for floppies.(3) (*note Features-Footnote-3::) It is conceivable that some kernel modules should be loaded in a compressed state, so a different module-loading command can be specified to avoid uncompressing the modules. Access data on any installed device Support reading data from any or all floppies or hard disk(s) recognized by the BIOS, independent of the setting of the root device. Be independent of drive geometry translations Unlike many other boot loaders, GRUB makes the particular drive translation irrelevant. A drive installed and running with one translation may be converted to another translation without any adverse effects or changes in GRUB's configuration. Detect all installed RAM GRUB can generally find all the installed RAM on a PC-compatible machine. It uses an advanced BIOS query technique for finding all memory regions. As described on the Multiboot Specification (*note Multiboot Specification: (multiboot)Top.), not all kernels make use of this information, but GRUB provides it for those who do. Support Logical Block Address mode In traditional disk calls (called "CHS mode"), there is a geometry translation problem, that is, the BIOS cannot access over 1024 cylinders, so the accessible space is limited to at least 508 MB and to at most 8GB. GRUB can't universally solve this problem, as there is no standard interface used in all machines. However, several newer machines have the new interface, Logical Block Address ("LBA") mode. GRUB automatically detects if LBA mode is available and uses it if available. In LBA mode, GRUB can access the entire disk. Support network booting GRUB is basically a disk-based boot loader but also has network support. You can load OS images from a network by using the "TFTP" protocol. Support remote terminals To support computers with no console, GRUB provides remote terminal support, so that you can control GRUB from a remote host. Only serial terminal support is implemented at the moment. (1) The NetBSD/i386 kernel is Multiboot-compliant, but lacks support for Multiboot modules. (2) Only CRC32 data integrity check is supported (xz default is CRC64 so one should use -check=crc32 option). LZMA BCJ filters are supported. (3) There are a few pathological cases where loading a very badly organized ELF kernel might take longer, but in practice this never happen. 1.5 The role of a boot loader ============================= The following is a quotation from Gordon Matzigkeit, a GRUB fanatic: Some people like to acknowledge both the operating system and kernel when they talk about their computers, so they might say they use "GNU/Linux" or "GNU/Hurd". Other people seem to think that the kernel is the most important part of the system, so they like to call their GNU operating systems "Linux systems." I, personally, believe that this is a grave injustice, because the _boot loader_ is the most important software of all. I used to refer to the above systems as either "LILO"(1) (*note Role of a boot loader-Footnote-1::) or "GRUB" systems. Unfortunately, nobody ever understood what I was talking about; now I just use the word "GNU" as a pseudonym for GRUB. So, if you ever hear people talking about their alleged "GNU" systems, remember that they are actually paying homage to the best boot loader around... GRUB! We, the GRUB maintainers, do not (usually) encourage Gordon's level of fanaticism, but it helps to remember that boot loaders deserve recognition. We hope that you enjoy using GNU GRUB as much as we did writing it. (1) The LInux LOader, a boot loader that everybody uses, but nobody likes.