The Linux Boot Process

When we start the Computer, the processor first looks for the BIOS (Basic Input and Output Service) and runs it. The Bios is a program written into the permanent read-only memory. The Bios controls the first step of the boot process.

The Bios first checks the system, peripherals and looks for the drive to boot the system. It checks the floppy drive , CD-ROM and then Hard Drive to  boot the system. These order of these settings can be changed in the Bios settings. The Bios then looks for the MBR(Master Boot Record) which resides in the first sector of the hard-drive that is used to boot. The Bios loads the MBR into memory and passes control to that.

The MBR then knows how to load the Boot loader (Grub or LILO).It loads the Grub boot loader and passes control to that. In General Grub uses information from MBR to display the boot options. Once the grub obtained the necessary information  , the Grub finds the correct boot file and passes control to that

Grub : GRand Unified Bootloader

GRUB is the reference implementation of the Multiboot Specification, which provides a user the choice to boot one of multiple operating systems installed on a computer or select a specific kernel configuration available on a particular operating system's partitions.

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

The Kernal

Once the Kernal is loaded , it finds the init in /sbin and executes it. The init process becomes the parent process for all other process that start after init. The first thing init does is to read the /etc/inittab file.this file tells which processes are started at bootup and during normal operation.

This file helps init in setting the paths , swap ,files systems basically everything that a system needs while start up.

The init reads the /etc/inittab which also tells how the system should be setup in different runlevels. A  runlevel is a software configuration of the system which allows only a selected group of processes to exist.a run level is nothing but a configuration of process.unix based system can run in different runlevels , like single user mode, multi user mode e.t.c.These run levels provides specific functionality . In single user mode , we can perform operations much like a system administrator .  in run level 6 , which is a reboot , shutdowns the system according to the procedure and restart the system.

we can use the runlevel command to find the run level we are currently in

[root@vx111a ~]# runlevel

N 5

Once the run level is identified from the /etc/inittab ,it starts the necessary process for the system to run by looking at the rc directory for that run level.In this case ,it starts from /etc/rc5.d.There are 2 types of files in this locations , one starts with “k” and other starts with “S”.the process that start with “K” are the stop process and process that start with “S” are the Start process.the init first executes all the process that start with “K” and then start the process (starting with “S”).this makes sure that all process are started correctly.

None of the scripts in here are started or killed.These are basically sysmbolic links to the files available in /etc/init.d.The symbolic links are numbered in perticular order so that they start and stop in order like 

K01dnsmasq

K02avahi-dnsconfd

K02NetworkManager

K05conman

there are some services with same number which makes to execute the process right after the process with same number,

Once init processed the runlevels, the /etc/inittab forks a getty process for each vitual console.getty opens tty lines, sets their modes, prints the login prompt, gets the user's name, and then initiates a login process for that user. This allows users to authenticate themselves to the system and use it. By default, most systems offer 6 virtual consoles, but as you can see from the inittab file, this is configurable.

/etc/inittab also tells what should be done when user preses ctrl+alt+del at the console.

in most system , a gui login screen is started in run level 5.the /etc/inittab run the script called in prefdm in /etc/x11/prefdm.this runs the x display manager based on the contents in /etc/sysconfig/desktop directory. This is typically gdm for gnome and kdm for KDE.

The /etc/default and/or /etc/sysconfig directories contain entries for a range of functions and services, these are all read at boot time

The scripts for a given run level are run during boot and shutdown. The scripts are found in the directory /etc/rc.d/rc#.d/ where the symbol # represents the run level. i.e. the run level "3" will run all the scripts in the directory /etc/rc.d/rc3.d/ which start with the letter "S" during system boot. This starts the background processes required by the system. During shutdown all scripts in the directory which begin with the letter "K" will be executed. This system provides an orderly way to bring the system to different states for production and maintenance modes.

Recommended basic services: anacron, ard, autofs, crond, gpm, iptables, keytable, kudzu, microcode_ctl (Intel32 hardware only), network, random. syslog

init run levels

The idea behind operating different services at different run levels essentially revolves around the fact that different systems can be used in different ways. Some services cannot be used until the system is in a particular state, or mode, such as being ready for more than one user or having networking available.

There are times in which you may want to operate the system in a lower mode. Examples are fixing disk corruption problems in run level 1 so no other users can possibly be on the system, or leaving a server in run level 3 without an X session running. In these cases, running services that depend upon a higher system mode to function does not make sense because they will not work correctly anyway. By already having each service assigned to start when its particular run level is reached, you ensure an orderly start up process, and you can quickly change the mode of the machine without worrying about which services to manually start or stop.

Runlevel	Scripts Directory (Red Hat/Fedora Core)	State
0	/etc/rc.d/rc0.d/	shutdown/halt system
1	/etc/rc.d/rc1.d/	Single user mode
2	/etc/rc.d/rc2.d/	Multiuser with no network services exported
3	/etc/rc.d/rc3.d/	Default text/console only start. Full multiuser
4	/etc/rc.d/rc4.d/	Reserved for local use. Also X-windows (Slackware/BSD)
5	/etc/rc.d/rc5.d/	XDM X-windows GUI mode (Redhat/System V)
6	/etc/rc.d/rc6.d/	Reboot
s or S		Single user/Maintenance mode (Slackware)
M		Multiuser mode (Slackware)

One may switch init levels by issuing the init command with the appropriate runlevel. Use the command "init #" where # is one of s,S,0,1,3,5,6. The command telinit does the same.

Happy Coding.More to Come