892a3d9805
* docs/grub.texi: Major overhaul. Remove all sections that are
specific to GRUB Legacy, or mostly composed of Legacy-specific
information.
1406 lines
48 KiB
Text
1406 lines
48 KiB
Text
\input texinfo
|
|
@c -*-texinfo-*-
|
|
@c %**start of header
|
|
@setfilename grub.info
|
|
@include version.texi
|
|
@settitle GNU GRUB Manual @value{VERSION}
|
|
@c Unify all our little indices for now.
|
|
@syncodeindex fn cp
|
|
@syncodeindex vr cp
|
|
@syncodeindex ky cp
|
|
@syncodeindex pg cp
|
|
@syncodeindex tp cp
|
|
@c %**end of header
|
|
|
|
@footnotestyle separate
|
|
@paragraphindent 3
|
|
@finalout
|
|
|
|
@copying
|
|
This manual is for GNU GRUB (version @value{VERSION},
|
|
@value{UPDATED}).
|
|
|
|
Copyright @copyright{} 1999,2000,2001,2002,2004,2006,2008 Free Software Foundation, Inc.
|
|
|
|
@quotation
|
|
Permission is granted to copy, distribute and/or modify this document
|
|
under the terms of the GNU Free Documentation License, Version 1.2 or
|
|
any later version published by the Free Software Foundation; with no
|
|
Invariant Sections.
|
|
@end quotation
|
|
@end copying
|
|
|
|
@dircategory Kernel
|
|
@direntry
|
|
* GRUB: (grub). The GRand Unified Bootloader
|
|
* grub-install: (grub)Invoking grub-install. Install GRUB on your drive
|
|
* grub-terminfo: (grub)Invoking grub-terminfo. Generate a terminfo
|
|
command from a
|
|
terminfo name
|
|
@end direntry
|
|
|
|
@setchapternewpage odd
|
|
|
|
@titlepage
|
|
@sp 10
|
|
@title the GNU GRUB manual
|
|
@subtitle The GRand Unified Bootloader, version @value{VERSION}, @value{UPDATED}.
|
|
@author Gordon Matzigkeit
|
|
@author Yoshinori K. Okuji
|
|
@c The following two commands start the copyright page.
|
|
@page
|
|
@vskip 0pt plus 1filll
|
|
@insertcopying
|
|
@end titlepage
|
|
|
|
@c Output the table of contents at the beginning.
|
|
@contents
|
|
|
|
@finalout
|
|
@headings double
|
|
|
|
@ifnottex
|
|
@node Top
|
|
@top GNU GRUB manual
|
|
|
|
This is the documentation of GNU GRUB, the GRand Unified Bootloader,
|
|
a flexible and powerful boot loader program for a wide range of
|
|
architectures.
|
|
|
|
This edition documents version @value{VERSION}.
|
|
|
|
@insertcopying
|
|
@end ifnottex
|
|
|
|
@menu
|
|
* Introduction:: Capturing the spirit of GRUB
|
|
* Naming convention:: Names of your drives in GRUB
|
|
* Installation:: Installing GRUB on your drive
|
|
* Booting:: How to boot different operating systems
|
|
* Configuration:: Writing your own configuration file
|
|
* Network:: Downloading OS images from a network
|
|
* Serial terminal:: Using GRUB via a serial line
|
|
* Preset Menu:: Embedding a configuration file into GRUB
|
|
* Images:: GRUB image files
|
|
* Filesystem:: Filesystem syntax and semantics
|
|
* Interface:: The menu and the command-line
|
|
* Commands:: The list of available builtin commands
|
|
* Troubleshooting:: Error messages produced by GRUB
|
|
* Invoking the grub shell:: How to use the grub shell
|
|
* Invoking grub-install:: How to use the GRUB installer
|
|
* Invoking grub-terminfo:: How to generate a terminfo command
|
|
* Obtaining and Building GRUB:: How to obtain and build GRUB
|
|
* Reporting bugs:: Where you should send a bug report
|
|
* Future:: Some future plans on GRUB
|
|
* Internals:: Hacking GRUB
|
|
* Copying This Manual:: Copying This Manual
|
|
* Index::
|
|
@end menu
|
|
|
|
|
|
@node Introduction
|
|
@chapter Introduction to GRUB
|
|
|
|
@menu
|
|
* Overview:: What exactly GRUB is and how to use it
|
|
* History:: From maggot to house fly
|
|
* Features:: GRUB features
|
|
* Role of a boot loader:: The role of a boot loader
|
|
@end menu
|
|
|
|
|
|
@node Overview
|
|
@section Overview
|
|
|
|
Briefly, a @dfn{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 @dfn{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@footnote{@dfn{chain-load} is the mechanism for loading
|
|
unsupported operating systems by loading another boot loader. It is
|
|
typically used for loading DOS or Windows.}. 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
|
|
(@pxref{Command-line interface}), or a menu interface (@pxref{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
|
|
(@pxref{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 (@pxref{Naming convention}) to GRUB, how to
|
|
install GRUB on your drive (@pxref{Installation}), and how to boot your
|
|
OSes (@pxref{Booting}), step by step.
|
|
|
|
|
|
@node History
|
|
@section 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
|
|
(@pxref{Top, Multiboot Specification, Motivation, multiboot, The Multiboot
|
|
Specification}), 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. @xref{Obtaining and Building
|
|
GRUB}, for more information.
|
|
|
|
|
|
@node Features
|
|
@section GRUB features
|
|
|
|
The primary requirement for GRUB is that it be compliant with the
|
|
@dfn{Multiboot Specification}, which is described in @ref{Top, Multiboot
|
|
Specification, Motivation, multiboot, The Multiboot Specification}.
|
|
|
|
The other goals, listed in approximate order of importance, are:
|
|
|
|
@itemize @bullet{}
|
|
@item
|
|
Basic functions must be straightforward for end-users.
|
|
|
|
@item
|
|
Rich functionality to support kernel experts and designers.
|
|
|
|
@item
|
|
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.
|
|
@end itemize
|
|
|
|
Except for specific compatibility modes (chain-loading and the Linux
|
|
@dfn{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):
|
|
|
|
@table @asis
|
|
@item Recognize multiple executable formats
|
|
Support many of the @dfn{a.out} variants plus @dfn{ELF}. Symbol
|
|
tables are also loaded.
|
|
|
|
@item Support non-Multiboot kernels
|
|
Support many of the various free 32-bit kernels that lack Multiboot
|
|
compliance (primarily FreeBSD, NetBSD, OpenBSD, and
|
|
Linux). Chain-loading of other boot loaders is also supported.
|
|
|
|
@item Load multiples modules
|
|
Fully support the Multiboot feature of loading multiple modules.
|
|
|
|
@item 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 (@pxref{Commands}) are a superset of those supported on the
|
|
command-line. An example configuration file is provided in
|
|
@ref{Configuration}.
|
|
|
|
@item 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.
|
|
|
|
@item 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 (@pxref{Commands}) are a subset of those supported
|
|
for configuration files. Editing commands closely resembles the Bash
|
|
command-line (@pxref{Command Line Editing, Bash, Command Line Editing,
|
|
features, Bash Features}), with @key{TAB}-completion of commands,
|
|
devices, partitions, and files in a directory depending on context.
|
|
|
|
@item Support multiple filesystem types
|
|
Support multiple filesystem types transparently, plus a useful explicit
|
|
blocklist notation. The currently supported filesystem types are
|
|
@dfn{BSD FFS}, @dfn{DOS FAT16 and FAT32}, @dfn{Minix fs}, @dfn{Linux
|
|
ext2fs}, @dfn{ReiserFS}, @dfn{JFS}, @dfn{XFS}, and @dfn{VSTa
|
|
fs}. @xref{Filesystem}, for more information.
|
|
|
|
@item Support automatic decompression
|
|
Can decompress files which were compressed by @command{gzip}. 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.@footnote{There are a few
|
|
pathological cases where loading a very badly organized ELF kernel might
|
|
take longer, but in practice this never happen.}
|
|
|
|
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.
|
|
|
|
@item 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.
|
|
|
|
@item 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.
|
|
|
|
@item Detect all installed @sc{ram}
|
|
GRUB can generally find all the installed @sc{ram} on a PC-compatible
|
|
machine. It uses an advanced BIOS query technique for finding all
|
|
memory regions. As described on the Multiboot Specification (@pxref{Top,
|
|
Multiboot Specification, Motivation, multiboot, The Multiboot
|
|
Specification}), not all kernels make use of this information, but GRUB
|
|
provides it for those who do.
|
|
|
|
@item Support Logical Block Address mode
|
|
In traditional disk calls (called @dfn{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 (@dfn{LBA}) mode. GRUB
|
|
automatically detects if LBA mode is available and uses it if
|
|
available. In LBA mode, GRUB can access the entire disk.
|
|
|
|
@item 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 @dfn{TFTP}
|
|
protocol.
|
|
|
|
@item 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.
|
|
@end table
|
|
|
|
|
|
@node Role of a boot loader
|
|
@section The role of a boot loader
|
|
|
|
The following is a quotation from Gordon Matzigkeit, a GRUB fanatic:
|
|
|
|
@quotation
|
|
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
|
|
@emph{boot loader} is the most important software of all. I used to
|
|
refer to the above systems as either ``LILO''@footnote{The LInux LOader,
|
|
a boot loader that everybody uses, but nobody likes.} 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@dots{} GRUB!
|
|
@end quotation
|
|
|
|
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.
|
|
|
|
|
|
@node Naming convention
|
|
@chapter Naming convention
|
|
|
|
The device syntax used in GRUB is a wee bit different from what you may
|
|
have seen before in your operating system(s), and you need to know it so
|
|
that you can specify a drive/partition.
|
|
|
|
Look at the following examples and explanations:
|
|
|
|
@example
|
|
(fd0)
|
|
@end example
|
|
|
|
First of all, GRUB requires that the device name be enclosed with
|
|
@samp{(} and @samp{)}. The @samp{fd} part means that it is a floppy
|
|
disk. The number @samp{0} is the drive number, which is counted from
|
|
@emph{zero}. This expression means that GRUB will use the whole floppy
|
|
disk.
|
|
|
|
@example
|
|
(hd0,1)
|
|
@end example
|
|
|
|
Here, @samp{hd} means it is a hard disk drive. The first integer
|
|
@samp{0} indicates the drive number, that is, the first hard disk, while
|
|
the second integer, @samp{1}, indicates the partition number (or the
|
|
@sc{pc} slice number in the BSD terminology). Once again, please note
|
|
that the partition numbers are counted from @emph{zero}, not from
|
|
one. This expression means the second partition of the first hard disk
|
|
drive. In this case, GRUB uses one partition of the disk, instead of the
|
|
whole disk.
|
|
|
|
@example
|
|
(hd0,4)
|
|
@end example
|
|
|
|
This specifies the first @dfn{extended partition} of the first hard disk
|
|
drive. Note that the partition numbers for extended partitions are
|
|
counted from @samp{4}, regardless of the actual number of primary
|
|
partitions on your hard disk.
|
|
|
|
@example
|
|
(hd1,a)
|
|
@end example
|
|
|
|
This means the BSD @samp{a} partition of the second hard disk. If you
|
|
need to specify which @sc{pc} slice number should be used, use something
|
|
like this: @samp{(hd1,0,a)}. If the @sc{pc} slice number is omitted,
|
|
GRUB searches for the first @sc{pc} slice which has a BSD @samp{a}
|
|
partition.
|
|
|
|
Of course, to actually access the disks or partitions with GRUB, you
|
|
need to use the device specification in a command, like @samp{root
|
|
(fd0)} or @samp{unhide (hd0,2)}. To help you find out which number
|
|
specifies a partition you want, the GRUB command-line
|
|
(@pxref{Command-line interface}) options have argument
|
|
completion. This means that, for example, you only need to type
|
|
|
|
@example
|
|
root (
|
|
@end example
|
|
|
|
followed by a @key{TAB}, and GRUB will display the list of drives,
|
|
partitions, or file names. So it should be quite easy to determine the
|
|
name of your target partition, even with minimal knowledge of the
|
|
syntax.
|
|
|
|
Note that GRUB does @emph{not} distinguish IDE from SCSI - it simply
|
|
counts the drive numbers from zero, regardless of their type. Normally,
|
|
any IDE drive number is less than any SCSI drive number, although that
|
|
is not true if you change the boot sequence by swapping IDE and SCSI
|
|
drives in your BIOS.
|
|
|
|
Now the question is, how to specify a file? Again, consider an
|
|
example:
|
|
|
|
@example
|
|
(hd0,0)/vmlinuz
|
|
@end example
|
|
|
|
This specifies the file named @samp{vmlinuz}, found on the first
|
|
partition of the first hard disk drive. Note that the argument
|
|
completion works with file names, too.
|
|
|
|
That was easy, admit it. Now read the next chapter, to find out how to
|
|
actually install GRUB on your drive.
|
|
|
|
|
|
@node Installation
|
|
@chapter Installation
|
|
|
|
In order to install GRUB as your boot loader, you need to first
|
|
install the GRUB system and utilities under your UNIX-like operating
|
|
system (@pxref{Obtaining and Building GRUB}). You can do this either
|
|
from the source tarball, or as a package for your OS.
|
|
|
|
After you have done that, you need to install the boot loader on a
|
|
drive (floppy or hard disk). There are two ways of doing that - either
|
|
using the utility @command{grub-install} (@pxref{Invoking
|
|
grub-install}) on a UNIX-like OS, or by running GRUB itself from a
|
|
floppy. These are quite similar, however the utility might probe a
|
|
wrong BIOS drive, so you should be careful.
|
|
|
|
Also, if you install GRUB on a UNIX-like OS, please make sure that you
|
|
have an emergency boot disk ready, so that you can rescue your computer
|
|
if, by any chance, your hard drive becomes unusable (unbootable).
|
|
|
|
GRUB comes with boot images, which are normally put in the directory
|
|
@file{/usr/lib/grub/i386-pc}. Hereafter, the directory where GRUB images are
|
|
initially placed (normally @file{/usr/lib/grub/i386-pc}) will be
|
|
called the @dfn{image directory}, and the directory where the boot
|
|
loader needs to find them (usually @file{/boot/grub}) will be called
|
|
the @dfn{boot directory}.
|
|
|
|
@menu
|
|
* Installing GRUB using grub-install::
|
|
@end menu
|
|
|
|
|
|
@node Installing GRUB using grub-install
|
|
@section Installing GRUB using grub-install
|
|
|
|
@strong{Caution:} This procedure is definitely less safe, because
|
|
there are several ways in which your computer can become
|
|
unbootable. For example, most operating systems don't tell GRUB how to
|
|
map BIOS drives to OS devices correctly---GRUB merely @dfn{guesses}
|
|
the mapping. This will succeed in most cases, but not
|
|
always. Therefore, GRUB provides you with a map file called the
|
|
@dfn{device map}, which you must fix if it is wrong. @xref{Device
|
|
map}, for more details.
|
|
|
|
If you still do want to install GRUB under a UNIX-like OS (such
|
|
as @sc{gnu}), invoke the program @command{grub-install} (@pxref{Invoking
|
|
grub-install}) as the superuser (@dfn{root}).
|
|
|
|
The usage is basically very simple. You only need to specify one
|
|
argument to the program, namely, where to install the boot loader. The
|
|
argument can be either a device file (like @samp{/dev/hda}) or a
|
|
partition specified in GRUB's notation. For example, under Linux the
|
|
following will install GRUB into the MBR of the first IDE disk:
|
|
|
|
@example
|
|
# @kbd{grub-install /dev/hda}
|
|
@end example
|
|
|
|
Likewise, under GNU/Hurd, this has the same effect:
|
|
|
|
@example
|
|
# @kbd{grub-install /dev/hd0}
|
|
@end example
|
|
|
|
If it is the first BIOS drive, this is the same as well:
|
|
|
|
@example
|
|
# @kbd{grub-install '(hd0)'}
|
|
@end example
|
|
|
|
Or you can omit the parentheses:
|
|
|
|
@example
|
|
# @kbd{grub-install hd0}
|
|
@end example
|
|
|
|
But all the above examples assume that GRUB should use images under
|
|
the root directory. If you want GRUB to use images under a directory
|
|
other than the root directory, you need to specify the option
|
|
@option{--root-directory}. The typical usage is that you create a GRUB
|
|
boot floppy with a filesystem. Here is an example:
|
|
|
|
@example
|
|
@group
|
|
# @kbd{mke2fs /dev/fd0}
|
|
# @kbd{mount -t ext2 /dev/fd0 /mnt}
|
|
# @kbd{grub-install --root-directory=/mnt fd0}
|
|
# @kbd{umount /mnt}
|
|
@end group
|
|
@end example
|
|
|
|
Another example is when you have a separate boot partition
|
|
which is mounted at @file{/boot}. Since GRUB is a boot loader, it
|
|
doesn't know anything about mountpoints at all. Thus, you need to run
|
|
@command{grub-install} like this:
|
|
|
|
@example
|
|
# @kbd{grub-install --root-directory=/boot /dev/hda}
|
|
@end example
|
|
|
|
By the way, as noted above, it is quite difficult to guess BIOS drives
|
|
correctly under a UNIX-like OS. Thus, @command{grub-install} will prompt
|
|
you to check if it could really guess the correct mappings, after the
|
|
installation. The format is defined in @ref{Device map}. Please be
|
|
quite careful. If the output is wrong, it is unlikely that your
|
|
computer will be able to boot with no problem.
|
|
|
|
Note that @command{grub-install} is actually just a shell script and the
|
|
real task is done by the grub shell @command{grub} (@pxref{Invoking the
|
|
grub shell}). Therefore, you may run @command{grub} directly to install
|
|
GRUB, without using @command{grub-install}. Don't do that, however,
|
|
unless you are very familiar with the internals of GRUB. Installing a
|
|
boot loader on a running OS may be extremely dangerous.
|
|
|
|
|
|
@node Making a GRUB bootable CD-ROM
|
|
@section Making a GRUB bootable CD-ROM
|
|
|
|
GRUB supports the @dfn{no emulation mode} in the El Torito
|
|
specification@footnote{El Torito is a specification for bootable CD
|
|
using BIOS functions.}. This means that you can use the whole CD-ROM
|
|
from GRUB and you don't have to make a floppy or hard disk image file,
|
|
which can cause compatibility problems.
|
|
|
|
For booting from a CD-ROM, GRUB uses a special Stage 2 called
|
|
@file{stage2_eltorito}. The only GRUB files you need to have in your
|
|
bootable CD-ROM are this @file{stage2_eltorito} and optionally a config file
|
|
@file{menu.lst}. You don't need to use @file{stage1} or @file{stage2},
|
|
because El Torito is quite different from the standard boot process.
|
|
|
|
Here is an example of procedures to make a bootable CD-ROM
|
|
image. First, make a top directory for the bootable image, say,
|
|
@samp{iso}:
|
|
|
|
@example
|
|
$ @kbd{mkdir iso}
|
|
@end example
|
|
|
|
Make a directory for GRUB:
|
|
|
|
@example
|
|
$ @kbd{mkdir -p iso/boot/grub}
|
|
@end example
|
|
|
|
Copy the file @file{stage2_eltorito}:
|
|
|
|
@example
|
|
$ @kbd{cp /usr/lib/grub/i386-pc/stage2_eltorito iso/boot/grub}
|
|
@end example
|
|
|
|
If desired, make the config file @file{menu.lst} under @file{iso/boot/grub}
|
|
(@pxref{Configuration}), and copy any files and directories for the disc to the
|
|
directory @file{iso/}.
|
|
|
|
Finally, make a ISO9660 image file like this:
|
|
|
|
@example
|
|
$ @kbd{mkisofs -R -b boot/grub/stage2_eltorito -no-emul-boot \
|
|
-boot-load-size 4 -boot-info-table -o grub.iso iso}
|
|
@end example
|
|
|
|
This produces a file named @file{grub.iso}, which then can be burned
|
|
into a CD (or a DVD). @kbd{mkisofs} has already set up the disc to boot
|
|
from the @kbd{boot/grub/stage2_eltorito} file, so there is no need to
|
|
setup GRUB on the disc. (Note that the @kbd{-boot-load-size 4} bit is
|
|
required for compatibility with the BIOS on many older machines.)
|
|
|
|
You can use the device @samp{(cd)} to access a CD-ROM in your
|
|
config file. This is not required; GRUB automatically sets the root device
|
|
to @samp{(cd)} when booted from a CD-ROM. It is only necessary to refer to
|
|
@samp{(cd)} if you want to access other drives as well.
|
|
|
|
|
|
@node Booting
|
|
@chapter Booting
|
|
|
|
GRUB can load Multiboot-compliant kernels in a consistent way,
|
|
but for some free operating systems you need to use some OS-specific
|
|
magic.
|
|
|
|
@menu
|
|
* General boot methods:: How to boot OSes with GRUB generally
|
|
* OS-specific notes:: Notes on some operating systems
|
|
@end menu
|
|
|
|
|
|
@node General boot methods
|
|
@section How to boot operating systems
|
|
|
|
GRUB has two distinct boot methods. One of the two is to load an
|
|
operating system directly, and the other is to chain-load another boot
|
|
loader which then will load an operating system actually. Generally
|
|
speaking, the former is more desirable, because you don't need to
|
|
install or maintain other boot loaders and GRUB is flexible enough to
|
|
load an operating system from an arbitrary disk/partition. However,
|
|
the latter is sometimes required, since GRUB doesn't support all the
|
|
existing operating systems natively.
|
|
|
|
@menu
|
|
* Loading an operating system directly::
|
|
* Chain-loading::
|
|
@end menu
|
|
|
|
|
|
@node Loading an operating system directly
|
|
@subsection How to boot an OS directly with GRUB
|
|
|
|
Multiboot (@pxref{Top, Multiboot Specification, Motivation, multiboot,
|
|
The Multiboot Specification}) is the native format supported by GRUB.
|
|
For the sake of convenience, there is also support for Linux, FreeBSD,
|
|
NetBSD and OpenBSD. If you want to boot other operating systems, you
|
|
will have to chain-load them (@pxref{Chain-loading}).
|
|
|
|
FIXME: this section is incomplete.
|
|
|
|
@enumerate
|
|
@item
|
|
Run the command @command{boot} (@pxref{boot}).
|
|
@end enumerate
|
|
|
|
However, DOS and Windows have some deficiencies, so you might have to
|
|
use more complicated instructions. @xref{DOS/Windows}, for more
|
|
information.
|
|
|
|
|
|
@node OS-specific notes
|
|
@section Some caveats on OS-specific issues
|
|
|
|
Here, we describe some caveats on several operating systems.
|
|
|
|
@menu
|
|
* GNU/Hurd::
|
|
* GNU/Linux::
|
|
@end menu
|
|
|
|
|
|
@node GNU/Hurd
|
|
@subsection GNU/Hurd
|
|
|
|
Since GNU/Hurd is Multiboot-compliant, it is easy to boot it; there is
|
|
nothing special about it. But do not forget that you have to specify a
|
|
root partition to the kernel.
|
|
|
|
FIXME: this section is incomplete.
|
|
|
|
@enumerate
|
|
@item
|
|
Run the command @command{boot} (@pxref{boot}).
|
|
@end enumerate
|
|
|
|
|
|
@node GNU/Linux
|
|
@subsection GNU/Linux
|
|
|
|
It is relatively easy to boot GNU/Linux from GRUB, because it somewhat
|
|
resembles to boot a Multiboot-compliant OS.
|
|
|
|
FIXME: this section is incomplete.
|
|
|
|
@enumerate
|
|
@item
|
|
Set GRUB's root device to the same drive as GNU/Linux's.
|
|
|
|
@item
|
|
Finally, run the command @command{boot} (@pxref{boot}).
|
|
@end enumerate
|
|
|
|
@strong{Caution:} If you use an initrd and specify the @samp{mem=}
|
|
option to the kernel to let it use less than actual memory size, you
|
|
will also have to specify the same memory size to GRUB. To let GRUB know
|
|
the size, run the command @command{uppermem} @emph{before} loading the
|
|
kernel. @xref{uppermem}, for more information.
|
|
|
|
|
|
@node Serial terminal
|
|
@chapter Using GRUB via a serial line
|
|
|
|
This chapter describes how to use the serial terminal support in GRUB.
|
|
|
|
If you have many computers or computers with no display/keyboard, it
|
|
could be very useful to control the computers through serial
|
|
communications. To connect one computer with another via a serial line,
|
|
you need to prepare a null-modem (cross) serial cable, and you may need
|
|
to have multiport serial boards, if your computer doesn't have extra
|
|
serial ports. In addition, a terminal emulator is also required, such as
|
|
minicom. Refer to a manual of your operating system, for more
|
|
information.
|
|
|
|
As for GRUB, the instruction to set up a serial terminal is quite
|
|
simple. First of all, make sure that you haven't specified the option
|
|
@option{--disable-serial} to the configure script when you built your
|
|
GRUB images. If you get them in binary form, probably they have serial
|
|
terminal support already.
|
|
|
|
Then, initialize your serial terminal after GRUB starts up. Here is an
|
|
example:
|
|
|
|
@example
|
|
@group
|
|
grub> @kbd{serial --unit=0 --speed=9600}
|
|
grub> @kbd{terminal serial}
|
|
@end group
|
|
@end example
|
|
|
|
The command @command{serial} initializes the serial unit 0 with the
|
|
speed 9600bps. The serial unit 0 is usually called @samp{COM1}, so, if
|
|
you want to use COM2, you must specify @samp{--unit=1} instead. This
|
|
command accepts many other options, so please refer to @ref{serial},
|
|
for more details.
|
|
|
|
The command @command{terminal} (@pxref{terminal}) chooses which type of
|
|
terminal you want to use. In the case above, the terminal will be a
|
|
serial terminal, but you can also pass @code{console} to the command,
|
|
as @samp{terminal serial console}. In this case, a terminal in which
|
|
you press any key will be selected as a GRUB terminal.
|
|
|
|
However, note that GRUB assumes that your terminal emulator is
|
|
compatible with VT100 by default. This is true for most terminal
|
|
emulators nowadays, but you should pass the option @option{--dumb} to
|
|
the command if your terminal emulator is not VT100-compatible or
|
|
implements few VT100 escape sequences. If you specify this option then
|
|
GRUB provides you with an alternative menu interface, because the normal
|
|
menu requires several fancy features of your terminal.
|
|
|
|
|
|
@node Filesystem
|
|
@chapter Filesystem syntax and semantics
|
|
|
|
GRUB uses a special syntax for specifying disk drives which can be
|
|
accessed by BIOS. Because of BIOS limitations, GRUB cannot distinguish
|
|
between IDE, ESDI, SCSI, or others. You must know yourself which BIOS
|
|
device is equivalent to which OS device. Normally, that will be clear if
|
|
you see the files in a device or use the command @command{find}
|
|
(@pxref{find}).
|
|
|
|
@menu
|
|
* Device syntax:: How to specify devices
|
|
* File name syntax:: How to specify files
|
|
* Block list syntax:: How to specify block lists
|
|
@end menu
|
|
|
|
|
|
@node Device syntax
|
|
@section How to specify devices
|
|
|
|
The device syntax is like this:
|
|
|
|
@example
|
|
@code{(@var{device}[,@var{part-num}][,@var{bsd-subpart-letter}])}
|
|
@end example
|
|
|
|
@samp{[]} means the parameter is optional. @var{device} should be
|
|
either @samp{fd} or @samp{hd} followed by a digit, like @samp{fd0}.
|
|
But you can also set @var{device} to a hexadecimal or a decimal number
|
|
which is a BIOS drive number, so the following are equivalent:
|
|
|
|
@example
|
|
(hd0)
|
|
(0x80)
|
|
(128)
|
|
@end example
|
|
|
|
@var{part-num} represents the partition number of @var{device}, starting
|
|
from zero for primary partitions and from four for extended partitions,
|
|
and @var{bsd-subpart-letter} represents the BSD disklabel subpartition,
|
|
such as @samp{a} or @samp{e}.
|
|
|
|
A shortcut for specifying BSD subpartitions is
|
|
@code{(@var{device},@var{bsd-subpart-letter})}, in this case, GRUB
|
|
searches for the first PC partition containing a BSD disklabel, then
|
|
finds the subpartition @var{bsd-subpart-letter}. Here is an example:
|
|
|
|
@example
|
|
(hd0,a)
|
|
@end example
|
|
|
|
The syntax @samp{(hd0)} represents using the entire disk (or the
|
|
MBR when installing GRUB), while the syntax @samp{(hd0,0)}
|
|
represents using the first partition of the disk (or the boot sector
|
|
of the partition when installing GRUB).
|
|
|
|
If you enabled the network support, the special drive, @samp{(nd)}, is
|
|
also available. Before using the network drive, you must initialize the
|
|
network. @xref{Network}, for more information.
|
|
|
|
If you boot GRUB from a CD-ROM, @samp{(cd)} is available. @xref{Making
|
|
a GRUB bootable CD-ROM}, for details.
|
|
|
|
|
|
@node File name syntax
|
|
@section How to specify files
|
|
|
|
There are two ways to specify files, by @dfn{absolute file name} and by
|
|
@dfn{block list}.
|
|
|
|
An absolute file name resembles a Unix absolute file name, using
|
|
@samp{/} for the directory separator (not @samp{\} as in DOS). One
|
|
example is @samp{(hd0,0)/boot/grub/menu.lst}. This means the file
|
|
@file{/boot/grub/menu.lst} in the first partition of the first hard
|
|
disk. If you omit the device name in an absolute file name, GRUB uses
|
|
GRUB's @dfn{root device} implicitly. So if you set the root device to,
|
|
say, @samp{(hd1,0)} by the command @command{root} (@pxref{root}), then
|
|
@code{/boot/kernel} is the same as @code{(hd1,0)/boot/kernel}.
|
|
|
|
|
|
@node Block list syntax
|
|
@section How to specify block lists
|
|
|
|
A block list is used for specifying a file that doesn't appear in the
|
|
filesystem, like a chainloader. The syntax is
|
|
@code{[@var{offset}]+@var{length}[,[@var{offset}]+@var{length}]@dots{}}.
|
|
Here is an example:
|
|
|
|
@example
|
|
@code{0+100,200+1,300+300}
|
|
@end example
|
|
|
|
This represents that GRUB should read blocks 0 through 99, block 200,
|
|
and blocks 300 through 599. If you omit an offset, then GRUB assumes
|
|
the offset is zero.
|
|
|
|
Like the file name syntax (@pxref{File name syntax}), if a blocklist
|
|
does not contain a device name, then GRUB uses GRUB's @dfn{root
|
|
device}. So @code{(hd0,1)+1} is the same as @code{+1} when the root
|
|
device is @samp{(hd0,1)}.
|
|
|
|
|
|
@node Interface
|
|
@chapter GRUB's user interface
|
|
|
|
GRUB has both a simple menu interface for choosing preset entries from a
|
|
configuration file, and a highly flexible command-line for performing
|
|
any desired combination of boot commands.
|
|
|
|
GRUB looks for its configuration file as soon as it is loaded. If one
|
|
is found, then the full menu interface is activated using whatever
|
|
entries were found in the file. If you choose the @dfn{command-line} menu
|
|
option, or if the configuration file was not found, then GRUB drops to
|
|
the command-line interface.
|
|
|
|
@menu
|
|
* Command-line interface:: The flexible command-line interface
|
|
* Menu interface:: The simple menu interface
|
|
@end menu
|
|
|
|
|
|
@node Command-line interface
|
|
@section The flexible command-line interface
|
|
|
|
The command-line interface provides a prompt and after it an editable
|
|
text area much like a command-line in Unix or DOS. Each command is
|
|
immediately executed after it is entered@footnote{However, this
|
|
behavior will be changed in the future version, in a user-invisible
|
|
way.}. The commands (@pxref{Command-line and menu entry commands}) are a
|
|
subset of those available in the configuration file, used with exactly
|
|
the same syntax.
|
|
|
|
Cursor movement and editing of the text on the line can be done via a
|
|
subset of the functions available in the Bash shell:
|
|
|
|
@table @key
|
|
@item C-f
|
|
@itemx PC right key
|
|
Move forward one character.
|
|
|
|
@item C-b
|
|
@itemx PC left key
|
|
Move back one character.
|
|
|
|
@item C-a
|
|
@itemx HOME
|
|
Move to the start of the line.
|
|
|
|
@item C-e
|
|
@itemx END
|
|
Move the the end of the line.
|
|
|
|
@item C-d
|
|
@itemx DEL
|
|
Delete the character underneath the cursor.
|
|
|
|
@item C-h
|
|
@itemx BS
|
|
Delete the character to the left of the cursor.
|
|
|
|
@item C-k
|
|
Kill the text from the current cursor position to the end of the line.
|
|
|
|
@item C-u
|
|
Kill backward from the cursor to the beginning of the line.
|
|
|
|
@item C-y
|
|
Yank the killed text back into the buffer at the cursor.
|
|
|
|
@item C-p
|
|
@itemx PC up key
|
|
Move up through the history list.
|
|
|
|
@item C-n
|
|
@itemx PC down key
|
|
Move down through the history list.
|
|
@end table
|
|
|
|
When typing commands interactively, if the cursor is within or before
|
|
the first word in the command-line, pressing the @key{TAB} key (or
|
|
@key{C-i}) will display a listing of the available commands, and if the
|
|
cursor is after the first word, the @kbd{@key{TAB}} will provide a
|
|
completion listing of disks, partitions, and file names depending on the
|
|
context. Note that to obtain a list of drives, one must open a
|
|
parenthesis, as @command{root (}.
|
|
|
|
Note that you cannot use the completion functionality in the TFTP
|
|
filesystem. This is because TFTP doesn't support file name listing for
|
|
the security.
|
|
|
|
|
|
@node Menu interface
|
|
@section The simple menu interface
|
|
|
|
The menu interface is quite easy to use. Its commands are both
|
|
reasonably intuitive and described on screen.
|
|
|
|
Basically, the menu interface provides a list of @dfn{boot entries} to
|
|
the user to choose from. Use the arrow keys to select the entry of
|
|
choice, then press @key{RET} to run it. An optional timeout is
|
|
available to boot the default entry (the first one if not set), which is
|
|
aborted by pressing any key.
|
|
|
|
Commands are available to enter a bare command-line by pressing @key{c}
|
|
(which operates exactly like the non-config-file version of GRUB, but
|
|
allows one to return to the menu if desired by pressing @key{ESC}) or to
|
|
edit any of the @dfn{boot entries} by pressing @key{e}.
|
|
|
|
If you protect the menu interface with a password (@pxref{Security}),
|
|
all you can do is choose an entry by pressing @key{RET}, or press
|
|
@key{p} to enter the password.
|
|
|
|
|
|
@node Menu entry editor
|
|
@section Editing a menu entry
|
|
|
|
The menu entry editor looks much like the main menu interface, but the
|
|
lines in the menu are individual commands in the selected entry instead
|
|
of entry names.
|
|
|
|
If an @key{ESC} is pressed in the editor, it aborts all the changes made
|
|
to the configuration entry and returns to the main menu interface.
|
|
|
|
When a particular line is selected, the editor places the user in a
|
|
special version of the GRUB command-line to edit that line. When the
|
|
user hits @key{RET}, GRUB replaces the line in question in the boot
|
|
entry with the changes (unless it was aborted via @key{ESC},
|
|
in which case the changes are thrown away).
|
|
|
|
If you want to add a new line to the menu entry, press @key{o} if adding
|
|
a line after the current line or press @key{O} if before the current
|
|
line.
|
|
|
|
To delete a line, hit the key @key{d}. Although GRUB unfortunately
|
|
does not support @dfn{undo}, you can do almost the same thing by just
|
|
returning to the main menu.
|
|
|
|
|
|
@node Commands
|
|
@chapter The list of available commands
|
|
|
|
In this chapter, we list all commands that are available in GRUB.
|
|
|
|
Commands belong to different groups. A few can only be used in
|
|
the global section of the configuration file (or ``menu''); most
|
|
of them can be entered on the command-line and can be used either
|
|
anywhere in the menu or specifically in the menu entries.
|
|
|
|
@menu
|
|
* Menu-specific commands::
|
|
* General commands::
|
|
* Command-line and menu entry commands::
|
|
@end menu
|
|
|
|
|
|
@node Menu-specific commands
|
|
@section The list of commands for the menu only
|
|
|
|
The semantics used in parsing the configuration file are the following:
|
|
|
|
@itemize @bullet
|
|
@item
|
|
The menu-specific commands have to be used before any others.
|
|
|
|
@item
|
|
The files @emph{must} be in plain-text format.
|
|
|
|
@item
|
|
@samp{#} at the beginning of a line in a configuration file means it is
|
|
only a comment.
|
|
|
|
@item
|
|
Options are separated by spaces.
|
|
|
|
@item
|
|
All numbers can be either decimal or hexadecimal. A hexadecimal number
|
|
must be preceded by @samp{0x}, and is case-insensitive.
|
|
|
|
@item
|
|
Extra options or text at the end of the line are ignored unless otherwise
|
|
specified.
|
|
|
|
@item
|
|
Unrecognized commands are added to the current entry, except before entries
|
|
start, where they are ignored.
|
|
@end itemize
|
|
|
|
These commands can only be used in the menu:
|
|
|
|
@menu
|
|
* menuentry:: Start a menu entry
|
|
@end menu
|
|
|
|
|
|
@node menuentry
|
|
@subsection menuentry
|
|
|
|
@deffn Command title name @dots{}
|
|
Start a new boot entry, and set its name to the contents of the rest of
|
|
the line, starting with the first non-space character.
|
|
@end deffn
|
|
|
|
|
|
@node General commands
|
|
@section The list of general commands
|
|
|
|
Commands usable anywhere in the menu and in the command-line.
|
|
|
|
@menu
|
|
* serial:: Set up a serial device
|
|
* terminfo:: Define escape sequences for a terminal
|
|
@end menu
|
|
|
|
|
|
@node serial
|
|
@subsection serial
|
|
|
|
@deffn Command serial [@option{--unit=unit}] [@option{--port=port}] [@option{--speed=speed}] [@option{--word=word}] [@option{--parity=parity}] [@option{--stop=stop}] [@option{--device=dev}]
|
|
Initialize a serial device. @var{unit} is a number in the range 0-3
|
|
specifying which serial port to use; default is 0, which corresponds to
|
|
the port often called COM1. @var{port} is the I/O port where the UART
|
|
is to be found; if specified it takes precedence over @var{unit}.
|
|
@var{speed} is the transmission speed; default is 9600. @var{word} and
|
|
@var{stop} are the number of data bits and stop bits. Data bits must
|
|
be in the range 5-8 and stop bits must be 1 or 2. Default is 8 data
|
|
bits and one stop bit. @var{parity} is one of @samp{no}, @samp{odd},
|
|
@samp{even} and defaults to @samp{no}. The option @option{--device}
|
|
can only be used in the grub shell and is used to specify the
|
|
tty device to be used in the host operating system (@pxref{Invoking the
|
|
grub shell}).
|
|
|
|
The serial port is not used as a communication channel unless the
|
|
@command{terminal} command is used (@pxref{terminal}).
|
|
|
|
This command is only available if GRUB is compiled with serial
|
|
support. See also @ref{Serial terminal}.
|
|
@end deffn
|
|
|
|
|
|
@node terminfo
|
|
@subsection terminfo
|
|
|
|
@deffn Command terminfo @option{--name=name} @option{--cursor-address=seq} [@option{--clear-screen=seq}] [@option{--enter-standout-mode=seq}] [@option{--exit-standout-mode=seq}]
|
|
Define the capabilities of your terminal. Use this command to define
|
|
escape sequences, if it is not vt100-compatible. You may use @samp{\e}
|
|
for @key{ESC} and @samp{^X} for a control character.
|
|
|
|
You can use the utility @command{grub-terminfo} to generate
|
|
appropriate arguments to this command. @xref{Invoking grub-terminfo}.
|
|
|
|
If no option is specified, the current settings are printed.
|
|
@end deffn
|
|
|
|
|
|
@node Command-line and menu entry commands
|
|
@section The list of command-line and menu entry commands
|
|
|
|
These commands are usable in the command-line and in menu entries. If
|
|
you forget a command, you can run the command @command{help}
|
|
(@pxref{help}).
|
|
|
|
@menu
|
|
* boot:: Start up your operating system
|
|
* cat:: Show the contents of a file
|
|
* chainloader:: Chain-load another boot loader
|
|
* cmp:: Compare two files
|
|
* configfile:: Load a configuration file
|
|
* halt:: Shut down your computer
|
|
* help:: Show help messages
|
|
* reboot:: Reboot your computer
|
|
@end menu
|
|
|
|
|
|
@node boot
|
|
@subsection boot
|
|
|
|
@deffn Command boot
|
|
Boot the OS or chain-loader which has been loaded. Only necessary if
|
|
running the fully interactive command-line (it is implicit at the end of
|
|
a menu entry).
|
|
@end deffn
|
|
|
|
|
|
@node cat
|
|
@subsection cat
|
|
|
|
@deffn Command cat file
|
|
Display the contents of the file @var{file}. This command may be useful
|
|
to remind you of your OS's root partition:
|
|
|
|
@example
|
|
grub> @kbd{cat /etc/fstab}
|
|
@end example
|
|
@end deffn
|
|
|
|
|
|
@node chainloader
|
|
@subsection chainloader
|
|
|
|
@deffn Command chainloader [@option{--force}] file
|
|
Load @var{file} as a chain-loader. Like any other file loaded by the
|
|
filesystem code, it can use the blocklist notation to grab the first
|
|
sector of the current partition with @samp{+1}. If you specify the
|
|
option @option{--force}, then load @var{file} forcibly, whether it has a
|
|
correct signature or not. This is required when you want to load a
|
|
defective boot loader, such as SCO UnixWare 7.1 (@pxref{SCO UnixWare}).
|
|
@end deffn
|
|
|
|
|
|
@node cmp
|
|
@subsection cmp
|
|
|
|
@deffn Command cmp file1 file2
|
|
Compare the file @var{file1} with the file @var{file2}. If they differ
|
|
in size, print the sizes like this:
|
|
|
|
@example
|
|
Differ in size: 0x1234 [foo], 0x4321 [bar]
|
|
@end example
|
|
|
|
If the sizes are equal but the bytes at an offset differ, then print the
|
|
bytes like this:
|
|
|
|
@example
|
|
Differ at the offset 777: 0xbe [foo], 0xef [bar]
|
|
@end example
|
|
|
|
If they are completely identical, nothing will be printed.
|
|
@end deffn
|
|
|
|
|
|
@node configfile
|
|
@subsection configfile
|
|
|
|
@deffn Command configfile file
|
|
Load @var{file} as a configuration file.
|
|
@end deffn
|
|
|
|
|
|
@node halt
|
|
@subsection halt
|
|
|
|
@deffn Command halt @option{--no-apm}
|
|
The command halts the computer. If the @option{--no-apm} option
|
|
is specified, no APM BIOS call is performed. Otherwise, the computer
|
|
is shut down using APM.
|
|
@end deffn
|
|
|
|
|
|
@node help
|
|
@subsection help
|
|
|
|
@deffn Command help @option{--all} [pattern @dots{}]
|
|
Display helpful information about builtin commands. If you do not
|
|
specify @var{pattern}, this command shows short descriptions of most of
|
|
available commands. If you specify the option @option{--all} to this
|
|
command, short descriptions of rarely used commands (such as
|
|
@ref{testload}) are displayed as well.
|
|
|
|
If you specify any @var{patterns}, it displays longer information
|
|
about each of the commands which match those @var{patterns}.
|
|
@end deffn
|
|
|
|
|
|
@node reboot
|
|
@subsection reboot
|
|
|
|
@deffn Command reboot
|
|
Reboot the computer.
|
|
@end deffn
|
|
|
|
|
|
@node Invoking grub-install
|
|
@chapter Invoking grub-install
|
|
|
|
The program @command{grub-install} installs GRUB on your drive using the
|
|
grub shell (@pxref{Invoking the grub shell}). You must specify the
|
|
device name on which you want to install GRUB, like this:
|
|
|
|
@example
|
|
grub-install @var{install_device}
|
|
@end example
|
|
|
|
The device name @var{install_device} is an OS device name or a GRUB
|
|
device name.
|
|
|
|
@command{grub-install} accepts the following options:
|
|
|
|
@table @option
|
|
@item --help
|
|
Print a summary of the command-line options and exit.
|
|
|
|
@item --version
|
|
Print the version number of GRUB and exit.
|
|
|
|
@item --root-directory=@var{dir}
|
|
Install GRUB images under the directory @var{dir} instead of the root
|
|
directory. This option is useful when you want to install GRUB into a
|
|
separate partition or a removable disk. Here is an example in which
|
|
you have a separate @dfn{boot} partition which is mounted on
|
|
@file{/boot}:
|
|
|
|
@example
|
|
@kbd{grub-install --root-directory=/boot hd0}
|
|
@end example
|
|
|
|
@item --recheck
|
|
Recheck the device map, even if @file{/boot/grub/device.map} already
|
|
exists. You should use this option whenever you add/remove a disk
|
|
into/from your computer.
|
|
@end table
|
|
|
|
|
|
@node Obtaining and Building GRUB
|
|
@appendix How to obtain and build GRUB
|
|
|
|
@quotation
|
|
@strong{Caution:} GRUB requires binutils-2.9.1.0.23 or later because the
|
|
GNU assembler has been changed so that it can produce real 16bits
|
|
machine code between 2.9.1 and 2.9.1.0.x. See
|
|
@uref{http://sources.redhat.com/binutils/}, to obtain information on
|
|
how to get the latest version.
|
|
@end quotation
|
|
|
|
GRUB is available from the GNU alpha archive site
|
|
@uref{ftp://alpha.gnu.org/gnu/grub} or any of its mirrors. The file
|
|
will be named grub-version.tar.gz. The current version is
|
|
@value{VERSION}, so the file you should grab is:
|
|
|
|
@uref{ftp://alpha.gnu.org/gnu/grub/grub-@value{VERSION}.tar.gz}
|
|
|
|
To unbundle GRUB use the instruction:
|
|
|
|
@example
|
|
@kbd{zcat grub-@value{VERSION}.tar.gz | tar xvf -}
|
|
@end example
|
|
|
|
which will create a directory called @file{grub-@value{VERSION}} with
|
|
all the sources. You can look at the file @file{INSTALL} for detailed
|
|
instructions on how to build and install GRUB, but you should be able to
|
|
just do:
|
|
|
|
@example
|
|
@group
|
|
@kbd{cd grub-@value{VERSION}}
|
|
@kbd{./configure}
|
|
@kbd{make install}
|
|
@end group
|
|
@end example
|
|
|
|
Also, the latest version is available from the SVN. See
|
|
@uref{http://savannah.gnu.org/svn/?group=grub} for more information.
|
|
|
|
@node Reporting bugs
|
|
@appendix Reporting bugs
|
|
|
|
These are the guideline for how to report bugs. Take a look at this
|
|
list below before you submit bugs:
|
|
|
|
@enumerate
|
|
@item
|
|
Before getting unsettled, read this manual through and through. Also,
|
|
see the @uref{http://www.gnu.org/software/grub/grub-faq.html, GNU GRUB FAQ}.
|
|
|
|
@item
|
|
Always mention the information on your GRUB. The version number and the
|
|
configuration are quite important. If you build it yourself, write the
|
|
options specified to the configure script and your operating system,
|
|
including the versions of gcc and binutils.
|
|
|
|
@item
|
|
If you have trouble with the installation, inform us of how you
|
|
installed GRUB. Don't omit error messages, if any. Just @samp{GRUB hangs
|
|
up when it boots} is not enough.
|
|
|
|
The information on your hardware is also essential. These are especially
|
|
important: the geometries and the partition tables of your hard disk
|
|
drives and your BIOS.
|
|
|
|
@item
|
|
If GRUB cannot boot your operating system, write down
|
|
@emph{everything} you see on the screen. Don't paraphrase them, like
|
|
@samp{The foo OS crashes with GRUB, even though it can boot with the
|
|
bar boot loader just fine}. Mention the commands you executed, the
|
|
messages printed by them, and information on your operating system
|
|
including the version number.
|
|
|
|
@item
|
|
Explain what you wanted to do. It is very useful to know your purpose
|
|
and your wish, and how GRUB didn't satisfy you.
|
|
|
|
@item
|
|
If you can investigate the problem yourself, please do. That will give
|
|
you and us much more information on the problem. Attaching a patch is
|
|
even better.
|
|
|
|
When you attach a patch, make the patch in unified diff format, and
|
|
write ChangeLog entries. But, even when you make a patch, don't forget
|
|
to explain the problem, so that we can understand what your patch is
|
|
for.
|
|
|
|
@item
|
|
Write down anything that you think might be related. Please understand
|
|
that we often need to reproduce the same problem you encounterred in our
|
|
environment. So your information should be sufficient for us to do the
|
|
same thing---Don't forget that we cannot see your computer directly. If
|
|
you are not sure whether to state a fact or leave it out, state it!
|
|
Reporting too many things is much better than omitting something
|
|
important.
|
|
@end enumerate
|
|
|
|
If you follow the guideline above, submit a report to the
|
|
@uref{http://savannah.gnu.org/bugs/?group=grub, Bug Tracking System}.
|
|
Alternatively, you can submit a report via electronic mail to
|
|
@email{bug-grub@@gnu.org}, but we strongly recommend that you use the
|
|
Bug Tracking System, because e-mail can be passed over easily.
|
|
|
|
Once we get your report, we will try to fix the bugs.
|
|
|
|
|
|
@node Future
|
|
@appendix Where GRUB will go
|
|
|
|
We started the next generation of GRUB, GRUB 2. GRUB 2 includes
|
|
internationalization, dynamic module loading, real memory management,
|
|
multiple architecture support, a scripting language, and many other
|
|
nice feature. If you are interested in the development of GRUB 2, take
|
|
a look at @uref{http://www.gnu.org/software/grub/grub.html, the
|
|
homepage}.
|
|
|
|
|
|
|
|
@node Copying This Manual
|
|
@appendix Copying This Manual
|
|
|
|
@menu
|
|
* GNU Free Documentation License:: License for copying this manual.
|
|
@end menu
|
|
|
|
@include fdl.texi
|
|
|
|
|
|
@node Index
|
|
@unnumbered Index
|
|
|
|
@c Currently, we use only the Concept Index.
|
|
@printindex cp
|
|
|
|
|
|
@bye
|
|
|
|
Some notes:
|
|
|
|
This is an attempt to make a manual for GRUB 2. The contents are
|
|
copied from the GRUB manual in GRUB Legacy, so they are not always
|
|
appropriate yet for GRUB 2.
|