Stages of Linux booting process – explanation, step by step tutorial

Have you ever wondered about the processes behind a system boot up? Yeah, as a SysAdmin, it’s very important to know about the steps and the processes in every steps while a machine boots up. If you are a good SysAdmin, you must have a better knowledge in Booting Process.

In this article, I am going to explain the booting process in detail. I can assure you that, you will get a clear idea about the Linux booting process after reading this post. I would like to divide the Linux booting in the following 5 steps:

From power up/reset to login prompt, we can mainly divide the Linux booting process in to five areas. The BIOS, Stage I boot loader, Stage II boot loader, Kernel and Init. These are the important areas behind a booting process.

Let us start the Linux booting process with BIOS.

Step 1. BIOS (Basic Input Output System)

In this article, I am explaining the Linux booting process with BIOS as the first steps. Not based on UEFI. Both UEFI and BIOS are low-level software that starts when you boot your PC before booting your operating system, but UEFI is a more modern solution, supporting larger hard drives, faster boot times, more security features, and—conveniently—graphics and mouse cursors.

Alright, we can go ahead with BIOS. It is a pre-installed firmware on a system/server’s Mother board. BIOS controls the computer hardware. BIOS is used to perform hardware initialization during the booting process. The main job assigned to BIOS is POST (Power On Self Test). It’s a hardware self test. POST tests are simple read/write tests of a few location.

The POST tests are not much useful as a Hardware diagnostic test. It just test the system hardware components, and loads a boot loader.

The main two errors occur during POST are:

  1. Fatal error. This occurs due to hardware problems.
  2. Non fatal error. Due to software problems.

Main responsibilities of BIOS during POST are listed below:

  1. Verify CPU registers.
  2. Verify the integrity of the BIOS code itself.
  3. Verify some basic components like DMA, timer, interrupt controller.
  4. Find, size, and verify system main memory.
  5. Initialize BIOS
  6. Identify, organize, and select which devices are available for booting.

The beep sound after the POST indicate its result. A short beep while restart/start means normal POST – system is OK. Two short beeps means POST error – error code shown on screen and so on. Check POST manual for more details.

BIOS act as an intermediary between computer CPU and Input/Output devices. This eliminates the need for the operating system and software on the system/server are always aware about the details of hardware and other I/O devices. If any harddisks or I/O devices changed, only the BIOS needs to be updated.

BIOS is stored in EEPROM (Electrically Erasable Programmable ROM) / Flash memory. BIOS can not stored on a  hard disk or other devices, because it manages those devices.

BIOS is written in assembly language.

Remember, POST, that is the main thing happen at BIOS stage of booting. Next we can move to 1st boot loader stage, MBR stage.

Step 2. Stage 1 boot loader (MBR)

Master Boot Record, is the first place where boot loaders begins to start. MBR is a 512 byte sector located in the first sector of hard disk. MBR contains both program code and partition table details. Please see the image added below:

When allocating disk space for a partition, the first sector or data unit for each partition is always reserved for programmable code used in booting process. The very first sector of the hard disk is reserved for same purpose and it’s called the Master Boot Record. In case of a mechanical spinning disk, sector 1 of cylinder 0, head 0.

First 446 byte are the primary boot loader which contains both executable code and error message text.

Next 64 bytes contains the partition table. This section contains records for each of four partitions. In the above image P1 represents Partition 1, P2 for Partition 2 and so on.

4 x 16 bytes = 64 bytes

The last two bytes known as magic number (0xAA55). This number is used for the validation check of MBR.

When booting from a hard disk, the BIOS starts by loading and executing boot loader code. The MBR size is not enough sometimes to execute the complete boot loader code. Because, its size is larger than the available space in MBR. So booting has to be done in different stages. These stages are different in different boot loader on your system. Yeah, it’s time to move over to Stage 2 boot loader

Step 3. Stage 2 boot loader.

It is called the kernel loader. The main task at this stage is to load the Linux kernel.

Different boot loaders

LILO : Linux Loader.
GRUB : Grand Unified Boot Loader.

We use GRUB, as LILO has some disadvantages. One great thing about GRUB is it has knowledge about the Linux file system. GRUB can load kernel from an ext2 or ext3 file system.

As we mentioned, the boot loader code is executing in different stages because of the size limit of MBR. This stages are different in different GRUB version. These stages are mainly listed as follows:

  1. Stage 1 and Stage 2 : These are two essential stages
  2. Stage 1.5 : An optional stage

Stage 1 is an essential image used to boot up a Linux machine. Usually, this is embedded in an MBR or the boot sector of the partition. The maximum size of stage one image is 512 bytes, because of the MBR size limit.

Stage 1 does not understand file system. It loads stage 2 or stage 1.5 from local disk for further booting process. So it knows Linux file system details.

Stage 2, this is the core image of GRUB. Usually, you can find this stage in a file system (Not necessary). Stage 1.5 is actually a bridge between Stage 1 and Stage 2.  Stage 1.5 will be installed into an area right after the MBR area.

Boot loaders are loading from Stage 2. So you must know some basic details of Linux boot loaders. The common boot loaders in Linux are listed below:

  1. LILO (Linux Loader)
  2. GRUB (Grand Unified Boot Loader)

Nowadays almost all Linux distributions are using GRUB as boot loader. The latest GRUB is GRUB v2.

Both LILO and GRUB can configure as a primary boot loader (on MBR) or the secondary boot loader (on a bootable partition). Both work with supporting OS such as Linux, FreeBSD, NetBSD. They can also work with unsupported OS like Microsoft Windows. That’s a great thing!

Configuration file for LILO is /etc/lilo.conf and some configuration directives are listed below:

boot=/dev/hda
map=/boot/map
install=/boot/boot.b
prompt
timeout=50
message=/boot/message
lba32
default=linux

image=/boot/vmlinuz-2.4.0-0.43.6
	label=linux
	initrd=/boot/initrd-2.4.0-0.43.6.img
	read-only
	root=/dev/hda5

other=/dev/hda1
	label=dos

Commonly using boot loader is GRUB and its configuration is also listed under the etc folder.  GRUB has two versions. GRUB v1 and the latest GRUB v2. There are a lot of changes in these two versions of GRUB.

GRUB v1 – /etc/grub.conf

This configuration is actually a link to /boot/grub/grub.conf. All kernel details are included in this configuration file.  Sample entries are pasted below:

# grub.conf generated by anaconda
#
# Note that you do not have to rerun grub after making changes to this file
# NOTICE: You have a /boot partition. This means that
# all kernel and initrd paths are relative to /boot/, eg.
# root (hd0,0)
# kernel /vmlinuz-version ro root=/dev/sda3
# initrd /initrd-[generic-]version.img
#boot=/dev/sda
default=0
timeout=5
splashimage=(hd0,0)/grub/splash.xpm.gz
hiddenmenu
title CloudLinux Server (2.6.32-673.26.1.lve1.4.27.el6.x86_64)
root (hd0,0)
kernel /vmlinuz-2.6.32-673.26.1.lve1.4.27.el6.x86_64 ro root=UUID=15f2bf27-2e16-4b6f-bc86-fa74314aa8d5 rd_NO_LUKS rd_NO_LVM LANG=en_US.UTF-8 rd_NO_MD SYSFONT=latarcyrheb-sun16 crashkernel=auto KEYBOARDTYPE=pc KEYTABLE=us rd_NO_DM rhgb quiet nohz=off
initrd /initramfs-2.6.32-673.26.1.lve1.4.27.el6.x86_64.img

GRUB v2 – /etc/grub2.cfg

This is actually a link to /boot/grub2/grub.cfg. The main difference between GRUB v1 and GRUB v2 is, we can not edit the configuration file for changing the kernel and other settings. However, you can use different grub2-* commands for changing GRUB settings.

A sample configuration is pasted below:

terminal_output console
if [ x$feature_timeout_style = xy ] ; then
set timeout_style=menu
set timeout=5
# Fallback normal timeout code in case the timeout_style feature is
# unavailable.
else
set timeout=5
fi
### END /etc/grub.d/00_header ###
BEGIN /etc/grub.d/10_linux ###
menuentry 'CentOS Linux (3.10.0-123.4.2.el7.x86_64) 7 (Core)' --class centos --class gnu-linux --class gnu --class os --unrestricted $menuentry_id_option 'gnulinux-3.10.0-123.el7.x86_64-advanced-fe0109f2-6f34-48ae-b51e-1f5fa78305b5' {
load_video
set gfxpayload=keep
insmod gzio
insmod part_msdos
insmod ext2
set root='hd0,msdos1'

The line starting from “menuentry” defines Kernels.

It’s something complicated than GRUB v1. But we can manage it simply from command line. We will discuss about GRUB setting on a different article. It needs more space, LOL 😛

Don’t forget, we are at stage 2 of Linux booting process 😛 In stage 2, GRUB is loaded from a known location in boot file system (/boot/grub).

This stage loads other required drives and kernel modules before reading the GRUB configuration file and displaying the boot menu. The familiar GRUB menu is now displayed on the monitor. You can select the kernel from there.

Step 4.  Kernel stage

Here the kernel stage begins. Kernel is in compressed format. We can select the kernel from the GRUB menu. If not selected, the GRUB automatically load the default one in its configuration. We can change the default kernel details from the GRUB configuration.

The kernel you selected is now loaded into the memory. An image file containing the basic root file system with all kernel modules are then loaded into the memory. This image file is located under /boot and it’s known as initramfs.

Initramfs, abbreviated from “initial RAM file system”, is the successor of initrd “initial ramdisk”. This image file contains the initial file system. The GRUB starts the kernel and tells the memory address of this image file. The kernel then mount this image file as a starter memory based root file system.

The kernel then starts to detect the system’s hardware. The root file system on disk takes over from the one in memory. The boot process then starts INIT (SYSTEMD) and the software daemons according to the Sys Admin’s settings. This can be done at next stages.

Step 5. INIT

The kernel, once it is loaded in step 4, it finds init in sbin (/sbin/init) and executes it. [In RHEL/CentOS 7 /sbin/init is linked to ../lib/systemd/systemd]. When init starts, it become the first or parent process on your Linux machine/server.

The first thing init does is reading the initialization file, /etc/inittab. This instructs init to read an initial configuration script for the environment, which sets the path, starts swapping, checks the file systems, and so on. From the /etc/inittab system will find the run level selected and start services by looking in the appropriate rc directory for that run level.

This is only an introduction to Linux booting process. This can expand more, more and more…..

I will and some FAQ and more details of each steps in coming articles. Hope you enjoyed the booting process!!

For the time being, comment me if you have any questions.

Suggested posts for SREs

1, Modern Monitoring Concepts – An Introduction To Prometheus World

2, Advantages of Prometheus monitoring tool

Post navigation

Arunlal A

Senior System Developer at Zeta. Linux lover. Traveller. Let's connect! Whether you're a seasoned DevOps pro or just starting your journey, I'm always eager to engage with like-minded individuals. Follow my blog for regular updates, connect on social media, and let's embark on this DevOps adventure together! Happy coding and deploying!

14 thoughts on “Stages of Linux booting process – explanation, step by step tutorial

  1. As a [beginner-self-learned] sysadmin; thank you very much for this article! Much appreciated, it clears up quite a few questions!

  2. Have been working on Linux since 4 years and every time I want to revise the boot process, I find either over explanatory or over simplified content.

    Very good job. _/\_

  3. it’s possible to do hands-on boot process – run each 5 step individually. I tried to boot but what happen is it runs until I get the prompt to login ?

  4. Bonjour,

    Je suis Alain BIVINA, je débute avec Linux svp donnez moi les astuces pour m’améliorer en moins de 2 semaines à titre personnel.

    Merci, c’est très bon site.

    Cordialement.
    Alain BIVINA

  5. The article is nice, but quite outdated. There is hardly any current system with BIOS, almost every computer has been using UEFI since ~2012.

    The most popular boot loader is grub2, so discussing others is not really important.

    Since almost all Linux systems use systemd, users won’t find a file called /etc/inittab anymore and /sbin/init is a symbolic link to /lib/systemd/systemd. Unfortunately, this is not at all mentioned.

  6. Internal to UEFI is BIOS POST code, relatively unchanged. It is executed first. Modern systems have a CPU that can map CACHE to RAM (CORE and beyond), so that is done as soon as possible, so that RAM for a stack exists. The integrity of the CACHE is basically trusted. At this point functions can be called with normal returns (ret, retn). Tracing thru older code that kept return points in registers and faked calls is a total pain (billions of instructions before base 64k RAM can be used). I have been there and done that… BIOS POST outputs a code to port x80, enables a bus or main component, then tests it for functionality. If it fails, the code in port x80 identifies the problem area. After storage devices are discovered, the same is done for file systems. Enable, Discover, then Test…

Leave a Reply

Your email address will not be published. Required fields are marked *