IOS203_Ch11

Chapter 11: The Boot Process

Bios Initialization ......................................................................................... 3

MBR ............................................................................................................. 4
GRUB2 Bootloader ...................................................................................... 4
Kernel Initialization ..................................................................................... 5
Systemd ....................................................................................................... 7

1
IOS203_Ch11

Objectives
Upon completion this chapter, the student should be able to:

 Understand the Linux boot process;

 Diagnose some boot problems;
 Change the boot sequence;
 Stop /(re)start/enable/disable a service.

Keywords
BIOS, POST, MBR, GRUP2, vmlinuz, initramfs, kernel, systemd, default.target, rc.local,
grub.cfg, tmpfs, /lib/modules, initrd, /sbin/init, runlevel, /etc/inittab, chkconfig,
systemctl.

2
IOS203_Ch11

Understanding the Linux boot process and the files involved in it help you to verify that the system
is correctly operating, to diagnose the boot problems, and to give you the information required
for troubleshooting a booting problem. Boot process starts when you turn on the power button
of your computer or when you initiate a reboot, which will first do a shutdown and then restart
the computer.

The following components are involved in the boot process:

1. BIOS: it performs POST (Power On Self-Test), then loads the MBR (Master Boot Recorder)
and executes it;
2. MBR: it loads GRUB2 (GRand Unified Bootloader, version 2) into memory;
3. GRUB2: the GRUB2 bootloader, loads the vmlinuz kernel image, and then extracts the
contents of the initramfs image;
4. Kernel: it loads driver modules from initramfs, then starts the system’s first process;
5. systemd: it performs the following tasks:
o Reads configuration files from the /etc/systemd directory
o Reads file linked by /etc/systemd/system/default.target
o Brings the system to the state defined by the system target
o Executes /etc/rc.local

1. Bios Initialization

BIOS stands for Basic Input Output System, it is the hardware portion of the boot process and is
the same for any OS. When power is first applied to the computer, a special hardware circuit
causes the CPU to look for the BIOS at a predetermined address. The CPU runs the BIOS which
performs the POST test on all the hardware components and peripherals. It initializes the required
hardware for booting and ensures that the computer hardware works correctly. If the POST fails,
the boot process does not continue, and the BIOS will inform you about any problem with the
help of beep codes through system speaker (different number of beep codes have different
meaning).

After the POST, the BIOS looks for a boot device from a list of devices which can be DVD, CD-ROM,
hard drive, a network interface or other removable media (such as external hard disk or USB flash
drive). The boot order will be something like the following:
1. DVD
2. HARD DISK
3. USB
4. CD-ROM
The previous boot order means that the BIOS will look at DVD first to check whether an OS can be
loaded from there, if it does not find an OS to load, it will check whether a bootable OS is there in
the HARD DISK, then USB and then CD-ROM. You can press a key (typically F2 of F12, but it
depends on your OS) during the BIOS startup to change the boot sequence. In most case, if you
don’t have a bootable CD in your DVD drive, then the BIOS will turn to HARD DISK from which the
boot process starts.

On each bootable device, a boot sector should be found and the BIOS must found it in order to
load the MBR boot loader into memory. The BIOS executes the MBR and gives control to it. If the

3
IOS203_Ch11

BIOS does not finds any bootable device then the BIOS gives an error and the boot process is
stopped.

2. MBR

The boot sector is the first physical sector on the storage device; it is called MBR and contains the
bootloader program, the partition table, and two bytes representing the “Magic Number” which
is used for error detection. The MBR is sometimes found on a USB flash or CD-ROM such as with
a live installation of Linux.

Figure 1: MBR and Hard Disk Partitions

MBR is located in the first sector of the bootable disk (usually, /dev/hda, or /dev/sda). The MBR
size is not more than 512 bytes, the bootloader is in the first 446 bytes, the partition table
information is in the next 64 bytes and the last two bytes are the magic number.

MBR loads the GRUB2 bootloader into memory and transfers control to it.

3. GRUB2 Bootloader

The main goal of the bootloader is to find the kernel, load it into memory, and execute it. The
bootloader, kernel and loader's configuration file, are often stored in the /boot directory. GRUB2
is now the primary bootloader for most current Linux distros; it allows the user to pass arguments
to the kernel.

The GRUP2’s configuration files grub.cfg is located in /boot/grub2. This file is generated during
installation, or by invoking manually the /usr/sbin/grub2-mkconfig utility. This utility generates a
grub.cfg file according to the template files located in /etc/grub.d/, and custom settings in the
/etc/default/grub file. You should be careful when using grub2-mkconfig utility because the
grub.cfg’s content will be lost. Take care also when you change manually the content of the
/etc/default/grub as well.

The GRUB2 searches the compressed kernel image file also called as vmlinuz in the /boot
directory.

4
IOS203_Ch11

The GRUB2 loads the vmlinuz kernel image file into memory and extracts the contents of the
initramfs (abbreviation of initial RAM file system) image file into a temporary memory-based file
system (tmpfs).

4. Kernel Initialization

A kernel is the most fundamental part of an OS, providing services to other user-level commands,
such as the ability to communicate with hard disks and other pieces of hardware. Usually, the
kernels are located in the /boot directory, along with an initial RAM disk image, and device maps
of the hard drives.

On most platforms, the kernel file is in a self-extracting, compressed format to save space on disk.
After the selected vmlinuz kernel image is loaded into memory, it must first extract itself from the
compressed version of the file before it can perform any useful work. The kernel initializes itself
after it loads and then checks the keyboard and other peripherals.

As the Kernel is loaded into the memory, now it needs to mount the Linux root (/) filesystem.
However, to mount the root file system, it needs to access its Kernel modules, which are usually
stored in /lib/modules. But, it is not possible to perform this task unless the root file system itself
is mounted.

The old way (before CentOS/RedHat7)

To get the solution, an image file initrd (found in the /boot directory) is uncompressed and
loaded. initrd stands for initial RAM disk, it is an initial root file system that is mounted before the
real root file system (/). The initrd image file contains a temporary file system that helps the kernel
to mount the permanent root file system and load all other kernel modules. The Kernel executes
a pivot_root command that alters the temporary file system from the memory and establishes
the permanent root file system (/).

The Linux kernel forks and executes /sbin/init program. The init process is the first process (PID
= 1) run by the Linux kernel, but you can also use it to have the system reread the /etc/inittab file
and implement changes it finds there or to change to a new runlevel.
Traditionally, the init would run default processes that were defined in "shell scripts" contained
in appropriate run-level directory which usually found in the /etc/rc.d directory. Within this
directory there is a separate folder for each run level, e.g., rc0.d, rc1.d, and so on. The /etc/inittab
file is used to set the default run level for the system.

The run level is a defined state that the Linux system is currently in. Linux relies on runlevels which
are numbered from 0 to 6, and each one is assigned a set of services that should be active. After
booting, Linux enters a predetermined runlevel, which you can set. Knowing what these functions
are, and how to manage runlevels, is important if you want to control the Linux boot process.
Toward this end, you must understand the purpose of runlevels, be able to identify the services
that are active in a runlevel, be able to adjust those services, be able to check your default and
current runlevels, and be able to change the default and current runlevels.

5
IOS203_Ch11

The following table contains a description for each runlevel:

runlevel Description
0 Halt mod, it shuts down the system
Single-user mode, it is typically used for low-level system maintenance that may
1, s, or S be impaired by normal system operation, such as resizing partitions. It does not
configure network interfaces, start daemons, or allow non-root logins
2 Multi-user mode, it does not configure network interfaces or start daemons.
Multi-user mode with networking, it is a full multi-user mode with a console (non-
3
graphical) login screen.
4 Undefined, it is available for customization
It is the same behavior as runlevel 3 with the addition of having display manager X
5
(graphical interface)
6 Reboot mode, it reboots the system

chkconfig command

The chkconfig command is used in RedHat based distros (like CentOS) to control what services
are started at which runlevels. Running the command chkconfig –list will display a list of services
whether they are enabled or disabled for each runlevel.

The current way (CentOS/RedHat7)

On CentOS/RHEL7 and modern OSs, the initramfs (initial ram disk filesystem) takes the place of
the initrd (initial ram disk). The main disadvantage of initrd is that it is treated as a block device
and wastes a lot of memory due to caching. Linux has a feature to cache all files (including dentries
i.e. directory entries) which are read from any block device. Hence Linux copies all data to and
from a initrd device into pagecache(i.e. files) and dentry cache(i.e. directory entries). With
initramfs, a cpio (copy input and output) archive is created; it contains the necessary boot
files/modules which the kernel extracts to a tmpfs during boot. The tmpfs allows using swap space
and hence the system doesn’t hang (still has available space) even after total memory is occupied.

The init process may force certain services to be launched in a particular sequence. CentOS/RHEL7
and modern OSs switch to systemd, which run services in parallel as opposed to in sequence.
Although Linux OSs (other than CentOS and RedHat based-distros) still use init, systemd is
compatible with init scripts used by previous versions of Linux including CentOS/RHEL 6, but
systemd is likely to replace init for all Linux distros in the future.

In modern OSs, the /sbin/init is a soft link to /usr/lib/systemd/systemd:

Moreover, in those OSs, the content of /etc/inittab file is:

6
IOS203_Ch11

You can note that all lines are comments; it means that the /etc/inittab file is no more used.

5. Systemd

The systemd is a more efficient method of controlling processes. It has the ability to start services
in parallel, and have them communicate with each other, even if they are restarted. The systemd
uses service level dependency which defined to make boot process faster. So, all
services/processes will start as a control group not by PID’s. A control group adds a tag to all
components of a service that make sure that all its components started properly. systemd has a
full control to restart crashed services and its components.

The systemd performs initializing tasks such as: setting the host name, initializing the network,
initializing the SELinux based on its configuration, printing a welcome banner, initializing the
system hardware based on kernel boot arguments, mounting the file systems (including virtual
file systems such as the /proc file system), cleaning up directories in /var, starting swapping and
others.

The systemd is the ancestor of all processes on a Linux OS. It reads the default.target file (i.e.,
/etc/system/system/default.target) to determine the default system target (equivalent to
runlevel) used to start the system. The mentioned file is a symbolic link to the default system
target file currently set.

The following table represents a comparison between runlevels with systemd targets and target
aliases:

Systemd Target Runlevel Alias Description

poweroff.target 0 runlevel0.target Halts the system and turns the power off
A basic system, including mounting the
rescue.target 1 runlevel1.target
filesystems with only the most basic

7
IOS203_Ch11

services running and a rescue shell on the

main console
Single-user mode—no services are
running; filesystems are not mounted. This
is the most basic level of operation with
emergency.target S
only an emergency shell running on the
main console for the user to interact with
the system.
Multi-user, without NFS (Network File
2 runlevel2.target System), but all other non-GUI services
running
multi-user.target 3 runlevel3.target All services running, but CLI only
Unused, this target could be created and
4 runlevel4.target customized to start local services without
changing the default multi-user.target.
graphical.target 5 runlevel5.target Multi-user.target with a GUI
reboot.target 6 runlevel6.target Reboot
halt.target Halts the system without powering it down

The system target file defines the services that systemd starts. The default.target is always aliased
with a symbolic link to either multiuser.target or graphical.target. The default.target should
never be aliased to halt.target, poweroff.target, or reboot.target.

The following represents the content of the default system target file currently set on a CentOS 7
system:

8
IOS203_Ch11

The chkconfig command does not show native systemd services:

Nowadays, most of modern Linux OSs are using tools newer than the chkconfig to manage
services and system target.

In the systemd, the target of most actions are “units”, which are resources that systemd knows
how to manage. Units are categorized by the type of resource they represent and they are defined
with files known as unit files. The type of each unit can be inferred from the suffix in the end of
the file name. The following table describes most commonly used list of systemd unit types:

Unit Description

service (name.service) Processes (daemons) start/stop/restart/reload

socket (name.socket) Define communication channel (for other services)
Device(name.device) Recognize hardware device (plug & play)
Mount (name.mount) Connect device to file system
target (name.target) Groups related services (dependency)
Can be used to temporarily save the state of the set of systemd
Snapshot (name.snapshot)
units, which can later be restored by activating the saved
snapshot unit.
Swap (name.swap) Encapsulate memory swap partitions or swap files.

For service management tasks, the target unit will be service units, which have unit files with a
suffix of “.service”. However, for most service management commands, you can actually leave off
the “.service” suffix, as systemd is smart enough to know that you probably want to operate on a
service when using service management commands.

systemctl command

This command is a new tool to control the systemd system and services. This is the replacement
of the old init command. The following table shows you how to manage services using the
systemctl command:

Action Example Description

Start service systemctl start atd Starting atd service
Stop service systemctl stopt atd Stopping atd service

9
IOS203_Ch11

Restart service systemctl restart atd Stopping then Starting atd service
Reload service systemctl reload mysql.service Reloading configuration of a running service
Display service
systemctl status atd Checking current status of a service
status
Enable Service systemctl enable atd Enabling service to start on system boot
Disable Service systemctl disable atd Disabling service to not to start on system boot
Show all units Systemctl –all Displaying status of all services (pipe to grep
Or, Systemctl -a for just one service)

To show a list of all of the current active units that systemd knows about, we can use the following
command line:

Where:

 UNIT: The unit name;

 LOAD: Service loaded state;
 ACTIVE: High-level activation state;
 SUB: Low- level activation state;
 DESCRIPTION: A short textual description of what the unit is/does.

The systemd units are defined by unit configuration files located in the directories listed in the
following table:

File Description

/usr/lib/systemd/system systemd units distributed with installed RPM packages

systemd units created at runtime. This directory takes precedence
/run/systemd/system
over the directory with installed service units
systemd units created and managed by the system administrator.
/etc/systemd/system This directory takes precedence over the directory with runtime
units.

The following command line allows you to check the default target:

You can verify that it is the graphical.target.

You can still use the old method, which displays the old runlevels.

10
IOS203_Ch11

Note that the previous runlevel is on the left; it is 5, indicating that the runlevel was 5 and has
changed since the host was booted. The number 3 indicates the current runlevel. When having N
(which means None) on the left, it means that the runlevel has not changed since the host was
booted.

You can switch to a graphical target using the following command line:

[root@localhoost ~]# systemctl isolate graphical.target

If you use again the runlevel command, you will have the following output:

11
IOS203_Ch11

Questions
1. Explain the Linux boot process
2. What does the BIOS do during the Linux boot process?
3. What is POST?
4. What is GRUB2 boot loader?
5. What is MBR?
6. Which file is needed to update for changing the default runlevel from 5 to 3?
7. What is the Linux kernel?
8. What is runlevel?
9. How to start a service on reboot?
10. How do you start and stop a service?
11. What does the systemd do during the Linux boot process?
12. What are the differences between initrd and initramfs?
13. What are the differences between init and systemd?
14. What are the differences between multi-user.target and graphical.target?
15. What are the differences between emergency.target and rescue.target?
16. What is the difference between runlevel and system target?
17. Explain the fields in the output of the following command line:
# systemctl list-units
18. List the directories in which unit configuration files are located
19. The chkconfig command does not show native systemd services, which command can show
these services?
20. When executing the runlevel command and have N as the first letter of the output, what does
that mean?

References

1. https://www.thegeekdiary.com/centos-rhel-7-booting-process/
2. https://yoinsights.com/step-by-step-red-hat-enterprise-linux-7-booting-process
3. https://opensource.com/article/20/5/systemd-startup
4. Red Hat Linux Essentials RH033-RHEL5-en-2-20070306
5. Paul Cobbaut, “Linux Fundamentals”, https://linux-training.be/funhtml/index.html. Updated
on 2015-05-24

12