Linux Boot Process

The linux boot process can be divided in the following steps:

1) System Start up(BIOS/Boot Monitor)
2) Stage 1 Bootloader (MBR)
3) Stage 2 Bootloader (LILO, GRUB etc)
4) Kernel (Linux)
5) Init (User-Space)


1) System Start Up 

The process of system start up depends on the hardware on which the Linux is being booted. Booting process starts in the BIOS at the address 0xFFFF0. 

There are two sub-components of BIOS: 

                                                                       a) POST code

                                                                        b) Runtime Services

First the POST code check the hardware (RAM, CPUs,Video Card, Hard Drive and other Mother Board Components). After the POST is done it is flushed from the memory. But the runtime services remain there and searches for devices that are both active and bootable and it searches in order of the preference defined by CMOS(Complimentary Metal Oxide Semiconductor) settings.  MBR which resides in the HDD contains the primary bootloader getting loaded in the RAM and then BIOS yields the control to it.

3) MBR: 
Master Boot Recorder is of 512 bytes where the first 446 bytes contains the information of the boot loaded, the next 64 bytes contains the information of the
partition tables and the last 2 bytes are used for the validation check of the MBR. MBR which has the information of the primary boot loader i.e. GRUB load and executes the GRUB.

4) Kernel

Kernel image which get loaded is in compressed form. At the head of this kernel image there is routine that does some hardware set up and then decompressed the kernel and place it in the high memory. If initrd is present this routine moves the initrd in to memory and notes it for later use. The routine then calls the kernel and  kernel boot begins. During the boot of the kernel, the initial RAM disk that is loaded in to the memory is copied in to the memory and then mounted. The initrd serves as a temporary root file system in RAM and allows the kernel to fully boot without having to mount any physical hard disk.  Since the necessary modules needed to interface with peripherals can be part of the initrd, the kernel can be very small, but still support a large number of possible hardware configurations. After the kernel is booted, the root file system is pivoted (via pivot_root) where the initrd root file system is unmounted and the real root file system is mounted.

The initrd function allows you to create a small Linux kernel with drivers compiled as loadable modules. These loadable modules give the kernel the means to access disks and the file systems on those disks, as well as drivers for other hardware assets. Because the root file system is a file system on a disk, the initrd function provides a means of bootstrapping to gain access to the disk and mount the real root file system. In an embedded target without a hard disk, the initrd can be the final root file system, or the final root file system can be mounted via the Network File System (NFS).

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.Init is the first process running on your system. It reads the /etc/inittab file, executes /etc/rc.d/rc.sysinit, then boots into the runlevel as defined in /etc/inittab.

Init starts out with a Process ID (PID) of 1. In the image above, there's a line saying "INIT: version 2.86 booting"; this is /sbin/init taking over at this point in the boot process. On the line right after that one, you see the messages being displayed by the /etc/rc.d/rc.sysinit shell script; as a matter of fact, the entire screen contains messages from that script, so you can get an idea of some of the functions it performs. Init will also normally start several instances of /sbin/getty or /sbin/mingetty, which are your virtual terminals. This is why you can hit <Ctrl> + <Alt> + < F1> through <F6> and come up with a virtual terminal.

Depending on what Init is doing, you may see typical Init script verification messages getting printed to the screen, i.e., [ OK ] or [Failed] to aid in troubleshooting. You may see a message like "Press 'I' to enter interactive startup" (on Red Hat-based systems); this is an indication of rc.sysinit executing, and allows the operator a certain level of control over the still-booting system. rc.sysinit ends with your default runlevel (as defined in /etc/inittab) being started. This is another common place for errors, because servers will usually have the "id:5:initdefault:" line set to 3, so the machine boots to runlevel 3 instead of runlevel 5. Another common place for errors is the line pertaining to "ca::ctrlaltdel:/sbin/shutdown -t3 -r now" commented out to prevent the 3-finger salute (<Ctrl> + <Alt> + <Del>) from restarting the server. People are human and make mistakes; I have seen typographical errors in both places that can cause problems. Unlike the "mount -a" command, which will alert you if errors exist in your mount points in the /etc/fstab file, executing the command "init q" will reread your /etc/inittab, but will not check for errors in the runlevels themselves; the best way to know if errors exist is to learn this file and to be very, very careful if you decide to modify any of the /etc/rc*/* files.

When you enter your runlevel, you will see further Init messages being printed to the screen (depending if your machine is configured to do so), again ending with a [ OK ] or [Failed] depending on whether it started successfully or not. These are your startup services within your runlevels. When you look at your /etc/inittab file, you will see a line like "id:5:initdefault:"; this is your default runlevel. The default runlevel on most servers will be set to 3; on desktops, of course, it's set to 5, so we can have an X Window System session start as soon as the system boots up.

To get an overview of what processes get started or stopped for any particular runlevel, we should look within the /etc/rcX.d (where X is your runlevel) directory. Inside these directories, you will see symbolic links to the files in your /etc/init.d/ directory. The file names will be prefixed with either a 'K' or an 'S' (signifying kill or start) for the given daemon at that runlevel. The number immediately after the letter positions the script in the start order, because the processes are started alphabetically. With Red Hat-based systems, the "chkconfig" command will alter the symbolic links to start or stop the daemon in a desired runlevel; the 'S' or 'K' will change appropriately and the number will most likely change as well.