Welcome to Linux Forums! With a comprehensive Linux Forum, information on various types of Linux software and many Linux Reviews articles, we have all the knowledge you need a click away, or accessible via our knowledgeable members.
Find the answer to your Linux question:
Site Navigation
Linux Forums
Linux Articles
Product Showcase
Linux Downloads
Linux Hosting
Free Magazines
Job Board
IRC Chat
RSS Feeds
Free Publications

Introduction: The Linux startup process is the process of Linux-operating system initialization. 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. Please note that in this article, I have explained everything for x86 platform.

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 Inventory.
-    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 bytes.
-    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)
It 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 Running!!
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 5

# 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 now

# 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
x:5:respawn:/etc/X11/prefdm nodaemon    -> this line will get executed for
runlevel 5

-    /etc/inittab executes /etc/rc.d/rc.sysinit in new subshell.

o    calls /etc/sysconfig/network in same shell
It 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 /etc/redhat-release
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 /etc/mtab
mount command simply displays the contents of /etc/mtab
Now /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:

-    /etc/rc.d/rc 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 boots.
If name of symlink in /etc/rc.d/rc?.d/ starts with K then those services will get stop when system boot.

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 wish

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

-    mingettys are spawned with their terminals. All mingettys enter sleep state - EXCEPT one
And here you get a LOGIN PROMPT.

-    If Runlevel 5, then script " /etc/X11/prefdm" 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]
[bash -r, --noediting as args in /etc/passwd 7th field]

-    Executes /etc/profile.d/*.sh [16 shell scripts are executed]
colorls.csh    colorls.sh
glib2.csh    glib2.sh
gnome-ssh-askpass.csh    gnome-ssh-askpass.sh
krb5-workstation.csh    krb5-workstation.sh
lang.csh    lang.sh
less.csh    less.sh
vim.csh    vim.sh
-    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!!

============================Boot Process Ends here================================

Rate This Article: poor excellent
Comments about this article
This article is incomplete
writen by: neel.gurjar on 2011-07-13 00:39:58

This article is not complete
RE: This article is incomplete written by neel.gurjar:
Boot Process
writen by: pras85 on 2011-07-14 01:12:07
Hi Neel,

I have recently joined this linux forums to gain more idea about linux.. I have recently done with my red hat certification in the month of FEB.. Hope more job opportunities are available in the linux world.. Practically i am not too strong. At the time of certification preparation i worked a lot based on the dumps they provided. But i fear that i dont have much experience as iam not practising. I am very much interested to proceed my career with Linux. Kindly suggest me on how to proceed..

My E-MAIL ID:prasanna_g60@yahoo.com

Boot process concept is well explained. Can u get me some nice materials where i can understand easily.. You can share it to my ID..
RE: Boot Process written by pras85:
Phase2 Correction
writen by: evinrude on 2012-01-26 07:31:05
The article suggests that once the kernel is finished it fires /sbin/init and the runlevel is determined by the /etc/inittab file.

1. /init actually gets executed first in the initrd/initramfs. If this does not exist, then in order, the kernel tries to execute (/sbin/init, /etc/init, /bin/init, and finally /bin/sh). Additionally, you can tell the kernel where your init script/executable is by passing the init= option on the kernel command line.

2. The sole purpose of the initrd/initramfs is to locate and mount the root file system and pass control to the init executable in that root file system. In order for this to occur, the intiramfs/initrd may have to load kernel modules, start up udev (populate the /dev directory or execute the old school MAKEDEV), intelligently figure out where the root file system is, and perform any other business such as selinux policy loading before the switch_root occurs. The root file system becomes the leader and the initrd/initramfs is wiped from memory.

3. Once init on the root filesystem takes control, it reads the inittab and your runlevel is determined unless it is overridden on the kernel cmdline
RE: Phase2 Correction written by evinrude:
RE: Phase2 Correction
writen by: neel.gurjar on 2012-08-25 23:42:50
Thanks evinrude
Reply to neel.gurjar:
rc.sysinit file not found in fedora 15
writen by: shivkamal on 2012-04-15 15:03:01
I am using fedora 15 in oracle virtual box. When I tried to study boot process in fedora 15 I did not find /etc/rc.d/rc.sysinit file in it.
Since there are many major changes are done in Fedora 15 and 16. (inittab file is no more in use), please guide me if rc.sysinit file is relocated to another path or if it is changed.

Thanks in advance..

RE: rc.sysinit file not found in fedora 15 written by shivkamal:

Comment title: * please do not put your response text here