In this lesson,
we're going to discuss the different Linux boot components.
Now, that we've configured the kernel,
we need to learn about how the kernel is loaded into memory
and how the operating system is actually going to start up.
We're also going to configure the boot process to our liking,
ensuring that the Linux workspace
operates as intended from the very beginning.
Now, have you ever wondered what it takes
to get your system ready to run applications and programs?
To begin with, we have to understand the Linux boot process,
because this is very important
for us to be able to configure Linux
and resolve startup issues,
as well as to identify various components
that make up the boot process
and configure them whenever we need to.
Now, in Linux,
there are going to be six different stages of booting.
This is called the booting process.
So, what is the booting process?
Well, booting is a process of starting
or restarting a computer
and loading an operating system for the user to access.
In the boot process,
a booting environment reads a small program
that's stored in read-only memory known as ROM.
This program then executes various operations
inside your RAM or your random-access memory,
and that's going to bootstrap the operating system
and make it available for use.
Linux like most other operating systems
has to be booted before it can function.
Now, there are various options associated
with the boot process that you're going to be able
to configure as well if you need to.
A boot loader is a small program that's stored in ROM
and that's going to load the kernel from a storage device,
like a hard disc drive.
And then, it's going to start up the operating system.
When a computer is powered up or restarted,
the basic input/output system performs initial tests
and then transfers control over to the Master Boot Record.
And this is where the boot loader is going to reside.
Boot loaders are able
to protect the boot process with a password,
and that's going to prevent
unauthorized booting of your system.
The boot loader can also use three main components
that are going to work together to systematically load up
the operating system in three different stages.
The first component is the boot sector program
and this is loaded by a boot environment on startup,
but it's main function is to load up the second boot loader.
The second stage boot loader
is going to load the operating system,
and this contains a kernel loader.
On the other hand, the boot loader installer
is going to control the installation of drive sectors
and can only be run when booting from a drive.
It's going to coordinate the activities
of the boot sector and the boot loader.
Now, there are several boot options
where you can boot Linux from a basic input/output system
known as BIOS or the UEFI,
the Unified Extensible Firmware Interface or UEFI.
Now, when a computer with BIOS is powered on,
the BIOS firmware is the first thing to run,
and this is going to enable it
to test the various hardware components in a computer,
as well as run a boot loader,
so the operating system can start up.
The BIOS has access to the ports
that are used by the basic hardware input devices,
things like the mouse and the keyboard
And users can also load up a BIOS interface
instead of going into an operating system.
This is done if they need
to make various hardware level changes.
On the other hand, UEFI is going to run faster than the BIOS.
It also operates with a greater amount of memory
and it gives you access to storage drives
of various different sizes.
It'll also allow you to access more hardware types
and has much more improved security protections
than standard BIOS does.
One security feature that both the BIOS
and UEFI will have is the ability to set a password.
If this password is not provided at boot time,
the system will simply not boot.
Now, because the BIOS and UEFI are firmware,
they do differ based on the different
hardware manufacturers that make them.
And the process of setting up this password
is not going to be consistent
across all BIOS or UEFI firmwares.
Another boot option includes booting from an ISO
which is an image file.
This is where you need to write that ISO file
to an optical disc or a USB thumb drive,
and then insert that media into the computer
and instruct your boot environment like the UEFI
or the BIOS to boot from that media device instead.
Another way you can boot up is by using PXE,
which is a Preboot eXecution Environment.
This is part of the UEFI standard,
and it enables a client
to retrieve the necessary boot loader
and system files from a server over the network.
Now, the client configures UEFI to boot from the PXE.
And during the startup process, it's going to search
for a Dynamic Host Configuration Protocol server
or DHCP server that also acts as your PXE server.
Clients can also acquire boot data over a network
from the content delivery protocols like HTTP,
the Hypertext Transfer Protocol
or FTP the File Transfer Protocol.
These are typically going to be faster, more reliable,
and more secure than using a standard TFTP protocol
like you'd normally use in PXE environments.
Finally, booting from NFS or a Network File System
allows a client to mount an NFS share
as its root file system, and then operate over the network.
This share must be prepared ahead of time though,
and stored on an NFS server
that the client can retrieve the files from.
Therefore, the client does not store the data locally,
but instead, it stores everything
on that network file server.
Another thing we have to think about
is how is a hard disk read from
or written to by an operating system.
Now, the information
about how a hard disc has been partitioned
is going to be stored inside your Master Boot Record,
known as the MBR.
The Master Boot Record is a sector
that the BIOS is going to read in
and start when the machine is first booted.
The Master Boot Record contains a small program
that reads the partition tables
and it checks which partitions are active
and then reads the first sector of that partition.
This boot sector contains another small program
that's going to read the first part
of the operating system that's stored on that partition,
assuming it's active and bootable,
and then it's going to start it up.
If you're using a GUID Partition Table,
also known as the GPT,
this is a newer version of a Master Boot Record.
And it basically makes up for the shortcomings
that were inside of a Master Boot Record,
because it is an older technology.
Just like a Master Boot Record,
a GPT is a partition structure,
but it's going to employ a more modern design,
and it's part of the UEFI standard
instead of relying on the older BIOS standards.
Every partition on a drive
is assigned a globally unique identifier or a GUID, or GUID.
This allows it to distinguish it from every other partition
on every other drive theoretically.
Other than formatting a partition as MBR or GPT,
you can also format a partition as raw.
Now, a raw partition enables users
and applications to read from
or write to a block storage device directly
without using the system's cache.
This is useful in situations where a software
like a database management system
or DBMS has its own caching mechanism.
Another thing we need talk about is RAM disk.
There's this thing known as the initial RAM disk or initrd.
And this refers to the root file system
that's temporarily loaded in the memory upon system boot.
This initial RAM disk is going to load alongside the kernel
and it's going to control all the functionality.
This initial RAM disk
will enable the system to be started in two phases.
During the first phase,
the system is booted with a minimal set of modules
that are required to load the main
or the permanent root file system.
In the second phase,
the main root file system is going to be mounted.
And then, the previously mounted
initial RAM disk file system can be removed.
And this way, the user space
boot process can continue forward.
The initial RAM disk is going to be useful
because there are potential variables
that can complicate the boot process.
For example, the kernel needs to find
and load the necessary device driver modules,
as well as the actual route file system itself.
There's also the possibility
that the route file system uses one
of several advanced storage mechanisms
like LVM the Logical Volume Manager,
or NFS the Network File System.
And these have different mounting requirements
than a standard partition would.
The Linux initial RAM disk image is an archive file
that contains all the essential files
that are required for booting up the operating system.
It can be built or customized to include additional modules
or remove unnecessary modules, or update existing modules.
Typically, this image
is going to be stored in the /boot directory.
Now, to make our initial RAM disk,
we're going to use the make initial RAM disk command.
The make initial RAM disk command
is used to create the initial RAM disk image
for preloading the kernel modules.
This command is written as mkinitrd.
Now, there's a couple of different options
for the make initial RAM disk command.
This includes the --preload equals module name option,
and this is used to load a module
into that initial RAM disk image
before loading the other modules.
Another option we have is --width equals the module name.
This option is going to be used
to load a module in the initial RAM disk image
after the loading of the other modules.
The -f option is going to be used
to overwrite an existing initial RAM disk image file.
And the -nocompress option
is used to disable the compression of that initial image.
In order to run the make initial RAM disk command,
you have to type in mkinitrd,
the options,
the initial RAM disk image name and the kernel version.
For example, if you want to create the initial RAM disk image
from your current kernel version and name it
as initrd-.img,
you can type mkinitrd/boot/initrd-$(uname -r)
.img $(uname -r)
in the command prompt.
Now, as defined by the File System Hierarchy Standard
or FHS, the /boot directory contains files
that are used to facilitate the Linux boot process.
Now, some of the files and sub-directories
within the /boot directory that you should know about
are things like the /boot/grub directory.
This contains configuration files
for a type of boot loader known as GRUB.
If you go into the /boot/grub2 directory,
this is also a different type of boot loader,
but it's known as GRUB 2.
It's an improved version of GRUB.
The /boot/efi directory contains boot files
for an EFI system partition known as ESP,
which is going to be required
for partitions of a system
that boot from the UEFI interface.
It also will contain a boot loader, device drivers,
and system application files that are executed by the UEFI.
The next one we need to talk about
is /boot/initramfs-.img.
This is a file
that is going to be the initial RAM file system image.
And this is an alternative
to the initial RAM disk image that we talked about before.
It's going to use different methods
to do the same basic things.
It's going to initialize a temporary route file system
on the boot drive and then load in those modules as needed.
Lastly, we have /boot/vmlinuz-
and this contains the Linux kernel itself.
The boot loader is going to load this file into memory
during the boot process
to initialize the overall Linux operating system.
Another command you need to be familiar with
is the dracut command.
This is used to generate an init RAM file system image,
similar to how we use the mkinitrd command
to generate an initial RAM disk image.
In fact, on some distributions,
the make initial RAM disk is a compatibility wrapper
that'll actually call the dracut command.
When you want to create an initial RAM file system image,
you can use the dracut command
by typing in dracut /boot.initramfs-$(uname -r)
.img $(uname -r).
This boot process is going to be repeated
each time your computer is started
by loading up the operating system from a storage device.
It's going to involve a series of sequential steps
that can be divided into the BIOS or UEFI initialization,
the boot loader, the kernel, and the initial RAM disk
or initial RAM file system initiation,
and finally, your boot scripts.
First, the processor's going to check for the BIOS
or UEFI firmware, and if it finds it, it's going to execute it.
This is also where your power
on self-test or post is going to occur.
Second, the BIOS or UEFI is going to check
for bootable media from the internal storage devices
or peripherals like USB thumb drives and DVD ROMs.
By doing this, it's going to locate a valid device
to boot up your system from.
Then, the BIOS or UEFI is going to load the primary boot loader
from the Master Boot Record or the GUID Partition Table.
It's going to do this into your memory.
And then, it's going to load the partition table along with it.
The user will then be prompted
by the GRUB 2 boot loader or other boot loader
to select the operating system that they want a boot from.
If the user doesn't respond,
then the default operating system is going to be booted up.
Next, the boot loader determines the kernel
and locates the corresponding kernel binary.
It'll then upload the respective initial RAM disk image
into memory and transfer control
of the boot process to the kernel.
Then, the kernel
will configure the available hardware drivers,
including your processors,
input/output systems, and storage devices.
It'll decompress the initial RAM disk image
and mount it to load the necessary drivers.
If the system implemented any virtual devices,
such as the LVM or software RAID,
those will also be initialized.
The kernel will then mount the main root partition
and release unused memory back into the system.
To set up the user environment,
the systemd program is going to run.
It's going to become Process ID 1 on that system.
Then, the systemd or the system Daemon program
is going to search for the default.target file,
which contains details
about the services that need to be started.
It'll then mount the file system
based on the /etc/fstab file
and begin the process of starting up at services.
On most systems, the target either
be a multiuser.target or graphical.target file.
If the graphical mode was selected,
then a display manager like XDM or KDM
is going to be started up
and the login window will be displayed on the screen.
The user can then enter a username
and password to log into the system.
And then, the system
will authenticate the user based on those credentials.
If the user is valid,
the various profile files are going to be executed.
Finally, the shell has started
and the system is ready for the user to begin their work.
Now, everything I just said
assumes that everything went right in the boot up process,
but there's times things go wrong.
And this is why we have a mechanism
for the system to detect if there's been a fatal error,
and it's going to respond to that
by doing what's called a kernel panic.
Now, a fatal error typically results
in the system becoming unstable or totally unusable.
There is software that handles these kernel panics
and those display an error message to the user
and dump the current state of the kernel memory
to a storage device for later debugging as well.
Depending on how your system is configured,
the panic handler will either
reboot the system automatically,
or it'll shut itself down
and wait for the user to turn on the system again.