On a redhat system
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 explainatory boot process, please go to
• 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.
• 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
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.
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)
• start () in ‘linux/arch/i386/boot/bootsect.S’ (This is only run if Linux is booted
directly from a 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)
* This routine then invokes the startup_32 () routine in.
(/arch/i386/boot/compressed/head.S.) This sets up the basic environment.
* The kernel is then decompressed through a call to a ‘C’ function called
decompress_kernel() located in (./arch/i386/boot/compressed/misc.c).
* 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
* 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).
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
• 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-
• 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
• 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
from 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 ;). 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
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
• Linux Administration, A Beginner's Guide, Fifth Edition (Wale Soyinka)
Courtesy : Google.