Added GRUB docs, Added netboot.xyz
This commit is contained in:
parent
637d9037dc
commit
8f9ccbfa39
35 changed files with 6482 additions and 28 deletions
312
boot/grub/persistent/docs/01_introduction
Normal file
312
boot/grub/persistent/docs/01_introduction
Normal file
|
|
@ -0,0 +1,312 @@
|
|||
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.
|
||||
|
||||
Loading…
Add table
Add a link
Reference in a new issue