The Booting process starts when the system/machine power is switched “On”.
————————
Stage 1
————————
The processor will execute the codes contained in BIOS[basic input and output system]. The BIOS is actually a program stored in ROM [Read only memory].
——
The processor runs the instruction located at the memory location CS:IP FFFF:0000 of the BIOS, which is located at the 0xFFFF0 address. This memory location is close to the end of the 1MB of system memory accessible in real mode. It typically contains a jump instruction that transfers execution to the location of the BIOS start-up program.
——
The BIOS will next run POST[power on self test] to find certain hardware and its working at the basic level. It compares the hardware settings in the CMOS (Complementary Metal Oxide Semiconductor) to what is physically on the system. It then initializes the hardware devices.
Once the POST is completed, the processor jumps to a specific, predefined location in RAM. The instructions located here are relatively simple and basically tell the hardware to go look for a boot device.
The BIOS goes through a pre-configured list of non-volatile storage devices (“boot device sequence”) until it finds one that is bootable [Depending on how your CMOS is configured]. A bootable device is defined as one that can be read from, and the last two bytes of the first sector contain the word 0xAA55 (also known as the boot signature).
When a boot device is found (let’s assume that it’s a hard disk), the hardware is told to go to the 0th (first) sector (cylinder 0, head 0, sector 0), then load and execute the instructions there. This is the master boot record, or MBR .
——
The conventional MBR code checks the MBR’s partition table for a partition set as bootable (the one with active flag set)[12]. If an active partition is found, the MBR code loads the boot sector code from that partition and executes it.
——
The BIOS will first load the MBR into memory which is only 512 bytes in size and points to the boot loader (LILO: Linux boot loader) or GRUB [GRand Unified Bootloader].
Once the BIOS finds and loads the boot loader program into memory, it yields control of the boot process to it.
————————
Stage 2 – Boot Loader
————————
LILO or GRUB allows the root user to set up the boot process as menu-driven or command-line, and permits the user to choose from amongst several boot options.
It also allows for a default boot option after a configurable timeout, and current versions are designed to allow booting from broken Level 1 (mirrored) RAID arrays.
It has the ability to create a highly configurable, “GUI-fied” boot menu, or a simple, text-only, command-line prompt.
——
Due to the very small amount of data the BIOS can access, most boot loaders load in two stages. In the first stage of the boot, the BIOS loads a part of the boot loader known as the initial program loader, or IPL. The IPL interrogates the partition table and subsequently is able to load data wherever it may exist on the various media. This action is used initially to locate the second stage boot loader, which holds the remainder of the loader.
The second stage boot loader is the real meat of the boot loader; many consider it the only real part of the boot loader. This contains the more disk-intensive parts of the loader, such as user interfaces and kernel loaders. These user interfaces can range from a simple command line to the all-singing, all-dancing GUIs.
Boot loaders are usually configured in one of two ways: either as a primary boot loader or as a secondary boot loader. Primary boot loaders are where the first stage of the boot loader is installed on the MBR (per the previous description). Secondary boot loaders are where the first stage of the boot loader is installed onto a bootable partition. A separate boot loader must then be installed into the MBR and configured to pass control to the secondary boot loader.
——
Depending on the kernel boot option chosen or set as default, lilo or grub will load that kernel .
————————
Stage 3 – Kernel
————————
When the kernel is loaded, it immediately initializes and configures the computer’s memory and configures the various hardware attached to the system, including all processors, I/O subsystems, and storage devices.
It then looks for the compressed initrd image in a predetermined location in memory, decompresses it, mounts it, and loads all necessary drivers.
Next, it initializes virtual devices related to the file system, such as LVM or software RAID before unmounting the initrd disk image and freeing up all the memory the disk image once occupied.
The kernel then creates a root device, mounts the root partition read-only, and frees any unused memory.
At this point, the kernel is loaded into memory and operational.
————————
Stage 4 – Init
————————
The first thing the kernel does after completing the boot process is to execute init program.
The /sbin/init program (also called init) coordinates the rest of the boot process and configures the environment for the user.
Init is the root/parent of all processes executing on Linux which becomes process number 1.
——
The first few process Ids are given below:-
1 – Init Process
2 – kflushd(bdflush) : Started by update – does a more imperfect sync more frequently
3 – kupdate : Does a sync every 30 seconds
4 – kpiod
5 – kswapd
6 – mdrecoveryd
Processes 2, 3, 4, 5 and 6 are kernel daemons. The kernel daemons are started after init, so they get process numbers like normal processes do. But their code and data lives in the kernel’s part of the memory.
——————
Kflushd and Kupdate
——————
Input and output is done via buffers in memory. This allows things to run faster and the data in the buffer are written to disk in larger more efficient chunks.
The daemons kflushd and kupdate handle this work. kupdate runs periodically (5 seconds) to check whether there are any dirty buffers. If there are, it gets kflushd to flush them to disk.
——————
Kswap and Kpiod
——————
System memory can be better managed by shifting unused parts of running programs out to the swap partition(s) of the hard disk.
Moving this data in and out of memory as needed is done by kpiod and kswapd.
Every second or so, kswapd wakes up to check out the memory situation, and if something on the disk is needed in memory, or there is not enough free memory, kpiod is called in.
——————
Mdrecoveryd
——————
mdrecoveryd is part of the Multiple Devices package used for software RAID and combining multiple disks into one virtual disk Basically it is part of the kernel.
It can be removed from the kernel by deselecting it (CONFIG_BLK_DEV_MD) and recompiling the kernel.
——
When the init command starts, it becomes the parent or grandparent of all of the processes that start up automatically on a Red Hat Linux system.
Based on the appropriate run-level in the /etc/inittab file , scripts are executed to start various processes to run the system and make it functional.
1]The init command then runs the /etc/inittab script.
2]The first thing init runs out of the inittab is the script /etc/rc.d/rc.sysinit , which sets the environment path, starts swap, checks the file systems, and takes care of everything the system needs to have done at system initialization.
3]init looks through /etc/inittab for the line with “initdefault” in the third field. The initdefault entry tells the system what run-level to enter initially.
—
id:5:initdefault: ( 5 is the default runlevel)
—
Depending on the run level, the init program starts all of the background processes by using scripts from the appropriate “rc” directory for the runlevel.
For instance, /etc/rc.d/rc5.d/ is the directory for runlevel 5. Run the following command in your local machine and check the contents of this directory. I am pasting a trace of the output below.
[user@localhost ~]$ ls -al /etc/rc.d/rc5.d/
total 20
drwxr-xr-x 2 root root 4096 Jun 24 19:10 .
drwxr-xr-x 10 root root 4096 Jul 10 2008 ..
lrwxrwxrwx 1 root root 22 Dec 23 2008 K02avahi-daemon -> ../init.d/avahi-daemon
lrwxrwxrwx 1 root root 24 Dec 23 2008 K02avahi-dnsconfd -> ../init.d/avahi-dnsconfd
lrwxrwxrwx 1 root root 16 Dec 23 2008 K02dhcdbd -> ../init.d/dhcdbd
lrwxrwxrwx 1 root root 24 Dec 23 2008 K02NetworkManager -> ../init.d/NetworkManager
lrwxrwxrwx 1 root root 34 Dec 23 2008 K02NetworkManagerDispatcher -> ../init.d/NetworkManagerDispatcher
…………
………..
……….
lrwxrwxrwx 1 root root 25 Dec 23 2008 S04readahead_early -> ../init.d/readahead_early
lrwxrwxrwx 1 root root 15 Dec 23 2008 S05kudzu -> ../init.d/kudzu
lrwxrwxrwx 1 root root 18 Dec 23 2008 S06cpuspeed -> ../init.d/cpuspeed
lrwxrwxrwx 1 root root 17 Dec 23 2008 S10network -> ../init.d/network
lrwxrwxrwx 1 root root 21 Dec 23 2008 S10restorecond -> ../init.d/restorecond
lrwxrwxrwx 1 root root 16 Dec 23 2008 S11auditd -> ../init.d/auditd
lrwxrwxrwx 1 root root 16 Dec 23 2008 S12syslog -> ../init.d/syslog
lrwxrwxrwx 1 root root 20 Dec 23 2008 S13irqbalance -> ../init.d/irqbalance
lrwxrwxrwx 1 root root 18 Dec 23 2008 S13mcstrans -> ../init.d/mcstrans
lrwxrwxrwx 1 root root 17 Feb 6 20:20 S13portmap -> ../init.d/portmap
You can find “S” , “K” prefix on the the 9th field [last field]. Scripts beginning with S denote startup scripts while scripts beginning with K denote shutdown (kill) scripts.
Numbers follow these letters to denote the order of execution. (lowest to highest)
Adding a script to the /etc/rc.d/rc#.d/ directory with either an S or K prefix, adds the script to the boot or shutdown process.Hence these scripts are executed to start all the system services which starts at S for run level 5 in the example above. One of the last things the init program executes is the /etc/rc.d/rc.local file. This file is useful for system customization.
Adding commands to this script is an easy way to perform necessary tasks like starting special services or initialize devices without writing complex initialization scripts in the /etc/rc.d/init.d/ directory and creating symbolic links.
Init typically will start multiple instances of “getty” which waits for console logins which spawn one’s user shell process.
Upon system shutdown init controls the sequence and processes for shutdown. The init process is never shut down. It is a user process and not a kernel system process although it does run as root.
That explains the Booting process.
References :
http://www.ibm.com/developerworks/linux/library/l-bootload.html
http://www.xs4all.nl/~lennartb/bootloaders/node3.html
