The six stages of linux boot process
1. BIOS Basic Input/Output System executes MBR
2. MBR Master Boot Record executes GRUB
3. GRUB Grand Unified Bootloader executes Kernel
4. Kernel Kernel executes /sbin/init
5. Init Init executes runlevel programs
6. Runlevel Runlevel programs are executed from /etc/rc.d/rc*.d/
3. GRUB Grand Unified Bootloader executes Kernel
4. Kernel Kernel executes /sbin/init
5. Init Init executes runlevel programs
6. Runlevel Runlevel programs are executed from /etc/rc.d/rc*.d/
1. BIOS
When the PC is powered up, the BIOS is the first program that runs which is stored in flash memory on the motherboard. The BIOS contains the following parts:
POST (Power On Self Test): The principal duties of the main BIOS during POST are as follows:
Verify CPU registers, verify the integrity of the BIOS code itself, verify some basic components like DMA, timer, interrupt controller, find, size, and verify system main memory, initialize BIOS, discover, initialize, and catalog all system buses and devices, pass control to other specialized BIOSes (if and when required), provide a user interface for system's configuration, identify, organize, and select which devices are available for booting construct whatever system environment that is required by the target operating system.
When the PC is powered up, the BIOS is the first program that runs which is stored in flash memory on the motherboard. The BIOS contains the following parts:
POST (Power On Self Test): The principal duties of the main BIOS during POST are as follows:
Verify CPU registers, verify the integrity of the BIOS code itself, verify some basic components like DMA, timer, interrupt controller, find, size, and verify system main memory, initialize BIOS, discover, initialize, and catalog all system buses and devices, pass control to other specialized BIOSes (if and when required), provide a user interface for system's configuration, identify, organize, and select which devices are available for booting construct whatever system environment that is required by the target operating system.
The Setup Menu: That lets you set some parameters and lets you adjust the real time clock. Most modern BIOS versions let you set the boot order, the devices that BIOS checks for booting. These can be A (the first floppy disk), C (the first hard disk), CD-ROM and possibly other disks as well. The first device in the list will be tried first.
The boot sector loader: This loads the first 512-byte sector from the boot disk into RAM and jumps to it.
The BIOS interrupts: These are simple device drivers that programs can use to access the screen, the keyboard and disks. Boot loaders rely on them, most operating systems do not (the Linux kernel does not use BIOS interrupts once it has been started). MSDOS does use BIOS interrupts.
2. MBR
When a computer boots, the BIOS transfers control to the first boot device, which is hard disk.The first sector on a hard disk is called the Master Boot Record. 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 64 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 job of the primary boot loader is to find and load the secondary boot loader. It does this by looking through the partition table for an active partition. When it finds an active partition, it scans the remaining partitions in the table to ensure that they're all inactive. When this is verified, the active partition's boot record is read from the device into RAM and executed.
By default, MBR code looks for the partition marked as active and once such a partition is found, it loads its boot sector into memory and passes control to it.
3. GRUB
GNU GRUB is a bootloader capable of loading a variety of free and proprietary operating systems. GRUB will work well with Linux, DOS, Windows, or BSD.
GRUB is dynamically configurable. This means that the user can make changes during the boot time, which include altering existing boot entries, adding new, custom entries, selecting different kernels, or modifying initrd. GRUB also supports Logical Block Address mode. This means that if your computer has a fairly modern BIOS that can access more than 8GB (first 1024 cylinders) of hard disk space, GRUB will automatically be able to access all of it.
GRUB can be run from or be installed to any device (floppy disk, hard disk, CD-ROM, USB drive, network drive) and can load operating systems from just as many locations, including network drives. It can also decompress operating system images before booting them.
GNU GRUB is a bootloader capable of loading a variety of free and proprietary operating systems. GRUB will work well with Linux, DOS, Windows, or BSD.
GRUB is dynamically configurable. This means that the user can make changes during the boot time, which include altering existing boot entries, adding new, custom entries, selecting different kernels, or modifying initrd. GRUB also supports Logical Block Address mode. This means that if your computer has a fairly modern BIOS that can access more than 8GB (first 1024 cylinders) of hard disk space, GRUB will automatically be able to access all of it.
GRUB can be run from or be installed to any device (floppy disk, hard disk, CD-ROM, USB drive, network drive) and can load operating systems from just as many locations, including network drives. It can also decompress operating system images before booting them.
LILO (Linux bootloader)
LILO is another Linux bootloader.
Advantage of GRUB over LILO
LILO supports only up to 16 different boot selections; GRUB supports an unlimited number of boot entries.
LILO cannot boot from network; GRUB can.
LILO must be written again every time you change the configuration file; GRUB does not.
LILO does not have an interactive command interface.
LILO is another Linux bootloader.
Advantage of GRUB over LILO
LILO supports only up to 16 different boot selections; GRUB supports an unlimited number of boot entries.
LILO cannot boot from network; GRUB can.
LILO must be written again every time you change the configuration file; GRUB does not.
LILO does not have an interactive command interface.
GRUB replaces the default MBR with its own code.
Furthermore, GRUB works in stages.
Stage 1 is located in the MBR and mainly points to Stage 2, since the MBR is too small to contain all of the needed data.Stage 1 can do little more than load the next stage of GRUB by loading a few disk sectors from a fixed location near the start of the disk (within 1024 cylinders).
Stage 2 points to its configuration file, which contains all of the complex user interface and options we are normally familiar with when talking about GRUB. Stage 2 can be located anywhere on the disk. If Stage 2 cannot find its configuration table, GRUB will cease the boot sequence and present the user with a command line for manual configuration.
Stage 1.5 also exists and might be used if the boot information is small enough to fit in the area immediately after MBR. Stage1.5 is located in the first 30 kilobytes of hard disk immediately following the MBR and before the first partition. If this space is not available (Unusual partition table, special disk drivers, GPT or LVM disk) the install of Stage 1.5 will fail. The stage 1.5 image contains filesystem specific drivers. This enables stage 1.5 to directly load stage 2 from a known location in the filesystem, for example from /boot/grub. Stage 2 will then load the default configuration file and any other modules needed
The Stage architecture allows GRUB to be large (~20-30K) and therefore fairly complex and highly configurable, compared to most bootloaders, which are sparse and simple to fit within the limitations of the Partition Table.
After loading GRUB, but before the operating system starts
Once GRUB has loaded, it presents an interface where the user can select which operating system to boot. This normally takes the form of a graphical menu. If this is not available, or the user wishes direct control, GRUB has its own command prompt. The user can then manually specify the boot parameters. GRUB can be set to automatically load a specified kernel after a user defined timeout.
Perhaps the most important commands that GRUB accepts in the operating system selection (kernel selection) menu are the following two commands.
By pressing 'e', it is possible to edit parameters for the selected operating system before the operating system is started. Typically, this is used for changing kernel parameters for a Linux system. The reason for doing this in GRUB (i.e. not editing the parameters in an already booted system) can be an emergency case: the system has failed to boot. Using the kernel parameters line it is possible, among other things, to specify a module to be disabled (blacklisted) for the kernel. This could be needed, if the specific kernel module is broken and thus prevents boot-up.
By pressing 'c', the user enters the GRUB command line. This is not a regular Linux shell. It accepts certain GRUB-specific commands.
Once boot options have been selected, GRUB loads the selected kernel into memory and passes control to the kernel. Alternatively, GRUB can pass control of the boot process to another loader, using chain loading. This is the method used to load operating systems such as Windows, that do not support the Multiboot standard or are not supported directly by GRUB. In this case, copies of the other system's boot programs have been saved by GRUB. Instead of a kernel, the other system is loaded as though it had been started from the MBR. This could be another boot manager, such as the Microsoft boot menu, allowing further selection of non-Multiboot operating systems.
With the second-stage 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 stage 2 boot loader invokes the kernel image.
4. Kernel
With the kernel image in memory and control given from the stage 2 boot loader, the kernel stage begins. The kernel image isn't so much an executable kernel, but a compressed kernel image. Typically this is a zImage (compressed image, less than 512KB) or a bzImage (big compressed image, greater than 512KB), that has been previously compressed with zlib. At the head of this kernel image is a routine that does some minimal amount of hardware setup and then decompresses the kernel contained within the kernel image and places it into high memory. If an initial RAM disk image is present, this routine moves it into memory and notes it for later use. The routine then calls the kernel and the kernel boot begins.
Furthermore, GRUB works in stages.
Stage 1 is located in the MBR and mainly points to Stage 2, since the MBR is too small to contain all of the needed data.Stage 1 can do little more than load the next stage of GRUB by loading a few disk sectors from a fixed location near the start of the disk (within 1024 cylinders).
Stage 2 points to its configuration file, which contains all of the complex user interface and options we are normally familiar with when talking about GRUB. Stage 2 can be located anywhere on the disk. If Stage 2 cannot find its configuration table, GRUB will cease the boot sequence and present the user with a command line for manual configuration.
Stage 1.5 also exists and might be used if the boot information is small enough to fit in the area immediately after MBR. Stage1.5 is located in the first 30 kilobytes of hard disk immediately following the MBR and before the first partition. If this space is not available (Unusual partition table, special disk drivers, GPT or LVM disk) the install of Stage 1.5 will fail. The stage 1.5 image contains filesystem specific drivers. This enables stage 1.5 to directly load stage 2 from a known location in the filesystem, for example from /boot/grub. Stage 2 will then load the default configuration file and any other modules needed
The Stage architecture allows GRUB to be large (~20-30K) and therefore fairly complex and highly configurable, compared to most bootloaders, which are sparse and simple to fit within the limitations of the Partition Table.
After loading GRUB, but before the operating system starts
Once GRUB has loaded, it presents an interface where the user can select which operating system to boot. This normally takes the form of a graphical menu. If this is not available, or the user wishes direct control, GRUB has its own command prompt. The user can then manually specify the boot parameters. GRUB can be set to automatically load a specified kernel after a user defined timeout.
Perhaps the most important commands that GRUB accepts in the operating system selection (kernel selection) menu are the following two commands.
By pressing 'e', it is possible to edit parameters for the selected operating system before the operating system is started. Typically, this is used for changing kernel parameters for a Linux system. The reason for doing this in GRUB (i.e. not editing the parameters in an already booted system) can be an emergency case: the system has failed to boot. Using the kernel parameters line it is possible, among other things, to specify a module to be disabled (blacklisted) for the kernel. This could be needed, if the specific kernel module is broken and thus prevents boot-up.
By pressing 'c', the user enters the GRUB command line. This is not a regular Linux shell. It accepts certain GRUB-specific commands.
Once boot options have been selected, GRUB loads the selected kernel into memory and passes control to the kernel. Alternatively, GRUB can pass control of the boot process to another loader, using chain loading. This is the method used to load operating systems such as Windows, that do not support the Multiboot standard or are not supported directly by GRUB. In this case, copies of the other system's boot programs have been saved by GRUB. Instead of a kernel, the other system is loaded as though it had been started from the MBR. This could be another boot manager, such as the Microsoft boot menu, allowing further selection of non-Multiboot operating systems.
With the second-stage 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 stage 2 boot loader invokes the kernel image.
4. Kernel
With the kernel image in memory and control given from the stage 2 boot loader, the kernel stage begins. The kernel image isn't so much an executable kernel, but a compressed kernel image. Typically this is a zImage (compressed image, less than 512KB) or a bzImage (big compressed image, greater than 512KB), that has been previously compressed with zlib. At the head of this kernel image is a routine that does some minimal amount of hardware setup and then decompresses the kernel contained within the kernel image and places it into high memory. If an initial RAM disk image is present, this routine moves it into memory and notes it for later use. The routine then calls the kernel and the kernel boot begins.
5. Init
After the kernel is booted and initialized, the kernel starts the first user-space application. This is the first program invoked that is compiled with the standard C library. Prior to this point in the process, no standard C applications have been executed.
6. Runlevel
The term runlevel refers to a mode of operation in one of the computer operating systems.Conventionally, seven runlevels exist, numbered from zero to six.The exact setup of these configurations will vary from OS to OS, and from one Linux distribution to another.
Some important files and definitions.
1. /etc/rc.d/rc.sysinit - script to initialize the system(includes mounting local filesystems)
2. /etc/inittab - file containing default runlevel
3. /etc/init/start-ttys.conf - starts 5 or 6 text based virtual consoles
4. /etc/init/rc.conf - init job responsible for starting System V based services
5. /boot/grub/grub.conf - contains bootloader configuration instructions
6. /etc/init/ - directory containing init jobs
7. /etc/rc.d/rc5.d/ - contains links to System V services scripts to be started or stopped when entering runlevel5
8. /etc/init/prefdm.conf - starts graphical loging prompt
9. /etc/init/rc.S.conf - init job to run system initialization script and spawn job to start System V services.
No comments:
Post a Comment