Linux Boot process

a.  System startup / Hardware initialization / BIOS running post

When you power ON a Linux machine, electricity power is supplied to all the devices in that machine.  Motherboard, hard disks, CD/DVD-Drive, mouse, keyboard, monitor, etc.  The most intelligent device in the machine is the CPU (Central Processing Unit).  The first instructions run are from the BIOS PROM, (Basic Input Output System).  The BIOS does the following:

• Runs the POST i.e. Power On Self Test
• Selects the first boot device in the Boot device list in the CMOS to run an Operating System

POST:  The Power On Self Test is a set of processes to check the availability of hardware.  The BIOS will send an electrical signal to each and every device in its list to check for hardware.  If a device responds with an electrical signal then the BIOS treats it as a device that is working fine and available for use.  If no response is obtained by the BIOS from the device that device is treated as faulty and is removed from the system configuration from the BIOS point of view.  After the boot process, if any new hardware is added to the machine the hardware is added into the BIOS device list and will be checked on the next reboot.

Selecting the boot device:  Once the Power On Self Test is done, the BIOS will have a list of devices available.  The BIOS checks for the first boot device in the list and try to boot the machine from that device, and hand over control to the CPU.  If that boot device fails to respond, the second boot device will be chosen for the machine boot, and so on until the machine is booted into the Operating System.  IF ultimately no boot device takes over you get an error message: "No boot device found".

b.  Boot loader Stage 1 / Master Boot Record

Once the BIOS hands over control to the CPU, the CPU will try to load the Master Boot Record from the first boot device (which is almost always a hard disk).  The MBR i.e. the Master Boot Record which is of a very insignificant size, a mere 512 bytes, resides usually at the first sector of the boot disk.  It has the following three pieces in it:

• Primary boot loader code of 446 bytes:  This code provides the boot loader information and the locational details of the actual boot loader code on the hard disk.  This helps the CPU to load the second stage of the boot loader.
• Partition table information of 64 bytes: This is the partition table information which contains details of the starting and ending of each partition, size of partition and type of partition.  HDD supports only 4 partitions since the limitation is that with each partition information taking up 16 bytes, only 4 can be accommodated in these 64 bytes.
• Magic number 2 bytes: The magic number service serves as the validation check for the Master Boot Record.  If the MBR gets corrupted the magic number is used for retrieving it.
  
  Once the CPU gets all these details it will try to analyze them and read the first portion of the Master Boot Record to load the second stage of the boot loader.

c.  Boot loader Stage 2 / GRUB loader

Once the Bootloader stage 1 is done and able to find the actual boot loader location, stage 1 boot loader starts the second stage by loading the boot loader into memory.  In this second stage of boot loading the GRUB i.e. Grand Unified Boot Loader image, which is located within the first 30 kilobytes of the hard disk immediately after the Master Boot Record, is loaded into RAM for reading its configuration and displays the GRUB boot menu. 
GRUB loads the user-selected kernel into memory and passes control to the kernel.  If the user does not explicitly choose a kernel within about 15 seconds, the GRUB will load the default kernel into memory.

d.  Linux Operating System / Kernel

The kernel takes over the control of the machine.  The kernel acts as the layer between the hardware and the Operating system, and acts as the medium between the users and the hardware functionalities.  Once the kernel is loaded into RAM it stays there right through the uptime of the machine.  Only when the system is powered down will the kernel die.  Once the kernel is in operation it executes the "init" process.

e.  Run levels / init process

The init process is the primary process and is the ultimate parent of all processes which run under Linux.  The init process always has a Process ID i.e. PID of 1, no exception.  The first process it runs is a script under /etc/rc.d/rc.sysinit which check all the system properties, hardware, display, load kernel modules, file system check, file system mounting, etc.  Based on the appropriate run-level, scripts are executed to start various processes in the Operating system and make the system functional.  The init process spawns the /etc/inittab file, looks for the number preceding the "initdefault" parameter which boots the system into the specified run-level.  Various scripts are started based on the appropriate run-level and are taken from the following directories:

/etc/rc0.d/S<N1> to S<N999>        which refer to startup scripts run in run-level 0 and are executed in an order from N1 to N999
/etc/rc1.d/S<N1> to S<N999>    for run-level 1
/etc/rc2.d/S<N1> to S<N999>    for run-level 2,   and so on until run-level 6.

After the run-level specified in the initdefault parameter in the /etc/inittab file is in effect, the init process runs one last script, the /etc/rc.local and returns the machine control to the kernel.

f.  User prompt / Ready to accept login

Once the kernel gets back the control over the Operating system, it starts multiple instances of the getty process.  The getty process waits for console login and at the same time users are able to login over the network and start using the machine.