On a redhat system Oct, 2010 ashwinwriter@gmail.com Note : Though I mentioned ‘redhat’ system, the boot process is more or less the same across Linux-based OSes. What follows is the semi-fast run down of the Linux boot process, if you are looking for a more detailed explanatory boot process, please go to Google.

• Power is turned on.

• CPU is reset.

Sorry to interrupt here : Until I experienced wisdom, I always believed that the first thing that starts on the computer system is BIOS, and the rest of the stuff including CPU follows. I know it sounds stupid! Wisdom : When the computer is turned on, it is practically useless because the RAM chips contain random data and no operating system is running. To get the BIOS running, somebody has to process the instruction, and there comes the CPU. So, the CPU manufacturers pre-programed the processor to always look at the same place in the system BIOS ROM for the start of the BIOS program. Therefore, CPU comes first and then what it executes is popularly known as BIOS. Let’s move on…

• Some registers on the CPU are set to fixed values, One of the registers is the

instruction pointer register, and its value is well defined: it is a 32-bit value of 0xfffffff0. The instruction pointer register points to code to be executed by the processor.The address is mapped by hardware to BIOS ROM chip.

BIOS begins…

• CPU executes the code at this well-known physical memory address 0xfffffff0 which corresponds to a read-only memory chip (ROM) that contains a suite of programs traditionally called BIOS.

BIOS is made up of two parts: the POST code and runtime services. After the POST is complete, it is flushed from memory, but the BIOS runtime services remain and are available to the target operating system.

• To boot an operating system, the BIOS runtime searches for devices that are both

active and bootable in the order of preference defined by the complementary metal oxide semiconductor (CMOS) settings. A boot device can be a floppy disk, a CD-ROM, a partition on a hard disk, a device on the network, or even a USB flash memory stick.

• BIOS invokes its ‘bootstrap’ loader function, which copies the first sector of the

bootable device (Usualy floppy drive or hard disk, as determined by the BIOS CMOS settings) at physical address 0x00007C00, then executes the code at this address.

What is bootstrap ? Origin-The origin of this descriptive phrase isn't known. It refers of course to boots and their straps (laces) and to the imagined feat of a lifting oneself off the ground by pulling on one's bootstraps. This impossible task is supposed to exemplify the achievement in getting out of a difficult situation by one's own efforts. Some early computers used a process called bootstrapping which alludes to this phrase. This involved loading a small amount of code which was then used to progressively load more complex code until the machine was ready for use. This has led to use of the term 'booting' to mean starting up a computer.

In the most commonly found computer literature, the term ‘bootstrap’ denotes bringing at least a portion of the operating system into main memory and having the processor execute it.

Note: BIOS also provides several functions for handling low-level devices' input and output. However, Linux kernel provides its own mechanisms for handling these low-level tasks.This is due to the fact that, kernel executes its operations in protected mode, whereas BIOS works in read-mode.

• With the first sector of MBR (1st Stage of GRUB also called Grub’s MBR) in memory, bootloader makes an entry….. (More on Grub’s MBR on Page 3)

What is a boot loader? Most simply, a boot loader loads the operating system. For Linux based OSes, this means either LILO (LInux LOader) Or GNU GRUB (GRand Unified Boot loader), and both are called multi-stage bootloaders. Among the two options, Grub has become the most popular one due to the fact that it is more interactive and it understands various filesystem, which the former did not. Hence, GRUB is currently the undisputed king in multi-stage bootloading. Besides Multiboot, it can boot Linux and BSD kernels and chainload anything else.

Stage 1 (boot loader) begins.. • The job of the Stage1 boot loader is to find and load the secondary boot loader

(Stage 2) from the Parition boot sector. This boot record is read from the device into RAM and executed.

Note: But, there is another Intermediate stage, between the common boot loader stages one and two (Called, the Stage 1.5). Stage 1.5 is there to enable regular file system access to the GRUB configuration files in /boot/grub/grub.conf rather than accessing using disk blocks (In case of Lilo) and hence it enables us to view and interact with the menu file. We then enter stage two of the boot loader where GRUB loads the contents of the file grub.conf. Note: The location of stage 1.5 Or stage 2 are hardcoded into the Stage 1.

Stage 2 (boot loader) begins.. The secondary, or Stage 2 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 (initrd). Currently, GRUB is the de facto standard bootloader of Linux, and is expected to be superseded by GRUB2 in the near future. When this happens, "GRUB" will become "GRUB Legacy". It is responsible for loading and transferring control to the Linux kernel. The kernel, in turn, initializes the rest of the operating system. We used the word Grub's MBR in previous page, In order to differentiate from the generic Windows boot loader, In which a bootloader scans through the partition table looking for a parition marked active and then loads it. Grub Stage 1 only has the (address) instruction to load Stage1_5 Or 2 hardcoded but due to the standard MBR requirements and BIOS geomatry It follows a similar enclosure. Hence, its stage1 code follows the structure of all MBRs by placing the standard four-entry Partition Table in its agreed upon location (offsets 01BEh through 01FDh) which is followed by the standard Word-sized signature ID of AA55h). This word-sized signature is what BIOS looks for in order to determine the bootable device. Unlike many bootloaders, GRUB can function as either a Master Boot Record (when installed in the first sector of a PC's /dev/hda device; that is, its Primary, Master hard disk) or as a Volume boot record, b’cos it never bothers to relocate its code, since there will be no other VBR code that needs to be immediately loaded at Segment Offset : 0000:7C00. Only after GRUB is fully operational (i.e., running elsewhere in memory), would it possibly need to perform a chainload of some OS's boot record that might require use of this area of memory. Isn’t that cool!

GRUB Summary :

• Loads the stage1 from the Grub’s MBR (Frist 512 bytes) • Then loads stage1_5 (if necessary) • Then loads stage2 (directly from /boot/grub/ directory on partition disk) and

presents the contents of /boot/grub/menu.lst Or grub.conf. file in a Menu form.

Note: Pressing any key on this screen will stop the timeout from kicking in, this may be required if you are troubleshooting Or simply wants to hand-load the OS and would like to tweak the kernel arguments to suit your needs. To be noted - Any changes you make in edit mode are not saved to the ‘grub.conf’ file. Oops...Its becoming too verbose, any extra words on this section is beyond the scope of this article. This is suppose to be a semi-fast run-down, and it’s going very very slow.

KERNEL Begins.. 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 yet, 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. Let’s deal with the most common one: bzImage (big zImage) The bzImage was compressed using the zlib algorithm until Linux 2.6.30 which introduced more algorithms, which is composed of bbootsect, bsetup and bvmlinux (head.o, misc.o, piggy.o) When the bzImage (for an i386 image) is invoked, you begin at ....

• start () in ‘linux/arch/i386/boot/bootsect.S’ (This is only run if Linux is booted directly from a floppy diskette).

• If booting from harddisk: start() in ‘linux/arch/i386/boot/setup.S’ (setup.S is

responsible for getting the system data from the BIOS and putting them into appropriate places in system memory, arranges the transition from the processor running in real mode (DOS mode) to protected mode (full 32-bit mode).

• This routine then invokes the startup_32 () routine in.

(/arch/i386/boot/compressed/head.S.) This routine sets up a basic environment (stack, etc.) and clears the Block Started by Symbol (BSS).

* The kernel is then decompressed through a call to a ‘C’ function called decompress_kernel() located in (./arch/i386/boot/compressed/misc.c).

What we did just now

This code sets up the registers, decompresses the compressed kernel, printing the famous following 2 lines from linux/arch/i386/boot/compressed/misc.c Uncompressing Linux... Ok. Booting the kernel. * When the kernel is decompressed into memory, yet another startup_32 function is called, but this function is located in (./arch/i386/kernel/head.S.)

* In the new startup_32 () function (also called the swapper or process 0), the page tables are initialized and memory paging is enabled. The type of CPU is detected along with any optional floating-point unit (FPU) and stored away for later use.

* The start_kernel () function is then invoked (init/main.c), which takes you to the non-architecture specific Linux kernel.That means "No operation is included in this function that involves hardware specific elements” hence non-architecture). This is it, ‘linux kernel’ begins now.

• With the call to start_kernel, a long list of initialization functions are called to set up interrupts, perform further memory configuration, and load the initial RAM disk. During the boot of the kernel, the initial-RAM disk (initrd) that was loaded into memory by the stage 2 boot loader is copied into RAM and mounted. The initrd serves as a temporary root file system in RAM and allows the kernel to fully boot without having to mount any physical disks. Since the necessary modules needed to interface with peripherals can be part of the initrd.

By the way, What is Initial Ram Disk ? An initial ramdisk (In short initrd) is a temporary file system (before the real root file system) used in the boot process of the Linux kernel. Why is it required ? Many Linux distributions ship a single, generic kernel image that is intended to boot as wide a variety of hardware as possible. The device drivers for this generic kernel image are included as loadable modules, which in turn is bundled into Initial RAM disk (initrd image). Continues..

At boot time these drivers are loaded as modules, not from the hard disk, but from an initial RAM disk. After doing that, the kernel would switch to the real root device (the hard disk). Without an initial RAM disk you would need the hard disk drivers (there are many possible SCSI host adapters) and the file system drivers compiled into the kernel, as it is not possible to statically compile them all into the one kernel without making it too large to boot from computers with limited memory.

• In the end, a call is made to kernel_thread located in

in (arch/i386/kernel/process.c) to start the init () function, which is the first user-space process

• Finally, the idle task is started and the scheduler can now take control (after the

call to cpu_idle). With interrupts enabled, the pre-emptive scheduler periodically takes control to provide multitasking.

• When init starts, it becomes the parent/grand parent of all the processes that start

up automatically on the linux system.

• The first thing init does, is reading its initialization file, located in /etc/initab file.

• This instructs init to read an entry for the initial configuration script

(si::sysinit:/etc/init.d/rcS) in the /etc/initab file, which sets the path, starts swapping, check the files system, and so on. Basically, this step takes care of everything that the system needs to have done at system initialization.

Next, init reads an entry for the default (id:3:initdefault:) run level of the system in the /etc/initab file, and starts all of the processess necessary for the system to run by looking at the appropriate run level subdirectory. For each runlevel, a subdirectory exists in the /etc/rc.d directory.

What is Run Level ? A Run level is basically a "configuration of processess". All UNIX-like sytem can be run in different process configurations, such as single user mode, which is reffered to as run level 1, Or run level s/S. In this mode only system administrator can connect to the system. It is primarily used to perform maintenance tasks without risks of damaging the system or user data, and also for the troubleshooting purposes. Naturally, in this configuration we don't need to offer user services, so they will be disabled. There are six run levels, out of which 1 & 6 are reserved and the fourth is not used.

Reason behind creating a subdirectory: Because of the number of services that need to be managed, “rc” scripts are used. The main one, /etc/rc.d/rc, is responsible for calling the appropriate scripts in the correct order for each runlevel. As you can imagine, such a script could easily become extremely uncontrollable! To keep this from happening, a slightly more elaborate system is used. Hence, for each runlevel, a subdirectory is created under the /etc/rc.d directory. These runlevel subdirectories follow the naming scheme of rc X .d, where X is the runlevel. For example, all the scripts for runlevel 3 are in/etc/rc.d/rc3.d.However, all the processes/services are symbolicly linked to scripts in the /etc/rc.d/init.d directory. That means, you can excute the same scripts manually after the system has finished booting with a command like /etc/init.d/httpd stop or service httpd stop logged in as root. In this case stopping the “web server”.

• init runs each of the kill scripts (File names for these scripts starts with a K letter)

which indicates a stop parameter. • It then runs all of the start scrits (File names for these scripts starts with a S letter)

which indicates a start parameter.

Note: These two letters (K & S) are casesensitive.You must use uppercase letters, or the startup scripts will not recognize them.

• When init has finished with the runlevel scripts, it reads a configuration file

(/etc/ttytab) to see which terminals and virtual terminals exist. init forks a getty process for each one, displays a login prompt on it, and then waits for input. When a name is typed, getty executes a login process with the name as its argument. If the user succeeds in logging in, login will execute the user's shell , and with that shell becomes the “child of init”.

• User commands create children of the shell, which are “grandchildren of init.

This sequence of events is an example of how process trees are used.

• On most rpm-based systems the graphical icon screen is started in run level 5, where /etc/initab runs a script called /etc/x11/prefdm. This script runs the prefered x display manager, based on the /etc/sysconfig/desktop directory. This is typically "gdm" if run GNOME, Or KDM if you run KDE console.

• THE END.

Unfortunately, it ended up being one of those lengthy articles (never inteded though), but to be very honest, this is just a summary of how boot process works, and there books on this subject detailing each step in absolute depth, but I do not see any reason to go that deeper unless you are a developer or an over-enthusiast. Like open source Linux, this material is openly sourced from various wonderful articles available on the net, (Just kidding ;) but that’s true. The problem was, none had everything that I was looking for at one place, here I am talking in sence of ‘easy to grasp’ language, and some confusions that never got answered back by the authors I wrote to, but then they must be dealing with 100s of emails in their Inbox everyday, fair enough. So, all I have done is, arranged the picked-up notes in an order that I thought made it easier to understand the whole process. This is just another article in addition to 100s & 1000s of articles on the same subject, as with all the articles, there is nothing like a best article, what suits one, may not suit another, it all depends on the individual. Hence, read through all the articles and then pickup the stuff you find it easier and put things together the way you understand it better. Finally, there is nothing like working live on linux, therefore get a hands-on experience to see yourself how things work. Have fun! If I have missed out on any article due for credit, please bring it to my notice, and I shall include them as a reference material. Though, there is no bigger reference pointer than the Google. References:

• http://en.wikipedia.org/wiki/Linux_startup_process • http://www.ibm.com/developerworks/linux/library/l-linuxboot/ • http://www.xs4all.nl/~lennartb/bootloaders/node4.html • http://mirror.href.com/thestarman/asm/mbr/GRUB.htm • http://www.ibm.com/developerworks/linux/library/l-bootload.html • Linux Administration, A Beginner's Guide, Fifth Edition (Wale Soyinka) • http://oss.sgi.com/LDP/HOWTO/Kernel-HOWTO/linux_boot_process.html • http://en.wikipedia.org/wiki/Initrd

Courtesy : Google. ashwinwriter@gmail.com