114 lines
4.8 KiB
Text
114 lines
4.8 KiB
Text
|
11 GRUB image files
|
||
|
|
*******************
|
||
|
|
|
||
|
|
GRUB consists of several images: a variety of bootstrap images for
|
||
|
|
starting GRUB in various ways, a kernel image, and a set of modules
|
||
|
|
which are combined with the kernel image to form a core image. Here is
|
||
|
|
a short overview of them.
|
||
|
|
|
||
|
|
'boot.img'
|
||
|
|
On PC BIOS systems, this image is the first part of GRUB to start.
|
||
|
|
It is written to a master boot record (MBR) or to the boot sector
|
||
|
|
of a partition. Because a PC boot sector is 512 bytes, the size of
|
||
|
|
this image is exactly 512 bytes.
|
||
|
|
|
||
|
|
The sole function of 'boot.img' is to read the first sector of the
|
||
|
|
core image from a local disk and jump to it. Because of the size
|
||
|
|
restriction, 'boot.img' cannot understand any file system
|
||
|
|
structure, so 'grub-install' hardcodes the location of the first
|
||
|
|
sector of the core image into 'boot.img' when installing GRUB.
|
||
|
|
|
||
|
|
'diskboot.img'
|
||
|
|
This image is used as the first sector of the core image when
|
||
|
|
booting from a hard disk. It reads the rest of the core image into
|
||
|
|
memory and starts the kernel. Since file system handling is not
|
||
|
|
yet available, it encodes the location of the core image using a
|
||
|
|
block list format.
|
||
|
|
|
||
|
|
'cdboot.img'
|
||
|
|
This image is used as the first sector of the core image when
|
||
|
|
booting from a CD-ROM drive. It performs a similar function to
|
||
|
|
'diskboot.img'.
|
||
|
|
|
||
|
|
'pxeboot.img'
|
||
|
|
This image is used as the start of the core image when booting from
|
||
|
|
the network using PXE. *Note Network::.
|
||
|
|
|
||
|
|
'lnxboot.img'
|
||
|
|
This image may be placed at the start of the core image in order to
|
||
|
|
make GRUB look enough like a Linux kernel that it can be booted by
|
||
|
|
LILO using an 'image=' section.
|
||
|
|
|
||
|
|
'kernel.img'
|
||
|
|
This image contains GRUB's basic run-time facilities: frameworks
|
||
|
|
for device and file handling, environment variables, the rescue
|
||
|
|
mode command-line parser, and so on. It is rarely used directly,
|
||
|
|
but is built into all core images.
|
||
|
|
|
||
|
|
'core.img'
|
||
|
|
This is the core image of GRUB. It is built dynamically from the
|
||
|
|
kernel image and an arbitrary list of modules by the 'grub-mkimage'
|
||
|
|
program. Usually, it contains enough modules to access
|
||
|
|
'/boot/grub', and loads everything else (including menu handling,
|
||
|
|
the ability to load target operating systems, and so on) from the
|
||
|
|
file system at run-time. The modular design allows the core image
|
||
|
|
to be kept small, since the areas of disk where it must be
|
||
|
|
installed are often as small as 32KB.
|
||
|
|
|
||
|
|
*Note BIOS installation::, for details on where the core image can
|
||
|
|
be installed on PC systems.
|
||
|
|
|
||
|
|
'*.mod'
|
||
|
|
Everything else in GRUB resides in dynamically loadable modules.
|
||
|
|
These are often loaded automatically, or built into the core image
|
||
|
|
if they are essential, but may also be loaded manually using the
|
||
|
|
'insmod' command (*note insmod::).
|
||
|
|
|
||
|
|
For GRUB Legacy users
|
||
|
|
=====================
|
||
|
|
|
||
|
|
GRUB 2 has a different design from GRUB Legacy, and so correspondences
|
||
|
|
with the images it used cannot be exact. Nevertheless, GRUB Legacy
|
||
|
|
users often ask questions in the terms they are familiar with, and so
|
||
|
|
here is a brief guide to how GRUB 2's images relate to that.
|
||
|
|
|
||
|
|
'stage1'
|
||
|
|
Stage 1 from GRUB Legacy was very similar to 'boot.img' in GRUB 2,
|
||
|
|
and they serve the same function.
|
||
|
|
|
||
|
|
'*_stage1_5'
|
||
|
|
In GRUB Legacy, Stage 1.5's function was to include enough
|
||
|
|
filesystem code to allow the much larger Stage 2 to be read from an
|
||
|
|
ordinary filesystem. In this respect, its function was similar to
|
||
|
|
'core.img' in GRUB 2. However, 'core.img' is much more capable
|
||
|
|
than Stage 1.5 was; since it offers a rescue shell, it is sometimes
|
||
|
|
possible to recover manually in the event that it is unable to load
|
||
|
|
any other modules, for example if partition numbers have changed.
|
||
|
|
'core.img' is built in a more flexible way, allowing GRUB 2 to
|
||
|
|
support reading modules from advanced disk types such as LVM and
|
||
|
|
RAID.
|
||
|
|
|
||
|
|
GRUB Legacy could run with only Stage 1 and Stage 2 in some limited
|
||
|
|
configurations, while GRUB 2 requires 'core.img' and cannot work
|
||
|
|
without it.
|
||
|
|
|
||
|
|
'stage2'
|
||
|
|
GRUB 2 has no single Stage 2 image. Instead, it loads modules from
|
||
|
|
'/boot/grub' at run-time.
|
||
|
|
|
||
|
|
'stage2_eltorito'
|
||
|
|
In GRUB 2, images for booting from CD-ROM drives are now
|
||
|
|
constructed using 'cdboot.img' and 'core.img', making sure that the
|
||
|
|
core image contains the 'iso9660' module. It is usually best to
|
||
|
|
use the 'grub-mkrescue' program for this.
|
||
|
|
|
||
|
|
'nbgrub'
|
||
|
|
There is as yet no equivalent for 'nbgrub' in GRUB 2; it was used
|
||
|
|
by Etherboot and some other network boot loaders.
|
||
|
|
|
||
|
|
'pxegrub'
|
||
|
|
In GRUB 2, images for PXE network booting are now constructed using
|
||
|
|
'pxeboot.img' and 'core.img', making sure that the core image
|
||
|
|
contains the 'pxe' and 'pxecmd' modules. *Note Network::.
|
||
|
|
|