Inside Linux

Linux booting process :

Here in this figure you can take the overview of  Linux booting in a PC or a customize embedded hardware 

booting sequence

Now its time to go some deeper inside booting process-

System startup

When a system is first booted, or is reset, the processor executes code at a well-known location. In a personal computer (PC), this location is in the basic input/output system (BIOS), which is stored in flash memory on the motherboard. The central processing unit (CPU) in an embedded system invokes the reset vector to start a program at a known address in flash/ROM. In either case, the result is the same. Because PCs offer so much flexibility, the BIOS must determine which devices are candidates for boot. We'll look at this in more detail later.

When a boot device is found, the first-stage boot loader is loaded into RAM and executed. This boot loader is less than 512 bytes in length (a single sector), and its job is to load the second-stage boot loader.

When the second-stage boot loader is in RAM and executing, a splash screen is commonly displayed, and Linux and an optional initial RAM disk (temporary root file system) are loaded into memory. When the images are loaded, the second-stage boot loader passes control to the kernel image and the kernel is decompressed and initialized. At this stage, the second-stage boot loader checks the system hardware, enumerates the attached hardware devices, mounts the root device, and then loads the necessary kernel modules. When complete, the first user-space program (init) starts, and high-level system initialization is performed.

That's Linux boot in a nutshell. Now let's dig in a little further and explore some of the details of the LinThe secondary, or second-stage, boot loader could be more aptly called the kernel loader. The task at this stage is to load the Linux kernel and optional initial RAM disk.

GRUB stage boot loaders

The /boot/grub directory contains the stage1,stage1.5, and stage2 boot loaders, as well as a number of alternate loaders (for example, CR-ROMs use the iso9660_stage_1_5).

The first- and second-stage boot loaders combined are called Linux Loader (LILO) or GRand Unified Bootloader (GRUB) in the x86 PC environment. Because LILO has some disadvantages that were corrected in GRUB, let's look into GRUB. (See many additional resources on GRUB, LILO, and related topics in the Resourcessection later in this article.)

The great thing about GRUB is that it includes knowledge of Linux file systems. Instead of using raw sectors on the disk, as LILO does, GRUB can load a Linux kernel from an ext2 or ext3 file system. It does this by making the two-stage boot loader into a three-stage boot loader. Stage 1 (MBR) boots a stage 1.5 boot loader that understands the particular file system containing the Linux kernel image. Examples include reiserfs_stage1_5 (to load from a Reiser journaling file system) or e2fs_stage1_5 (to load from an ext2 or ext3 file system). When the stage 1.5 boot loader is loaded and running, the stage 2 boot loader can be loaded.

With stage 2 loaded, GRUB can, upon request, display a list of available kernels (defined in /etc/grub.conf, with soft links from /etc/grub/menu.lst and /etc/grub.conf). You can select a kernel and even amend it with additional kernel parameters. Optionally, you can use a command-line shell for greater manual control over the boot process. 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.ux boot process.

MBR

MBR stands for Master Boot Record.
It is located in the 1st sector of the bootable disk. Typically /dev/hda, or /dev/sda
MBR is less than 512 bytes in size. This has three components 1) primary boot loader info in 1st 446 bytes 2) partition table info in next 64 bytes 3) mbr validation check in last 2 bytes.
It contains information about GRUB (or LILO in old systems).
So, in simple terms MBR loads and executes the GRUB boot loader.

GRUB

GRUB stands for Grand Unified Bootloader.
If you have multiple kernel images installed on your system, you can choose which one to be executed.
GRUB displays a splash screen, waits for few seconds, if you don’t enter anything, it loads the default kernel image as specified in the grub configuration file.
GRUB has the knowledge of the filesystem (the older Linux loader LILO didn’t understand filesystem).
Grub configuration file is /boot/grub/grub.conf (/etc/grub.conf is a link to this). The following is sample grub.conf of CentOS.
#boot=/dev/sda
default=0
timeout=5
splashimage=(hd0,0)/boot/grub/splash.xpm.gz
hiddenmenu
title CentOS (2.6.18-194.el5PAE)
          root (hd0,0)
          kernel /boot/vmlinuz-2.6.18-194.el5PAE ro root=LABEL=/
          initrd /boot/initrd-2.6.18-194.el5PAE.img
As you notice from the above info, it contains kernel and initrd image.
So, in simple terms GRUB just loads and executes Kernel and initrd images.

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

 Mounts the root file system as specified in the “root=” in grub.conf

 Kernel executes the /sbin/init program

Since init was the 1st program to be executed by Linux Kernel, it has the process id (PID) of 1.

Do a ‘ps -ef | grep init’ and check the pid.

 initrd stands for Initial RAM Disk.

 initrd is used by kernel as temporary root file system until kernel is booted and the real root

file system is mounted. It also contains necessary drivers compiled inside, which helps it to

access the hard drive partitions, and other hardware.

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.

In a desktop Linux system, the first application started is commonly /sbin/init. But it need not be. Rarely do embedded systems require the extensive initialization provided by init (as configured through /etc/inittab). In many cases, you can invoke a simple shell script that starts the necessary embedded applications.

.

 Looks at the /etc/inittab file to decide the Linux run level.

 Following are the available run levels

  §  0 – halt
§  1 – Single user mode
§  2 – Multiuser, without NFS
§  3 – Full multiuser mode
§  4 – unused
§  5 – X11
§  6 – reboot

  Init identifies the default initlevel from /etc/inittab and uses that to load all appropriate

 program.

  Execute ‘grep initdefault /etc/inittab’ on your system to identify the default run level

  If you want to get into trouble, you can set the default run level to 0 or 6. Since you know

 what 0 and 6 means, probably you might not do that.

 Typically you would set the default run level to either 3 or 5.

Runlevel

 When the Linux system is booting up, you might see various services getting started. For

example, it might say “starting sendmail …. OK”. Those are the runlevel programs, executed

from the run level directory as defined by your run level.

Depending on your default init level setting, the system will execute the programs from one of

the following directories.

§  Run level 0 – /etc/rc.d/rc0.d/

§  Run level 1 – /etc/rc.d/rc1.d/

§  Run level 2 – /etc/rc.d/rc2.d/

§  Run level 3 – /etc/rc.d/rc3.d/

§  Run level 4 – /etc/rc.d/rc4.d/

§  Run level 5 – /etc/rc.d/rc5.d/

§  Run level 6 – /etc/rc.d/rc6.d/

  Please note that there are also symbolic links available for these directory under /etc directly.

 So, /etc/rc0.d is linked to /etc/rc.d/rc0.d.

  Under the /etc/rc.d/rc*.d/ directories, you would see programs that start with S and K.

  Programs starts with S are used during startup. S for startup.

  Programs starts with K are used during shutdown. K for kill.

  There are numbers right next to S and K in the program names. Those are the sequence

 number in which the programs should be started or killed.

 For example, S12syslog is to start the syslog deamon, which has the sequence number of 12.  S80sendmail is to start the sendmail daemon, which has the sequence number of 80. So,  syslog program will be started before sendmail.