Articles

Linux Boot Process

The process of booting a Linux system consists of a number of stages. But whether you're booting a standard x86 desktop much of the flow is surprisingly similar. This article explores the Linux boot process from the initial bootstrap to the start of the first user-space application. The booting of a linux machine includes various steps as explained below in the order.

1. The BIOS

When an x86 computer is booted, the processor looks at the end of system memory for the Basic Input/Output System or BIOS program and runs it. The BIOS controls not only the first step of the boot process, but also provides the lowest level interface to peripheral devices. For this reason it is written into read-only, permanent memory and is always available for use.
Once loaded, the BIOS tests the system, looks for and checks peripherals, and then locates a valid device with which to boot the system. Usually, it checks any diskette drives and CD-ROM drives present for bootable media, then, failing that, looks to the system's hard drives. In most cases, the order of the drives searched while booting is controlled with a setting in BIOS, and it looks on the master IDE device on the primary IDE bus. The BIOS then loads into memory whatever program is residing in the first sector of this device, called the Master Boot Record or MBR. The MBR is only 512 bytes in size and contains machine code instructions for booting the machine, called a boot loader, along with the partition table. Once the BIOS finds and loads the boot loader program into memory, it yields control of the boot process to it.

2. boot loader

Next, the kernel is loaded into the memory and executed. This can be done by different programs like LOADLIN that reads a kernel file you specify and writes it into the memory (it overwrites DOS loaded into the memory).
Another way can be LILO, the LInux LOader. It loads the kernel directly from the physical sector on a hard disk. Therefore, LILO writes itself into the Master Boot Record (MBR) together with the sectors where the kernels are placed. The very first sector of the hard disk is reserved for the same purpose and is called the master boot record (MBR). After choosing the appropriate kernel, it writes it into memory and executes it.
When booting from a hard disk, the PC system BIOS loads and executes the boot loader code in the MBR. The MBR then needs to know which partitions on the disk have boot loader code specific to their operating systems in their boot sectors and then attempts to boot one of them.
Fedora Linux is supplied with the GRUB boot loader which is fairly sophisticated and therefore cannot entirely fit in the 512 bytes of the MBR. The GRUB MBR boot loader merely searches for a special boot partition and loads a second stage boot loader. This then reads the data in the /boot/grub/grub.conf configuration file, which lists all the available operating systems and their booting parameters. When this is complete, the second stage boot loader then displays the familiar Fedora branded splash screen that lists all the configured operating system kernels for your choice. The kernel is responsible for recognizing and including all the hardware into the system.

Sample grub.conf file

default=0
timeout=10
splashimage=(hd0,0)/grub/splash.xpm.gz
title Fedora Core (2.6.8-1.521)
root (hd0,0)
kernel /vmlinuz-2.6.8-1.521 ro root=LABEL=/
initrd /initrd-2.6.8-1.521.img
title Windows 2000
rootnoverify (hd0,1)
chainloader +1

3. The 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. However, since there are no user applications that allow meaningful input to the system, not much can be done with it.

In order to set up the user environment, the kernel executes the /sbin/init program.

4. initrd

There is nothing special about init. It is a program just like any other on the Linux system, and you ll find it in /sbin along with other system binaries. The main purpose of init is to start and stop other programs in a particular sequence. All you have to know is how this sequence works. There are a few different variations, but most Linux distributions use the System V style discussed here. Some distributions use a simpler version that resembles the BSD init, but you are unlikely to encounter this.

Runlevels

At any given time on a Linux system, a certain base set of processes are running. This state of the machine is called its runlevel, and it is denoted with a number from 0 through 6. The system spends most of its time in a single runlevel. However, when you shut the machine down, init switches to a different runlevel in order to terminate the system services in an orderly fashion and to tell the kernel to stop.

It's Linux's first process, and parent of all the other processes. This process is the first running process on any Linux/UNIX system, and is started directly by the kernel. It is what loads the rest of the system, and always has a PID of 1.

The init process
The easiest way to get a handle on runlevels is to examine the init configuration file, /etc/inittab. Look for a line like the following:

id:5:initdefault:

This line means that the default runlevel on the system is 5. All lines in the inittab file take this form, with four fields separated by colons occuring in the following order:

l5:5:wait:/etc/rc.d/rc 5

This particular line is important because it triggers most of the system configuration and services through the rc*.d and init.d directories. You can see that init is set to execute a command called /etc/rc.d/rc 5 when in runlevel 5. The wait action tells when and how init runs the command: run rc 5 once when entering runlevel 5, and then wait for this command to finish before doing anything else. There are several different actions in addition to initdefault and wait, especially pertaining to power management, and the inittab(5) manual page tells you all about them.

respawn

The respawn action causes init to run the command that follows, and if the command finishes executing, to run it again. You re likely to see something similar to this line in your inittab file:

1:2345:respawn:/sbin/mingetty tty1

The getty programs provide login prompts. The preceding line is for the first virtual console (/dev/tty1), the one you see when you press ALT-F1 or CONTROL-ALT-F1 (see Section 3.3). The respawn action brings the login prompt back after you log out.

ctrlaltdel

The ctrlaltdel action controls what the system does when you press CONTROL-ALT-DELETE on a virtual console. On most systems, this is some sort of reboot command, using the shutdown command,

sysinit

The sysinit action is the very first thing that init should run when it starts up, before entering any runlevels.

Table Linux Runlevels

Mode Directory Run Level Description
0 /etc/rc.d/rc0.d Halt
1 /etc/rc.d/rc1.d Single-user mode
2 /etc/rc.d/rc2.d Not used (user-definable)
3 /etc/rc.d/rc3.d Full multi-user mode (no GUI interface)
4 /etc/rc.d/rc4.d Not used (user-definable)
5 /etc/rc.d/rc5.d Full multiuser mode (with GUI interface)
6 /etc/rc.d/rc6.d Reboot

Based on the selected runlevel, the init process then executes startup scripts located in subdirectories of the /etc/rc.d directory. Scripts used for runlevels 0 to 6 are located in subdirectories /etc/rc.d/rc0.d through /etc/rc.d/rc6.d, respectively.

Here is a directory listing of the scripts in the /etc/rc.d/rc3.d directory:

[root@localhost]# ls /etc/rc.d/rc3.d
... ... K75netfs K96pcmcia ... ...
... ... K86nfslock S05kudzu ... ...
... ... K87portmap S09wlan ... ...
... ... K91isdn S10network ... ...
... ... K92iptables S12syslog ... ...
... ... K95firstboot S17keytable ... ...
[root@localhost]#

As you can see, each filename in these directories either starts with an "S" which signifies the script should be run at startup, or a K, which means the script should be run when the system is shutting down. If a script isn't there, it won't be run.

Most Linux packages place their startup script in the /etc/init.d directory and place symbolic links (pointers) to this script in the appropriate subdirectory of /etc/rc.d. This makes file management a lot easier. The deletion of a link doesn't delete the file, which can then be used for another day.

The number that follows the K or S specifies the position in which the scripts should be run in ascending order. In our example, kudzu with a value 05 will be started before wlan with a value of 09. Fortunately you don't have to be a scripting/symbolic linking guru to make sure everything works right because Fedora comes with a nifty utility called chkconfig.

Summary

Much like Linux itself, the Linux boot process is highly flexible, supporting a huge number of processors and hardware platforms. In the beginning, the loadlin boot loader provided a simple way to boot Linux without any frills. The LILO boot loader expanded the boot capabilities, but lacked any file system awareness. The latest generation of boot loaders, such as GRUB, permits Linux to boot from a range of file systems (from Minix to Reiser).