Linux Basics – Linux Boot Process


Linux startup process is the process of Linux-operating system


“Linux Boot Process” is most discussed topic over internet. It includes Linux
internals. It is very important for Linux Administrator. Because most of the
troubleshooting is depend upon this.


note that in this article, I have explained everything for x86 platform.


Linux startup process is the process of Linux-operating system


Boot Process
” is most discussed topic over internet. It includes Linux
internals. It is very important for Linux Administrator. Because most of the
troubleshooting is depend upon this.


note that in this article, I have explained everything for x86 platform.


Phases of Linux Boot Process:


Phase1. From “Power
ON” to “Loading Kernel

Phase2. From “init”
to “Login prompt

Phase3. From “Login
prompt” to “Bash Prompt”


Phase1 – From
“Power ON” to “Loading Kernel”

Overview of Phase1:

Step 1-
When we power on PC, BIOS (which is stored on Motherboard) loads into RAM. The
purpose of BIOS is load OS or Kernel into RAM.

Step 2-
BIOS search for Bootable Device. When bootable device found goes to next step

Step 3- When
bootable device found it loads 1 stage Boot Loader i.e. MBR in RAM. Size of MBR
is just 512 bytes. just first sector of Harddisk

Step 4-
First stage boot loader loads Second stage boot loader i.e. GRUB or LILO

Step 5- When
second stage boot loader gets executed in RAM, Splash Screen gets displayed.
Job of second stage boot loader is to load kernel in RAM

Step 6- Stage
2 boot loader loads Kernel and optional initial Root FileSystem into RAM. It
passes control to Kernel and kernel get decompressed into RAM and get
initialised. At this stage second stage boot loader checks Hardware and mount
root device also loads necessary kernel modules. When it completes first Userspace
program gets executed i.e. init. init is father of all processes


Detail Phase1 process:

Step 1- BIOS boots up

     When we power on PC, BIOS (which is stored on MotherBoard) loads
into RAM.
The purpose of BIOS is load OS or Kernel into RAM.
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.



Step 2- BIOS boots up contd.

     BIOS performs Power On Self Test (POST). Here BIOS does Hardware

     Here, 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.


What is this MBR?



|    Boot Sector (BS)                    | 
Partition         |  Magic          |

|                                                |  Table (PT)       |  Numbers      |

|    446 bytes                              |  64 bytes          |  2 bytes        |

512 bytes ======================

                          M         B           R

     Size of MBR is 512

     Boot Sector is stored
in first 446 bytes.

Boot Loader resides here.

     Partition Table is
stored in next 64 bytes

     Last 2 bytes are for
Magic No. The magic number serves as a validation check of the MBR.


Step 3- MBR loads into RAM

     If the POST is successful, the BIOS calls INT 19H

     INT 19H is to load the sector at head 0,
cylinder 0, sector 1 i.e. MBR of Hard disk into memory at 0:7C00h, and transfer
control to it.

     After MBR gets loaded
into RAM, BIOS handover control to it.

     It loads First Stage
Boot Loader which resides in MBR


Step 4- Stage 1 Boot Loader
loads into RAM

     The job of the Stage
1 Boot Loader is to find and load the Stage 2 Boot Loader

     Stage 1 BL examines
Partition Table from MBR and search for Active Partition.

     It also scans
remaining to verify that they are all inactive.

     Active Partition’s
boot record is read from the device into RAM and executed.


Step 5- Stage 2 Boot Loader & Kernel

     The purpose of Stage
2 BL is to load OS kernel into RAM.

     Now here 2 major Boot
Loaders are available for Linux. i.e. LILO & GRUB. Here we w

     The main advantage of
GRUB over LILO is, GRUB has knowledge of Linux Filesystems. So GRUB can load
kernel directly from ext2 or ext3 filesystem. Whereas LILO uses RAW sectors on
the disk and it requires BIOS calls “int 13 fn 8” & “int 13 fn 2”.

     GRUB does this by
adding one more Stage after Stage 1 i.e. Stage 1.5.

o  Here Stage 1 BL loads Stage 1.5 (i.e. /boot/e2fs_stage1_5 to
load ext2 or ext3 FileSystem)

o  Stage 1.5 then loads Stage 2 BL.

o  Now GRUB has all the information about FileSystem.

     Stage 2 BL then
request to display a list of available kernel (Defined in /boot/grub/menu.lst)

is also called GRUB startup menu, which allows the user to choose an operating
system and examine and edit startup parameters.

     After an operating
system is chosen, respective kernel gets loaded into RAM and Stage 2 BL passes
over the control.

     Here Stage 2 BL
uncompresses Kernel and fills the memory with kernel memory structures which
can be seen in the /proc virtual file system


The Engine Of The Car Is Ready And

The Linux OS is ready and running!!
Kernel Land is ready!!

But No User land!!


Phase2. From
“init” to “Login prompt”.

     When the kernel is
loaded, it immediately initializes and configures the computer’s memory and configures
various hardware attached to the system, including all processors, I/O
subsystems, and storage devices. It then looks for the compressed “initrd
image” in a predetermined location in memory, decompresses it, mounts it, and
loads all necessary drivers.

     After this the kernel
locates & starts the first user-space application “/sbin/init”

     “Init” is the Father
of all Processes. Its PID is “1”


     Before /sbin/init
loads into RAM, it reads /etc/inittab file

     /etc/inittab is ASCII
text file. Where we can configure multiple parameters for init daemon

     If you take close
look of /etc/inittab, you will find below entries there ->





id:5:initdefault:                     —- > Defines Default Runlevel.

                                                                                     Here it is

# System initialization

si::sysinit:/etc/rc.d/rc.sysinit      —- >  Executes
/etc/rc.d/rc.sysinit in subshell

                                         I have explained below about rc.sysinit

l0:0:wait:/etc/rc.d/rc 0

l1:1:wait:/etc/rc.d/rc 1

l2:2:wait:/etc/rc.d/rc 2

l3:3:wait:/etc/rc.d/rc 3

l4:4:wait:/etc/rc.d/rc 4

l5:5:wait:/etc/rc.d/rc 5

l6:6:wait:/etc/rc.d/rc 6



ca::ctrlaltdel:/sbin/shutdown -t3 -r


# When our UPS tells us power has
failed, assume we have a few minutes

# of power left.  Schedule a shutdown for 2 minutes from now.

# This does, of course, assume you
have powerd installed and your

# UPS connected and working correctly.

pf::powerfail:/sbin/shutdown -f -h +2
“Power Failure; System Shutting Down”


# If power was restored before the
shutdown kicked in, cancel it.

pr:12345:powerokwait:/sbin/shutdown -c
“Power Restored; Shutdown Cancelled”


# Run gettys in standard runlevels

1:2345:respawn:/sbin/mingetty tty1

2:2345:respawn:/sbin/mingetty tty2

3:2345:respawn:/sbin/mingetty tty3

4:2345:respawn:/sbin/mingetty tty4

5:2345:respawn:/sbin/mingetty tty5

6:2345:respawn:/sbin/mingetty tty6


# Run xdm in runlevel 5

-nodaemon    -> this line will get
executed for

runlevel 5



in new subshell.


o  calls /etc/sysconfig/network in same shell

sets the hostname and checks whether Network is yes or no i.e. checks for
existence for Network card

o  calls /etc/init.d/functions script in the same shell.
It sets global umask and path and defines 27 shells functions within the
rc.sysinit shell environment

o  Displays the “Welcome to Red Hat…” from

o  Runs dmesg* which creates /var/log/dmesg and display its
contents on the screen

o  Mounts all local filesystems from /etc/fstab and updates
“mount” command simply displays the contents of /etc/mtab

/etc/rc.d/rc.sysinit script ends!!


Summary:  rc.sysinit:   1.
Sets the global umask, global PATH

2. Sets up the Networking subsystem

3. Basically starts the
System Daemons




Back to /etc/inittab:


script is executed in a new subshell of /etc/inittab


o  It starts and stops the
Application Networking daemons, by using Init Scripts

These init scripts are
stored under /etc/init.d/

Their symlinks are created
in all /etc/rc.d/rc?.d/directories

If name of the symlink in
/etc/rc.d/rc?.d/ starts with “S” then those services will get start system

If name of symlink in
/etc/rc.d/rc?.d/ starts with “K” then those services will get stop when system


If you want any service to
start when system boots up then use below command:

# chkconfig –level <No> <service name> on

# chkconfig -level 3 gpm on 
— > Enabling GPM service


o  It runs /etc/rc.d/rc.local
which is a symlink in all RLs and is the only script which is run regardless of
the RL and is  “S99local” in all
/etc/rc.d/rc?.d/… and points to



     Goes back to inittab


     shutdown CAD magic
keys are set –  You can hack it if you


ca::ctrlaltdel:/sbin/shutdown -t3 -r


     mingettys are
spawned with their terminals. All mingettys enter sleep state – EXCEPT one

And here you get a LOGIN


     If Runlevel 5, then
script “
is executed..




Phase3. From
“Login prompt” to “Bash Prompt”


 Now mingettys are loaded


What is getty?


A getty is is a program that
opens a tty port, prompts for a login name, and runs the /bin/login command. It
is normally invoked by init.


The mingetty daemon is used
to listen for virtual consoles (like the 6 that run by default with your
keyboard and monitor) and cannot be used to handle serial lines


You will need to configure
agetty or mgetty to listen on the serial ports, because they are capable of
responding to input on physical serial ports.



How do you get Login Prompt?


     The first mingetty [awake
one] loads device driver for /dev/tty1 & executes /etc/issue

     mingetty then
executes the /bin/login process and is then put to sleep state by init

     /bin/login displays
login prompt.


Towards Bash prompt ->


     /bin/login execs
/usr/bin/passwd which challenges for passwd from user which then does
authentication and authorization using PAM


     init then puts the
login daemon into sleep state, wakes up mingetty which now takes over


     mingetty checks for
.hushlogin in $HOME/$USER


If $HOME/.hushlogin DOES NOT
EXISTS then it does the following:


– executes “lastlog* -u $USER” using /var/log/lastlog

– executes “cat /etc/motd”

– executes users mail, if any, in /var/spool/mail/$USER

    init then wakes
/bin/login process


     mingetty then goes
into zombie state and is killed by init


     login then loads
/bin/bash as a monitored child process   


     /bin/bash takes over


     and login goes into
sleep state


     Executes /etc/profile
-> sets system-wide ENV variables Global Profile


     Executes /etc/inputrc
-> Sets keyboard mappings  [See stty
-a] Show Terminal characteristics


Examples ->      # stty
intr ^g   –> Keyboard mapping

                                                # stty -echo     –> Terminal Characteristics



#/etc/inputrc See man bash – /bell-style


                                                     set bell-style [audible] [none] [visible]

                                                     set disable-completion [off] on


                                                To do it per-user:


setterm -blength 0 [in per user .bash_profile]


xset b off [in GUI]



/etc/profile.d/*.sh [16 shell scripts are executed]










     Executes /etc/bashrc
– Sets system-wide [Global] aliases/shell functions

sets the users and root’s
final global umask

     Executes user’s
personal .bash_profile

     Executes .bashrc   -> user specific Bash initialization
file. It resides at every users home directory. And gets executed when you
successfully login to the Linux system.


     Misc :

o  .bash_history  -> It stores all command history

o  .bash_logout   -> It stores logout logs. It gets
executes while Logoff.



Finally, at last, the
comforting shell login prompt bash!!


Process Ends========================

Enhanced by Zemanta

Neelesh Gurjar has written 122 articles

Leave a Reply