Enter your email address:

Delivered by FeedBurner

How Linux Boots


Most people don’t understand the basics behind how their computers boot up when they first turn them on. Most Windows users think that when you start up your system, it runs NTLDR, which in turn reads the BOOT.INI configuration file. While this is the most obvious and observable way most of us understand the PC startup process, there’s a lot more going on underneath. And it’s in the nuts and bolts that Linux differs significantly from Windows when a system starts up.

What Everybody Does
When you press the power button on your system, it initializes all hardware devices and goes through a series of tests, commonly known as POST. These tests naturally run before any operating system is loaded. Once the POST is finished, the hardware looks for the first available bootable device on the available hardware. Systems today let you boot from a CD, hard removable device, or even network devices. A bootable device is something where the first 512 bytes contain boot information about the actual device itself. This is known as the boot sector of the device; for hard drives, it resides in the MBR (master boot record), which is before the partition information. Once the system finishes its POST, it reads the data in the MBR and then executes the code. Up until this point the Windows and Linux boot up procedures are identical. What happens next depends not only on what operating system you use, but also, in the case of Linux, which boot loader you use. With recent Windows installations, the MBR code will load NTLDR, which reads the BOOT.INI configuration file. This file contains information for different installations of Windows, as well as parameters to be passed to those installations. A Linux user has two popular boot loaders available: LILO (Linux Loader) and GNU GRUB. LILO is one of the earliest Linux boot loaders and is rarely used in newer Linux installations. Most modern Linux distributions use GNU GRUB, or GRUB for short, as their boot loader, due to its ease of use and configurability.

Boot From LILO
But let’s go back to the beginning and cover how LILO works, because a lot of legacy systems still have it. As with most boot loaders, LILO is much too big to fit into 512 bytes and so is loaded in stages. The first stage is when the initial 512 bytes are loaded from the boot sector on the hard drive. The purpose of this stage is to get things started and to load the next stage. LILO gives you a status of what stage it’s in based on how many letters in its name it’s shown. The first “L” indicates that the first stage has loaded. Just before LILO is ready to go onto the loader in the next stage, it displays an “I.” If LILO hangs with just an “LI,” it typically means that the file that LILO is expecting can’t be found. The disk might be damaged or perhaps the file has moved. But assuming everything’s fine, the secondary loader is executed and the second “L” will appear. The second stage boot loader for LILO is where the guts of the boot process occur. Here the secondary stage loader reads in the Lilo.conf file, which tells LILO where its various parts are and different boot options. The second stage loader also reads in what is known as a map file. The map file contains a collection of locations for the bootable partitions, including each partition’s respective disk. When LILO has successfully loaded the map file, it’ll display the “O” in its name and you’ll see a “boot:” prompt. At the “boot:” prompt, simply type the name of the operating system you want to run and press ENTER. If you’re not sure what OSes are on your system, press the TAB key. If you don’t make a selection after a little while, it’ll boot the first Linux OS it can find. If you want to change the display name of the available operating systems, or the timeout to boot the default OS, you’ll need to modify LILO’s configuration file, /etc/lilo.conf. LILO depends very heavily on the configuration file for all of its bootup information, so any changes to Lilo.conf can potentially make it impossible to boot next time. But don’t worry about making changes to Lilo.conf; there’s a GUI utility to help you with those things. If you’re using the KDE window manager, click the KDE icon and then select Control Center. Expand the System Administration heading and then select Boot Manager (LILO). This will give you a handy graphical utility with which to manipulate the Lilo.conf file. You can add, delete, and edit entries in the Lilo.conf file, and it’ll handle the grunt work of making it work.

Get GRUBby
In 1995 the Free Software Foundation created a specification on how boot loaders should interact with operating systems. To demonstrate the specification in action, GNU GRUB, or simply GRUB for short, was created. Like LILO, GRUB is too big to fit into 512 bytes and thus loads in stages. GRUB’s stage 1 loader is functionally identical to the first stage of LILO boot loader: Its goal is to load the next stage. But what happens next with GRUB depends on what type of operating system the stage 2 loader sits on. Most Linux flavors default to using the ext2 or ext3 file systems when laying out a disk. In these cases the GRUB stage 1 loader will load up the stage 2 loader without any problems. If you have Linux loaded on some other file system, such as xfs, jfs, fat, or reiserfs, then the GRUB stage 1 loader will load the stage 1.5 loader. The only purpose of the stage 1.5 loader is to act as a bridge between the stage 1 and stage 2 loaders. That is, the GRUB stage 1.5 loader knows enough about the underlying file system to run the stage 2 loader. Once the GRUB stage 1.5 loader has run, it’ll load the GRUB stage 2 loader. The GRUB stage 2 loader is where most of the action happens with GRUB, and it’s what most people think is GRUB. Here, the user is given a text menu with a list of available operating systems, and whichever one he chooses gets loaded. GRUB offers a number of improvements over LILO, such as the ability to specify an unlimited number of operating systems and boot from a network device. But perhaps best of all is that, unlike LILO, you can easily modify the GRUB configuration file without having to reinstall GRUB or play around with the boot sector. Because GRUB is newer, it has its own set of GUI tools to help modify its configuration file. A popular one is the KGRUBEditor, which requires the KDE 4 libraries to run. When you run it, all of the bootable entries in GRUB’s initial text menu are shown. As with the KDE Boot Manager for LILO, you can add, delete, or edit entries, and it’ll take care of the configuration files themselves.

Still Not In Linux
So after we’ve run either LILO or GRUB through its paces to boot the operating system, the Linux kernel is loaded, right? Wrong. Linux is designed to try and run on as many different systems as possible. It does this by having a large library of modules to enable different features. But due to the sheer number and size of modules, they can’t all be available at boot time. Also, Linux has some special features that require special work before they can be fully utilized, like booting off a network device. To address these situations, after you’ve gone through all of the boot loaders, you haven’t really loaded Linux yet. Instead, you will actually boot into a very small Linux kernel with just enough drivers to get the real Linux kernel started. This small Linux kernel is known as the initial ramdisk, or initrd for short. Once initrd has loaded, it moves itself out of the way, loads the real Linux kernel, and then deletes itself from memory. Only after initrd has freed itself from memory have you truly booted into Linux. Most people have probably never thought about how Linux boots up, so they’ve been stuck if it doesn’t boot. But after reading this, if your Linux box doesn’t boot, you at least now know where to go looking to troubleshoot the problem.

Source of Information : CPU Magazine 07 2009


Post a Comment

Alltop, all the top stories
All Malaysian Bloggers Project
Computer Blogs - BlogCatalog Blog Directory Add to Technorati Favorites
Technorati Profile
Top Computers blogs