Product SiteDocumentation Site

F.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 F.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 Appendix E, 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, ext3, and ext4 [8] partitions and load its configuration file — /boot/grub/grub.conf — at boot time. Refer to Section E.7, “GRUB Menu Configuration File” for information on how to edit this file.

Important — Supported file systems

The GRUB bootloader in Fedora 14 supports ext2, ext3, and ext4 file systems. It does not support other file systems such as VFAT, Btrfs or XFS. Furthermore, GRUB does not support LVM.


If upgrading the kernel using the Red Hat Update Agent, the boot loader configuration file is updated automatically. More information on Red Hat Network can be found online at the following URL:
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.
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 Appendix E, The GRUB Boot Loader. For information on changing the runlevel at the boot loader prompt, refer Section E.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 /sysroot/, 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 or ext4 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 Appendix E, The GRUB Boot Loader.

F.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 IBM eServer pSeries architecture uses yaboot, and the IBM System z systems use the z/IPL boot loader.
Consult the sections of this guide specific to these platforms for information on configuring their boot loaders.

[8] GRUB reads ext3 and ext4 file systems as ext2, disregarding the journal file.