313 lines
14 KiB
Text
313 lines
14 KiB
Text
|
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 <TAB>-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.
|
||
|
|