Ce contenu n'est pas disponible dans la langue sélectionnée.
1.2.2. The Boot Loader
This section looks at the default boot loader for the x86 platform, GRUB. Depending on the system's architecture, the boot process may differ slightly. Refer to Section 1.2.2.1, “Boot Loaders for Other Architectures” for a brief overview of non-x86 boot loaders. For more information about configuring and using GRUB, see Chapter 2, The GRUB Boot Loader.
A boot loader for the x86 platform is broken into at least two stages. The first stage is a small machine code binary on the MBR. Its sole job is to locate the second stage boot loader and load the first part of it into memory.
GRUB has the advantage of being able to read ext2 and ext3 [1] partitions and load its configuration file —
/boot/grub/grub.conf — at boot time. Refer to Section 2.7, “GRUB Menu Configuration File” for information on how to edit this file.
Note
If upgrading the kernel using the Red Hat User Agent, the boot loader configuration file is updated automatically. More information on Red Hat Network can be found online at the following URL: https://rhn.redhat.com/.
Once the second stage boot loader is in memory, it presents the user with a graphical screen showing the different operating systems or kernels it has been configured to boot. On this screen a user can use the arrow keys to choose which operating system or kernel they wish to boot and press Enter. If no key is pressed, the boot loader loads the default selection after a configurable period of time has passed.
Note
If Symmetric Multi-Processor (SMP) kernel support is installed, more than one option is presented the first time the system is booted. In this situation GRUB displays
Red Hat Enterprise Linux (<kernel-version>-smp), which is the SMP kernel, and Red Hat Enterprise Linux (<kernel-version>), which is for single processors.
If any problems occur using the SMP kernel, try selecting the a non-SMP kernel upon rebooting.
Once the second stage boot loader has determined which kernel to boot, it locates the corresponding kernel binary in the
/boot/ directory. The kernel binary is named using the following format — /boot/vmlinuz-<kernel-version> file (where <kernel-version> corresponds to the kernel version specified in the boot loader's settings).
For instructions on using the boot loader to supply command line arguments to the kernel, refer to Chapter 2, The GRUB Boot Loader. For information on changing the runlevel at the boot loader prompt, refer Section 2.8, “Changing Runlevels at Boot Time”.
The boot loader then places one or more appropriate initramfs images into memory. Next, the kernel decompresses these images from memory to
/boot/, a RAM-based virtual file system, via cpio. The initramfs is used by the kernel to load drivers and modules necessary to boot the system. This is particularly important if SCSI hard drives are present or if the systems use the ext3 file system.
Once the kernel and the
initramfs image(s) are loaded into memory, the boot loader hands control of the boot process to the kernel.
For a more detailed overview of the GRUB boot loader, refer to Chapter 2, The GRUB Boot Loader.
1.2.2.1. Boot Loaders for Other Architectures
Once the kernel loads and hands off the boot process to the
init command, the same sequence of events occurs on every architecture. So the main difference between each architecture's boot process is in the application used to find and load the kernel.
For example, the Itanium architecture uses the ELILO boot loader, the IBM eServer pSeries architecture uses YABOOT, and the IBM eServer zSeries and IBM S/390 systems use the z/IPL boot loader.
Consult the Installation Guide specific to these platforms for information on configuring their boot loaders.
[1]
GRUB reads ext3 file systems as ext2, disregarding the journal file. Refer to the chapter titled The ext3 File System in the System Administrators Guide for more information on the ext3 file system.
