228 lines
9.2 KiB
Text
228 lines
9.2 KiB
Text
|
|
|
|
Listing of commands available in the configuration files, a subset of
|
|
which is usable on the command-line.
|
|
|
|
The interpretation of the config file represents a simple state-machine,
|
|
where:
|
|
|
|
(1) Config-file specific commands have to be used before any others.
|
|
(2) A multiboot kernel must be loaded before modules can be.
|
|
(3) A kernel must be loaded before either the config-file entry ends,
|
|
or any "boot" command is issued in any case.
|
|
|
|
Semantics are as follows:
|
|
|
|
-- The files *must* be in plain-text format!!
|
|
|
|
-- "#" at the beginning of a line means it is a comment line in a config
|
|
file only.
|
|
|
|
-- Options are separated by spaces.
|
|
|
|
-- All numbers can be either decimal or hexidecimal. A hexidecimal number
|
|
must be preceeded by "0x", and is case insensitive.
|
|
|
|
-- Extra options/text at the end of the line is ignored unless otherwise
|
|
specified.
|
|
|
|
-- Bad commands generally get included in the current entry being added
|
|
to, except before entries start, where they are ignored.
|
|
|
|
|
|
Notes for interpreting commands described in double-quotes below:
|
|
|
|
-- "literal_string" : means use the string "literal_string".
|
|
-- "<name>" : means the whole name "<name>" represents some variable
|
|
quantity that is interpreted at runtime (like a number
|
|
or device/file name).
|
|
-- "[option]" : means "option" is may be omitted.
|
|
-- "..." : means extra text included at the end of the line is used for
|
|
some purpose.
|
|
|
|
|
|
Commands usable in config files only.
|
|
|
|
-- "timeout= <sec>"
|
|
Sets a timeout, in <sec> seconds, before automatically booting the
|
|
default entry (normally the first entry defined).
|
|
|
|
-- "default= <num>"
|
|
Sets the default entry to entry number <num> (otherwise it is 0,
|
|
the first entry).
|
|
|
|
-- "fallback= <num>"
|
|
Goes into unattended boot mode: if the default boot entry has any
|
|
errors, instead of waiting for the user to do anything, it
|
|
immediately starts over using the <num> entry (same numbering
|
|
as the "default=" command). This obviously doesn't help if the
|
|
machine was in the middle of the boot process (after leaving GRUBs
|
|
code) and rebooted.
|
|
|
|
-- "password= <passwd> <new_config_file>"
|
|
Disables all interactive editing control (menu entry editor
|
|
and command-line). If the password <passwd> is entered, it
|
|
loads the <new_config_file> as a new config file and restarts
|
|
the GRUB Stage 2.
|
|
|
|
-- "title= ..."
|
|
Starts a new menu entry, and sets it's name to the contents of the
|
|
rest of the line, starting with the first non-space character.
|
|
|
|
|
|
Commands usable in config files and interactively.
|
|
|
|
-- "pause= ..."
|
|
Prints the entirety of "pause= ..." to the end of it's line, then
|
|
waits until a key is pressed.
|
|
|
|
NOTE that placing a ^G in it will cause the speaker to emit the
|
|
standard beep sound, which is useful when asking the user to change
|
|
floppies, etc.
|
|
|
|
-- "uppermem= <kbytes>"
|
|
Forces GRUB to ignore what it found during the autoprobe of the
|
|
memory available to the system, and to use <kbytes> as the number
|
|
of kilobytes of upper memory installed. Any address range maps
|
|
of the system are discarded.
|
|
|
|
NOTE: This should be used with great caution, and should only
|
|
be necessary on some old machines. GRUB's BIOS probe can pick up
|
|
all RAM on all new machines the author has ever heard of. It can
|
|
also be used for debugging purposes to lie to an OS.
|
|
|
|
-- "root= <device> [<hdbias>]"
|
|
Sets the current "root partition" to the device <device>, then
|
|
attempts to mount it to get the partition size (for passing the
|
|
partition descriptor in ES:ESI, used by some chainloaded
|
|
bootloaders), the BSD drive-type (for booting BSD kernels using
|
|
their native boot format), and fixup automatic determination of
|
|
the PC partition where a BSD sub-partition is located. The optional
|
|
<hdbias> parameter is a number to tell a kernel which is using
|
|
one of the BSD boot methodologies how many BIOS drive numbers
|
|
are on controllers before the current one. An example is if there
|
|
is an IDE disk and a SCSI disk, then set the root partition
|
|
normally, except for a kernel using a BSD boot methodology
|
|
(FreeBSD or NetBSD), then use a "1" for <hdbias>.
|
|
|
|
-- "rootnoverify= <device> [<hdbias>]"
|
|
Similar to "root=", but doesn't attempt to mount the partition.
|
|
This is useful for when an OS is outside of the area of the disk
|
|
that GRUB can read, but setting the correct root partition is still
|
|
desired.
|
|
|
|
NOTE: the items mentioned in "root=" above which are derived from
|
|
attempting the mount will NOT work correctly.
|
|
|
|
-- "chainloader= <file>"
|
|
Loads <file> as a chainloader.
|
|
|
|
NOTE: 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 "+1".
|
|
|
|
-- "kernel= <file> ..."
|
|
Attempts to load the primary boot image (Multiboot a.out or ELF,
|
|
Linux zImage or bzImage, FreeBSD-a.out, or NetBSD-a.out) from
|
|
<file>. This command ignores the rest of the contents of the line,
|
|
except that the entire line starting with the kernel filename is
|
|
passed verbatim as the "kernel command-line". The module state is
|
|
reset by this (i.e. reload any modules).
|
|
|
|
-- "module= <file> ..."
|
|
Loads a boot module for a Multiboot format boot image (no
|
|
interpretation of the file contents are made, so the user of this
|
|
command/writer of the config file must know what the kernel in
|
|
question works with). The rest of the line is passed as the "module
|
|
command-line" much like with the "kernel=" command.
|
|
|
|
-- "modulenounzip= <file> ..."
|
|
Exactly like "module", except that automatic decompression is
|
|
disabled.
|
|
|
|
-- "initrd= <file> ..."
|
|
Loads an initial ramdisk for a Linux format boot image and sets
|
|
the appropriate parameters in the Linux setup area in memory.
|
|
|
|
-- "install= <stage1_file> [d] <dest_dev> <file> <addr> [p] [<config_file>]"
|
|
This command is fairly complex, and for detailed examples one
|
|
should look at the install documentation. In short, it will
|
|
perform a full install presuming the stage1.5 or stage2 (they're
|
|
loaded the same way, I'll just refer to it as a stage2 from now on)
|
|
is in it's final install location (pretty much all other edits are
|
|
performed by the "install=" command).
|
|
|
|
In slightly more detail, it will load <stage1_file>, validate
|
|
that it is a GRUB stage1 of the right version number, install
|
|
blocklists for loading <file> (if the option "d" is present,
|
|
the stage1 will always look for the actual disk <file> was
|
|
installed on, rather than using the booting drive) as a stage2
|
|
into memory at address <addr> (for a stage1.5, an address of
|
|
0x2000 should be used, and for a stage2, an address of 0x8000
|
|
should be used), then write the completed stage1 to the first
|
|
block of the device <dest_dev>. If the options "p" or <config_file>
|
|
are present, then it reads the first block of stage2, modifies it
|
|
with the values of the partition <file> was found on (for "p") or
|
|
places the string <config_file> into the area telling the stage2
|
|
where to look for a configuration file at boot time. Finally, it
|
|
preserves the DOS BPB (and for hard disks, the partition table) of
|
|
the sector the stage1 is to be installed into.
|
|
|
|
-- "makeactive"
|
|
Sets the active partition on the root disk to GRUB's root partition
|
|
(on a floppy this is a NO-OP). This is limited to working with
|
|
"primary" PC partitions.
|
|
|
|
-- "boot"
|
|
This boots the OS/chainloader which has been loaded. Only necessary
|
|
if running the fully interactive command-line (it is implicit at the
|
|
end of a config-file entry).
|
|
|
|
|
|
Commands usable in config files and interactively which are only available
|
|
in the debug version of the GRUB Stage 2.
|
|
|
|
-- "testload= <file>"
|
|
Reads the entire contents of <file> in several different ways and
|
|
compares them, to test the filesystem code. The output is somewhat
|
|
cryptic (see the "T" subcommand of "syscmd=" below), but if no
|
|
errors are reported and the part right at the end which reads
|
|
"i=<X>, filepos=<Y>" has <X> and <Y> equal, then it is definitely
|
|
consistent, and very likely works correctly subject to a consistent
|
|
offset error. A good idea if this works is then to try loading a
|
|
kernel with your code.
|
|
|
|
-- "read= <addr>"
|
|
Reads a 32-bit unsigned value at address <addr> and displays it
|
|
in hex format.
|
|
|
|
-- "displaymem"
|
|
Displays what GRUB thinks the system address space map of the
|
|
machine is, including all regions of physical RAM installed.
|
|
The "upper/lower memory" thing GRUB has uses the standard BIOS
|
|
interface for the available memory in the first megabyte, or
|
|
"lower memory", and a synthesized number from various BIOS
|
|
interfaces of the memory starting at 1MB and going up to the first
|
|
chipset hole for "upper memory" (the standard PC "upper memory"
|
|
interface is limited to reporting a maximum of 64MB).
|
|
|
|
-- "impsprobe"
|
|
Probes Intel MPS spec 1.1 or 1.4 configuration table and boots
|
|
the various other CPUs which are found into a tight loop.
|
|
|
|
-- "fstest"
|
|
Toggles filesystem test mode.
|
|
|
|
Filesytem test mode, when turned on, prints out data corresponding
|
|
to all the device reads and what values are being sent to the
|
|
low-level routines. The format is:
|
|
|
|
"<sector, byte_offset, byte_len>" for high-level reads
|
|
inside a partition (so "sector" is an offset from
|
|
the start of the partition).
|
|
"[sector]" for low-level sector requests from the disk
|
|
(so "sector" is offset from the start of the disk).
|
|
|
|
Filesystem test mode is turned off by any uses of the "install=" or
|
|
"testload=" commands.
|
|
|