Overview#Linux Boot Process consists of several stages each represented by a different component.
The following list briefly summarizes the boot process and features all the major components involved. This discussion focus is on the Intel/PC platform to try to keep it simple.
System Startup#The system startup stage depends on the hardware that Linux is being booted on. On an embedded platform, a booting environment is used when the system is powered on, or reset. Examples include U-Boot, RedBoot, and MicroMonitor from Lucent. Embedded platforms are commonly shipped with a boot monitor. These programs reside in special region of flash memory on the target hardware and provide the means to download a Linux kernel image into flash memory and subsequently execute it. In addition to having the ability to store and boot a Linux image, these boot monitors perform some level of system test and hardware initialization. In an embedded target, these boot monitors commonly cover both the first- and second-stage Boot Loaders. BIOS initializes the screen and keyboard and tests the main memory. Up to this stage, the machine does not access any mass Storage devices. Subsequently, the information about the current date, time, and the most important peripherals are loaded from the CMOS values. When the first hard disk and its geometry are recognized, the system control passes from the BIOS to the Boot Loader. If the BIOS supports network Booting, it is also possible to configure a boot server that provides the Boot Loader. On x86 systems, PXE boot is needed. Other architectures commonly use the BOOTP protocol to get the Boot Loader. Boot Loaders combined are called Linux Loader (LILO) or GRand Unified Bootloader (GRUB) on the x86 PC environment.
Primary Boot Loader#The primary Boot Loader that resides in the MBR is a 512-byte image containing both program code and a small partition table. The first 446 bytes are the primary Boot Loader, which contains both executable code and error message text. The next sixty-four bytes are the partition table, which contains a record for each of four partitions (sixteen bytes each). The MBR ends with two bytes that are defined as the magic number (0xAA55). The magic number serves as a validation check of the MBR.
The first physical 512-byte data sector of the first hard disk is loaded into the main memory and the boot loader that resides at the beginning of the first physical 512-byte data sector of the first hard disk takes over. The commands executed by the Boot Loader determine the remaining part of the Booting process. Therefore, the first 512 bytes on the first hard disk are referred to as the Master Boot Record (MBR). The Boot Loader then passes control to the actual Operating System, in this case, the Linux kernel. More information about GRUB, the Linux boot loader. For a network boot, the BIOS acts as the Boot Loader. It gets the image to start from the boot server then starts the system. This is completely independent of local hard disks.
Secondary Boot Loader#The secondary, or second-stage, Boot Loader could be more aptly called the kernel loader. The task at this stage is to load the Linux kernel and optional initial RAM disk.
With stage 2 loaded, GRUB can, upon request, display a list of available kernels (defined in /etc/grub.conf, with soft links from /etc/grub/menu.lst and /etc/grub.conf). You can select a kernel and even amend it with additional kernel parameters. Optionally, you can use a Command-line shell for greater manual control over the boot process.
With the secondary Boot Loader in memory, the File System is consulted, and the default kernel image and initrd image are loaded into memory. With the images ready, the secondary boot loader invokes the default or selected kernel image.Boot Loader loads both the kernel and an initial RAM–based File System (initramfs) into memory. The contents of the initramfs can be used by the kernel directly. initramfs contains a small executable called init that handles the mounting of the real root File System. If special hardware drivers are needed before the mass storage can be accessed, they must be in initramfs.
If the system does not have a local hard disk, the initramfs must provide the root file system to the kernel. This can be done with the help of a network block device like iSCSI or SAN, but it is also possible to use NFS as the root device.
init on initramfs #This program performs all actions needed to mount the proper root File System, like providing kernel functionality for the needed File System and device drivers for mass storage controllers with udev. After the root file system has been found, it is checked for errors and mounted. If this has been successful, the initramfs is cleaned and the init program on the root file system is executed. For more information about init, refer to Section 7.1.2, “init on initramfs” (page 63). Find more information about udev in Chapter 11, Dynamic Kernel Device Management with udev (page 131).
init #init handles the actual booting of the system through several different levels providing different functionality. init is described in Section 7.2, “The init Process” (page 65). MBR is defined by an Operating System–independent convention. The first 446 bytes are reserved for the program code. They typically hold part of a Boot Loader program or an Operating System selector. The next 64 bytes provide space for a Disk partition table of up to four entries. The partition table contains information about the partitioning of the hard disk and the File System types. The operating system needs this table for handling the hard disk. With conventional generic code in the MBR, exactly one Disk partition must be marked active. The last two bytes of the MBR must contain a static "magic number" (AA55). An MBR containing a different value is regarded as invalid by some BIOSes, and is not considered for booting.
Boot Sectors#Boot sectors are the first sectors of each hard disk partitions with the exception of the extended partition, which merely serves as a "container" for other partitions. These boot sectors have 512 bytes of space for code used to boot an Operating System installed in the respective partition.
- Microsoft Windows - boot sectors of formatted MS-DOS, Microsoft Windows, and OS2 disk partitions, which also contain some basic important data of the File System.
- Linux - the boot sectors of Linux disk partitions are initially empty after setting up a File System other than XFS. Therefore, a Linux disk partitions is not bootable by itself, even if it contains a kernel and a valid root File System. A boot sector with valid code for booting the system has the same magic number as the MBR in its last two bytes (AA55).