grubby/boot/grub/persistent/docs/01_introduction

313 lines
14 KiB
Plaintext

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.