Linux Booting Process

Linux Booting Process 1. Introduction

"Booting the computer", this is a common word associated with starting the computer. Though we use it casually in our daily life, have you ever thought of what exactly it is ? or how the system brings itself to a workable environment ? Well, my attempt in this article is to explain all the stages involved in booting your Linux machine. In simple words, bootstrapping means starting up your computer. It involves all those stages, from the moment you power on your machine till the system is ready to log you in.

2. The Boot Process

The Boot process involves several different stages that the system undergoes while it is being booted. If any of these stages fail, then the system cannot start itself.

* The BIOS
* Kernel Initialization
* Hardware Configuration
* System Processes
* Startup Scripts
* Multiuser Mode

Lets look at each of the above stages in detail.

2.1 The BIOS

This is the initial stage of the boot process. The moment you power your system, the microprocessor is not aware of your computer environment or even your operating system. It is the BIOS, that provides the necessary instructions to microprocessor and helps to initialize the computer environment. That is why it is called Basic Input/Output System.

These are the main tasks of BIOS.

* POST (Power On Self Test): The BIOS performs a power on self test on all hardware components attached to the computer during booting. You might have noticed the LEDs on your keyboard flashing during booting. That is an example of POST. If anything fails, it will be reported to you on your screen.

* The BIOS provides a set of low level routines for the hardware components to interface with the Operating System. These routines act like drivers for your Screen, Keyboard, Ports etc.

* The BIOS helps to manage the settings of hard disks, your first boot device, system time and more.

The BIOS also initiates the bootstrapping sequence by loading the Initial Program Loader (The boot loader program) into the computer memory. The software is usually stored in the ROM. This stage is actually outside of the domain of the Operating System and it is more vendor specific.

2.2 Kernel Initialization

Linux actually implements a two stage boot process. In the first stage, the BIOS loads the boot program (Initial Program Loader) from the hard disk to the memory. In the second stage, the boot program loads the Operating System kernel vmlinuz into memory. Though, the kernel can be called any name, we'll call it vmlinuz. Well, it's just a tradition, where vm stands for the Virtual Memory support and last z denotes that it is a compressed image, ie vmlinux.z => vmlinuz.

When the kernel loads into memory, it performs a memory test. Most of the kernel data structures are initialized statically. So it sets aside a part of memory for kernel use. This part of the memory cannot be used by any other processes. It also reports the total amount of physical memory available and sets aside those for the user processes.

2.3 Hardware Configuration
If you have configured a Linux kernel, you would have configured the hardware sections as well. This is how the kernel knows what hardware to find. Based on the configuration, when the kernel boots, it tries to locate or configure those devices. It also prints the information of the devices it found during the bootup. It will probe the the bus for devices or asks the driver for information of the devices. Devices that are not present in the system or not responding to the probing will be disabled. It is possible to add more devices using the utility kudzu.

2.4 System Processes
Once the hardware initialization is complete, the kernel will create several spontaneous processes in the user space. The following are those processes.

* init
* keventd
* kswapd
* kupdated
* bdflush

These are called spontaneous processes because they are not created by the usual fork mechanism. Of these, only init is actually in the user space(only processes in the user space can be controlled by us) , we have no control over others. The rest of the boot up procedure is controlled by init.

2.5 Startup Scripts

Before explaining how startup scripts work, let's have a look at the tasks performed by them. The following are the important tasks performed by startup scripts.

* Set the name of the computer
* Set the time zone
* Check the hard disk with fsck
* Mount system disk
* Remove old files from /tmp partition
* Configure network interfaces with correct IP address
* Startup deamons and other network services

The startup scripts are found in /etc/rc.d/init.d folder in your Linux machine.

2.5.1 Init and runlevels

You can boot your Linux machine to different runlevels. A runlevel is a software defined configuration of your system where the system behavior will vary in different runlevels. Though, Linux can have 10 different runlevels, only 7 of them are used. I have mentioned them below.

runlevel description
0 shutdown
1 or S single user mode
2 multiuser mode without nfs
3 full multiuser mode
4 not used
5 X windows
6 reboot

You can specify the runlevel in the init configuration file /etc/inittab.

2.5.2 Startup Scripts and runlevels

You may see folders (rc[0-7].d) corresponding to each runlevel in the /etc folder. These folders contain files symbolically linked (in Linux everything is a file) to the startup scripts in folder /etc/rc.d/init.d. If you look at these folders, you may see that the name of the symbolic links starts with the letter S or K followed by a number and the name of the startup script /service to which it is linked to.

For example, the following are the files in runlevel 2 and 3.

/etc/rc2.d/K20nfs -> ../init.d/nfs
/etc/rc2.d/S55named -> ../init.d/named
The name of those files are important. Because when you switch between runlevels, the services are started/stopped based on these names. Consider these two cases here.

* switching to higher runlevels - init will run scripts that start with letter S, in ascending order of the number with argument start
* switching to lower runlevels - init will run scripts that start with letter K, in descending order of the number with argument stop
The runlevels init checks to switch between them, depends on the configuration of your system. The following commands will help. For more details of the commands, refer to the manual pages.

The commands that deal with runlevels are:

/sbin/runlevel - shows the previous and current runlevels
/sbin/init and /sbin/telinit[b] - to switch between runlevels
[b]/sbin/chkconfig - to enable/disable services in runlevels

2.5.3 Startup Scripts and /etc/sysconfig files
The files in the /etc/sysconfig folder are read by the startup scripts. So it's worth mentioning them here.

* network - contains information of your hostname, nisdomain name etc.
* clock - timezone information
* autofsck - automatic filesystem check during boot up
* network-scripts - folder contains interface configuration files ifcfg-lo, ifcfg-eth0 etc.
* hwconf - hardware information
* sendmail, spamassassin, syslog, yppasswdd - information about the corresponding daemons.

Edit the files in /etc/sysconfig folder to make changes to your system.

2.5.4 Init and single user mode

This runlevel is used by sysadmins to perform routine maintenance. Its most commonly used for checking errors in file system with command fsck. Only the root file system will be mounted in this runlevel and the system administrator is provided with a shell. If necessary, other partitions needs to be mounted manually. Also none of the deamons will be running in this runlevel. Only the system administrator can use the system in this mode. You can simply exit from the shell to boot it to the multiuser mode.

2.6 Multiuser Operation

Though the system has been booted to a particular runlevel, none of the users can login to the system until init spawns getty processes on terminals. If the system is booted to runlevel 5, init needs to spawn the graphical login system gdm.

If the system has gone through the above mentioned stages without any failures, you may say that your system is booted and is ready to perform the tasks Smile

3. Rebooting and Shutting down

We have discussed about the boot procedure so far. It is also important to shutdown the system properly. Otherwise you may end up with loss of data or serious damage to the file system.

You can safely use the commands /sbin/shutdown, /usr/bin/halt or /usr/bin/reboot to halt or reboot the computer. For more details of the commands, refer to the manual pages.


===================================================================================

Boot process in a simple manner
_____________________________

When a system is switched on the processor looks at the end of system memory for the Basic Input/Output System or BIOS program and runs it. The BIOS is made up of two parts: the POST code and runtime services. POST(Power On Self Test) checks the system hardware and performs local device initialization. Then BIOS runtime services check for a valid boot device. If no configuration changes are made in BIOS it will first check floppy drive then harddisk drive and then on removable disk drives if any. If no boot device is found it will sends an interrupt and boot process will be terminated.

The boot device contains primary bootloader in the first 512-byte sector of the disk. This segment is called the Boot Sector. Sometimes it is also called Master Boot Record(MBR). Once a valid boot device is found, primary bootloader is loaded into RAM and BIOS passes control to it.

Stage 1

The primary boot loader that resides in the MBR is a 512-byte image containing both program code and a small partition table. The first 446 bytes are the primary boot loader, which contains both executable code and error message text. The next sixty-four bytes are the partition table, which contains a record for each of four partitions (sixteen bytes each). The MBR ends with two bytes that are defined as the magic number (0xAA55). The magic number serves as a validation check of the MBR.

The job of the primary boot loader is to find and load the secondary boot loader (stage 2) by looking through the partition table for an active partition. When it finds an active partition, it scans the remaining partitions in the table to ensure that they're all inactive. When this is verified, the active partition's boot record (secondary boot loader) is read from the device into RAM and executed.

Stage 2

The secondary boot loader is also called the kernel loader. The task at this stage is to load the Linux kernel and optional initial RAM disk.

The second stage boot loader has two functions:

1. Display the list of available kernels upon request, defined in bootloader configuration file.
(ie, for LILO /etc/lilo.conf and for Grub /etc/grub.conf)

2. Consult with filesystem to load the default kernel image and initrd image into memory.

With the images ready, the stage 2 boot loader passes the control to kernel image.

Stage 3

From here the Kernel stage begins.

The kernel image is a compressed image typically a zImage or bzImage.

The bzImage is decompressed by the C function decompress_kernel (located in ./arch/i386/boot/compressed/misc.c). When the kernel is decompressed into memory, it immediately initializes and configures memory paging and configures the various hardware attached to the system, including all processors, I/O subsystems, and storage devices.

Then it loads the initial RAM disk(initrd) and loads all the necessary drivers. This initrd serves as a temporary root file system in RAM and allows the kernel to fully boot without having to mount any physical disks. At this point, there are no user applications that allow meaningful input to the system, not much can be done with the system. To set up the user environment, the kernel executes the /sbin/init program.

Init

After the kernel is booted and initialized, the kernel starts the first user-space application. The /sbin/init program (also called init) coordinates the rest of the boot process and configures the environment for the user.

--------------------------------------------------------------------

VPS ( Virtual private server )

A virtual private server (VPS, also referred to as Virtual Dedicated Server or VDS) is a method of partitioning a physical server computer into multiple servers such that each has the appearance and capabilities of running on its own dedicated machine. Each virtual server can run its own full-fledged operating system, and each server can be independently rebooted.

The practice of partitioning a single server so that it appears as multiple servers has long been common practice in mainframe computers, but has seen a resurgence lately with the development of virtualization software and technologies for other architectures.