This page (revision-1) was last changed on 29-Nov-2024 16:16 by UnknownAuthor

Only authorized users are allowed to rename pages.

Only authorized users are allowed to delete pages.

Page revision history

Version Date Modified Size Author Changes ... Change note

Page References

Incoming links Outgoing links
Linux Boot Process
Linux Boot Process

Version management

Difference between version and

At line 1 added 90 lines
!!! Overview
[{$pagename}] 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]
For the PC platform, after the computer has been turned on, the [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 Loader]
The primary and secondary [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.
!! [Kernel] and initramfs
To pass system control, the [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).
!! [Master Boot Record]
The structure of the [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).
!!! [Booting with GRUB]
[GRUB (Grand Unified Bootloader)|Booting with GRUB] comprises two stages.
!! More Information
There might be more information for this subject on one of the following:
[{ReferringPagesPlugin before='*' after='\n' }]
This page (revision-1) was last changed on 29-Nov-2024 16:16 by UnknownAuthorTop