Linux - How does a system boot, Boot process Machine or Computer

How does a system boot

Boot Process of a Linux Machine

BOOTING PROCESS

BIOS BootSector KernelInitilisation Init SysVinit scripts.

BIOS

(Basic Input Output System)
Bios is a piece of software that is built-in to the machine,usually by being stored in the flash ROM on the motherboard. There are two purpose of BIOS,one it takes the machine from a power-on state to the point where it can run grub.Secondly it provides the set of rudimentary device drivers for some of the hardware in the machine.

Functions of BIOS:

1) Post (Power-On Self Test) The Power On Self Test, or POST routine runs to find certain hardware and to test that the hardware is working at a basic level.

a) It checks the system components. 
b) verify the checksum 
c) display the status.

2) Initialisation Hardware devices are initialized. PCI devices need to be given IRQs, input/output addresses and a table of these devices is then displayed on-screen.

3) Bsl(bootStrapLoader) The BIOS must search for an operating system on the various media that is supported. This usually occurs by searching for a boot sector on the devices that are specified in the CMOS/BIOS.Once a valid boot sector has been found, it is copied into RAM and then executed.

a) Detect the boot device. 
b) Read boot block. 
c) Locate MBR. 
d) Transter the OS.

Boot Sectors

Boot loader maintains the OS image,boot loader always locate at the first 512 bytes of disk area. It holds the partition information and filesystem metadata.

GRUB(GRand Unified Bootloader)

--> Bios loads boot block containing stage1.
--> Stage1 loads first block of stage2,whose location is burned in.
--> First block of stage2 loads rest of stage2.
--> Stage2 loads configuration files /boot/grub/grub.conf

--> Stage2 loads kernel.

Grub boot process:

Grub comes in two parts stage1 and stage2. Stage1 is a very small program which fits into a 512bytes disksector with room to spare for partition tables and small amount of configuration information.Stage1 is stored in MBR of the harddisk and is loaded by the BIOS. Stage2 is the part of GRUB that does all the hardwork. It reads the configuration /boot/grub/grub.conf

Kernel Initialisation

kernel boot time functions:

1) Device detection.
2) Device driver initialisation.
3) Mounts root filesystem readonly.
4) Loads initial process init.

The kernel must initialize any devices the system has. Even devices that have been initialized by the BIOS must be reinitialized. This provides portability and robustness by ensuring that each system has been initialized in a similar fashion, independent of the BIOS.

The decompressed kernel now takes over and begins to set up the execution environment for the first Linux process. The kernel will now begin printing a large number of messages on the screen as it initializes the scheduler, irqs, console, hardware, etc. This is done in the start_kernel() function and nearly every kernel component is initialized by this function.

The kernel_thread() function is called next to start init. The kernel goes into an idle loop and becomes an idle thread with process ID 0.

Init

The first program that is run under the kernel is init. This program is always process with the pid 1. The Linux kernel can be told which program to use as init by passing the "init=" boot parameter. If this parameter is not specified, then the kernel will try to execute '/sbin/init', '/etc/init', '/bin/init' or '/bin/sh' in that order. If none of these exist, then the kernel will panic.

Runlevel Scripts

Linux generally has eight runlevels. Runlevel 0,1,6 and S are reserved for specific functions. More runlevels can be defined, but Unix has traditionally only used up to runlevel 6. Changing to runlevel 0 will halt the system and changing to runlevel 6 will cause a reboot. Runlevel S is for single user mode. It's important to note that runlevel S is not the same as runlevel 1. Runlevel 1 will run some scripts and then enter runlevel S. No scripts are run when entering runlevel S. It is for this reason that runlevel S is not meant to be entered directly with an already running system. Single user mode is most useful for making repairs or system changes.

The runlevel scripts can be setup in many different ways. I will be describing the layout used by Debian and many other systems. This layout is not much different then the others, but differences exist. I would encourage anyone who is interested, to take a look at their own system and trace out the process of booting these scripts. Having a good understanding of the boot scripts used on your system will aid greatly in your ability to understand the system as a whole.

At this point init is running and a default runlevel has been specified. The initial sysinit script has been run which has done things like setup networking, set the time, check filesystems and then mount them. A swap file will be mounted at this point as well. init now calls the script for the default runlevel. On my Debian system, the default runlevel is 2 which results in the 'rc' script being run with 2 as a parameter. This script and pretty much all the other boot scripts, are located in '/etc/init.d'. Each runlevel is given a directory to hold scripts for that runlevel and these directories are labeled rc0.d, rc1.d, rc2.d up to rc6.d. But having a copy of every script in each runlevel would be an administrative nightmare for maintaining, so these directories contain symbolic links that point to the real scripts. The real scripts are located in the '/etc/init.d' directory.

The symbolic links that are contained in these directories follow a specific naming convention.

<action><2 digit number><original name>

example: S40httpd

The link names will begin with an which will either be an 'S' or a 'K' that will signify whether to 'start' or 'kill' the daemon. If it is to be started, then the script is called with 'start' as a parameter. If it is to be killed, then the script is called with 'stop' as a parameter. A valid list of parameters for each script will be printed if one calls the script by itself.

When entering a runlevel, all the kill or stop scripts are run first before processing the start scripts. On bootup, things are a bit different. Because we have not come from another runlevel, all the kill or stop scripts are skipped. There is no need in stopping services that cannot be running in the first place. It should also be noted that a kill or stop script and a start script can exist for the same service in the same runlevel. This would cause the service to be restarted upon entering that runlevel.

Immediately following the identifier is a two digit number that indicates the order it is to be executed. The scripts are actually run in alphabetical order, so the lower numbered scripts are run first.

The name that follows the two digit number isn't necessary, but helps greatly in identifying the links.

Finishing up

Once init finishes with the startup scripts, it runs a getty process on each terminal specified in inittab. Getty is what you see when you are logging in. Once you enter your username, the getty process runs login, which in turn asks for your password.

Getty doesn't have to be run here though. It could instead be replaced with something else. If one wanted to build an Internet kiosk, they could replace it with a script that started XFree86 and then a web browser like Mozilla.

There are many ways in which one might want to change the boot behaviour and there can sometimes be many chances for speeding up this process. Having a good understanding of the Linux boot process will greatly aid in ones ability to effectively maintain it.

If anyone wishes for a truly in-depth look at the boot process from the viewpoint of the programmer, they should check out "Linux Kernel 2.4 Internals" which is in the Guides section at the Linux Documentation Project [1] (http://www.tldp.org/).

Summary:

1. BIOS

2. System reads the MBR (512 bytes) MBR has primary boot loader also known as stage1 boot loader.(446 bytes) Purpose: Identify and load the second stage boot loader or secondary boot loader Partition table (64 bytes)16 byte record for each partition.Each 16 byte contains provides information abt that partition like size, where it starts and ends and other info like it is active r not magic number (2 bytes) to check MBR The active partition is identified from the partition table and the control is transferred to the Boot Record of that partition.

3.The second stage boot loader resides in the BR of the partition.(Eg: GRUB or LILO) Refers to the /boot/grub.conf file for the path of the kernel image and initial RAM disk files Once this secondary boot loader is loaded into memory kernel image is invoked.

4. The kernel decompreses and starts to execute. (checking hardware and all peripherals, loading initrd image to memory)

5. /sbin/init

6. /etc/rc.sysinit

7. /etc/inittab

8. Starts the necessary process in /etc/rcx.d/ where x is the runlevel defined in inittab

9. starts mingetty

10./etc/issue

11.login process

12./etc/motd

The topic on Linux - How does a system boot is posted by - Honey

Hope you have enjoyed, Linux - How does a system bootThanks for your time