Linux Professional Institute Learning Logo.
Skip to main content
  • Home
    • All Resources
    • LPI Learning Materials
    • Become a Contributor
    • Publishing Partners
    • Become a Publishing Partner
    • About
    • FAQ
    • Contributors
    • Roadmap
    • Contact
  • LPI.org
101.2 Lesson 1
Topic 101: System Architecture
101.1 Determine and configure hardware settings
  • 101.1 Lesson 1
101.2 Boot the system
  • 101.2 Lesson 1
101.3 Change runlevels / boot targets and shutdown or reboot system
  • 101.3 Lesson 1
Topic 102: Linux Installation and Package Management
102.1 Design hard disk layout
  • 102.1 Lesson 1
102.2 Install a boot manager
  • 102.2 Lesson 1
102.3 Manage shared libraries
  • 102.3 Lesson 1
102.4 Use Debian package management
  • 102.4 Lesson 1
102.5 Use RPM and YUM package management
  • 102.5 Lesson 1
102.6 Linux as a virtualization guest
  • 102.6 Lesson 1
Topic 103: GNU and Unix Commands
103.1 Work on the command line
  • 103.1 Lesson 1
  • 103.1 Lesson 2
103.2 Process text streams using filters
  • 103.2 Lesson 1
103.3 Perform basic file management
  • 103.3 Lesson 1
  • 103.3 Lesson 2
103.4 Use streams, pipes and redirects
  • 103.4 Lesson 1
  • 103.4 Lesson 2
103.5 Create, monitor and kill processes
  • 103.5 Lesson 1
  • 103.5 Lesson 2
103.6 Modify process execution priorities
  • 103.6 Lesson 1
103.7 Search text files using regular expressions
  • 103.7 Lesson 1
  • 103.7 Lesson 2
103.8 Basic file editing
  • 103.8 Lesson 1
Topic 104: Devices, Linux Filesystems, Filesystem Hierarchy Standard
104.1 Create partitions and filesystems
  • 104.1 Lesson 1
104.2 Maintain the integrity of filesystems
  • 104.2 Lesson 1
104.3 Control mounting and unmounting of filesystems
  • 104.3 Lesson 1
104.5 Manage file permissions and ownership
  • 104.5 Lesson 1
104.6 Create and change hard and symbolic links
  • 104.6 Lesson 1
104.7 Find system files and place files in the correct location
  • 104.7 Lesson 1
How to get certified
  1. Topic 101: System Architecture
  2. 101.2 Boot the system
  3. 101.2 Lesson 1

101.2 Lesson 1

Certificate:

LPIC-1

Version:

5.0

Topic:

101 System Architecture

Objective:

101.2 Boot the system

Lesson:

1 of 1

Introduction

In order to control the machine, the operating system’s main component — the kernel — must be loaded by a program called a bootloader, which itself is loaded by a pre-installed firmware such as BIOS or UEFI. The bootloader can be customized to pass parameters to the kernel, such as which partition contains the root filesystem or in which mode the operating system should execute. Once loaded the kernel continues the boot process identifying and configuring the hardware. Lastly, the kernel calls the utility responsible for starting and managing the system’s services.

Note

On some Linux distributions, commands executed in this lesson may require root privileges.

BIOS or UEFI

The procedures executed by x86 machines to run the bootloader are different whether they use BIOS or UEFI. The BIOS, short for Basic Input/Output System, is a program stored in a non-volatile memory chip attached to the motherboard, executed every time the computer is powered on. This type of program is called firmware and its storage location is separate from the other storage devices the system may have. The BIOS assumes that the first 440 bytes in the first storage device — following the order defined in the BIOS configuration utility — are the first stage of the bootloader (also called bootstrap). The first 512 bytes of a storage device are named the MBR (Master Boot Record) of storage devices using the standard DOS partition schema and, in addition to the first stage of the bootloader, contain the partition table. If the MBR does not contain the correct data, the system will not be able to boot, unless an alternative method is employed.

Generally speaking, the pre-operating steps to boot a system equipped with BIOS are:

  1. The POST (power-on self-test) process is executed to identify simple hardware failures as soon as the machine is powered on.

  2. The BIOS activates the basic components to load the system, like video output, keyboard and storage media.

  3. The BIOS loads the first stage of the bootloader from the MBR (the first 440 bytes of the first device, as defined in the BIOS configuration utility).

  4. The first stage of the bootloader calls the second stage of the bootloader, responsible for presenting boot options and loading the kernel.

The UEFI, short for Unified Extensible Firmware Interface, differs from BIOS in some key points. As the BIOS, the UEFI is also a firmware, but it can identify partitions and read many filesystems found in them. The UEFI does not rely on the MBR, taking into account only the settings stored in its non-volatile memory (NVRAM) attached to the motherboard. These definitions indicate the location of the UEFI compatible programs, called EFI applications, that will be executed automatically or called from a boot menu. EFI applications can be bootloaders, operating system selectors, tools for system diagnostics and repair, etc. They must be in a conventional storage device partition and in a compatible filesystem. The standard compatible filesystems are FAT12, FAT16 and FAT32 for block devices and ISO-9660 for optical media. This approach allows for the implementation of much more sophisticated tools than those possible with BIOS.

The partition containing the EFI applications is called the EFI System Partition or just ESP. This partition must not be shared with other system filesystems, like the root filesystem or user data filesystems. The EFI directory in the ESP partition contains the applications pointed to by the entries saved in the NVRAM.

Generally speaking, the pre-operating system boot steps on a system with UEFI are:

  1. The POST (power-on self-test) process is executed to identify simple hardware failures as soon as the machine is powered on.

  2. The UEFI activates the basic components to load the system, like video output, keyboard and storage media.

  3. UEFI’s firmware reads the definitions stored in NVRAM to execute the pre-defined EFI application stored in the ESP partition’s filesystem. Usually, the pre-defined EFI application is a bootloader.

  4. If the pre-defined EFI application is a bootloader, it will load the kernel to start the operating system.

The UEFI standard also supports a feature called Secure Boot, which only allows the execution of signed EFI applications, that is, EFI applications authorized by the hardware manufacturer. This feature increases the protection against malicious software, but can make it difficult to install operating systems not covered by the manufacturer’s warranty.

The Bootloader

The most popular bootloader for Linux in the x86 architecture is GRUB (Grand Unified Bootloader). As soon as it is called by the BIOS or by the UEFI, GRUB displays a list of operating systems available to boot. Sometimes the list does not appear automatically, but it can be invoked by pressing Shift while GRUB is being called by BIOS. In UEFI systems, the Esc key should be used instead.

From the GRUB menu it is possible to choose which one of the installed kernels should be loaded and to pass new parameters to it. Most kernel parameters follow the pattern option=value. Some of the most useful kernel parameters are:

acpi

Enables/disables ACPI support. acpi=off will disable support for ACPI.

init

Sets an alternative system initiator. For example, init=/bin/bash will set the Bash shell as the initiator. This means that a shell session will start just after the kernel boot process.

systemd.unit

Sets the systemd target to be activated. For example, systemd.unit=graphical.target. Systemd also accepts the numerical runlevels as defined for SysV. To activate the runlevel 1, for example, it is only necessary to include the number 1 or the letter S (short for “single”) as a kernel parameter.

mem

Sets the amount of available RAM for the system. This parameter is useful for virtual machines so as to limit how much RAM will be available to each guest. Using mem=512M will limit to 512 megabytes the amount of available RAM to a particular guest system.

maxcpus

Limits the number of processors (or processor cores) visible to the system in symmetric multi-processor machines. It is also useful for virtual machines. A value of 0 turns off the support for multi-processor machines and has the same effect as the kernel parameter nosmp. The parameter maxcpus=2 will limit the number of processors available to the operating system to two.

quiet

Hides most boot messages.

vga

Selects a video mode. The parameter vga=ask will show a list of the available modes to choose from.

root

Sets the root partition, distinct from the one pre-configured in the bootloader. For example, root=/dev/sda3.

rootflags

Mount options for the root filesystem.

ro

Makes the initial mount of the root filesystem read-only.

rw

Allows writing in the root filesystem during initial mount.

Changing the kernel parameters is not usually required, but it can be useful to detect and solve operating system related problems. Kernel parameters must be added to the file /etc/default/grub in the line GRUB_CMDLINE_LINUX to make them persistent across reboots. A new configuration file for the bootloader must be generated every time /etc/default/grub changes, which is accomplished by the command grub-mkconfig -o /boot/grub/grub.cfg. Once the operating system is running, the kernel parameters used for loading the current session are available for reading in the file /proc/cmdline.

Note

Configuring GRUB will be discussed further in a later lesson.

System Initialization

Apart from the kernel, the operating system depends on other components that provide the expected features. Many of these components are loaded during the system initialization process, varying from simple shell scripts to more complex service programs. Scripts are often used to perform short lived tasks that will run and terminate during the system initialization process. Services, also known as daemons, may be active all the time as they can be responsible for intrinsic aspects of the operating system.

The diversity of ways that startup scripts and daemons with the most different characteristics can be built into a Linux distribution is huge, a fact that historically hindered the development of a single solution that meets the expectations of maintainers and users of all Linux distributions. However, any tool that the distribution maintainers have chosen to perform this function will at least be able to start, stop and restart system services. These actions are often performed by the system itself after a software update, for example, but the system administrator will almost always need to manually restart the service after making modifications to its configuration file.

It is also convenient for a system administrator to be able to activate a particular set of daemons, depending on the circumstances. It should be possible, for example, to run just a minimum set of services in order to perform system maintenance tasks.

Note

Strictly speaking, the operating system is just the kernel and its components which control the hardware and manages all processes. It is common, however, to use the term “operating system” more loosely, to designate an entire group of distinct programs that make up the software environment where the user can perform the basic computational tasks.

The initialization of the operating system starts when the bootloader loads the kernel into RAM. Then, the kernel will take charge of the CPU and will start to detect and setup the fundamental aspects of the operating system, like basic hardware configuration and memory addressing.

The kernel will then open the initramfs (initial RAM filesystem). The initramfs is an archive containing a filesystem used as a temporary root filesystem during the boot process. The main purpose of an initramfs file is to provide the required modules so the kernel can access the “real” root filesystem of the operating system.

As soon as the root filesystem is available, the kernel will mount all filesystems configured in /etc/fstab and then will execute the first program, a utility named init. The init program is responsible for running all initialization scripts and system daemons. There are distinct implementations of such system initiators apart from the traditional init, like systemd and Upstart. Once the init program is loaded, the initramfs is removed from RAM.

SysV standard

A service manager based on the SysVinit standard controls which daemons and resources will be available by employing the concept of runlevels. Runlevels are numbered 0 to 6 and are designed by the distribution maintainers to fulfill specific purposes. The only runlevel definitions shared between all distributions are the runlevels 0, 1 and 6.

systemd

systemd is a modern system and services manager with a compatibility layer for the SysV commands and runlevels. systemd has a concurrent structure, employs sockets and D-Bus for service activation, on-demand daemon execution, process monitoring with cgroups, snapshot support, system session recovery, mount point control and a dependency-based service control. In recent years most major Linux distributions have gradually adopted systemd as their default system manager.

Upstart

Like systemd, Upstart is a substitute to init. The focus of Upstart is to speed up the boot process by parallelizing the loading process of system services. Upstart was used by Ubuntu based distributions in past releases, but today gave way to systemd.

Initialization Inspection

Errors may occur during the boot process, but they may not be so critical to completely halt the operating system. Notwithstanding, these errors may compromise the expected behaviour of the system. All errors result in messages that can be used for future investigations, as they contain valuable information about when and how the error occurred. Even when no error messages are generated, the information collected during the boot process can be useful for tuning and configuration purposes.

The memory space where the kernel stores its messages, including the boot messages, is called the kernel ring buffer. The messages are kept in the kernel ring buffer even when they are not displayed during the initialization process, like when an animation is displayed instead. However the kernel ring buffer loses all messages when the system is turned off or by executing the command dmesg --clear. Without options, command dmesg displays the current messages in the kernel ring buffer:

$ dmesg
[    5.262389] EXT4-fs (sda1): mounted filesystem with ordered data mode. Opts: (null)
[    5.449712] ip_tables: (C) 2000-2006 Netfilter Core Team
[    5.460286] systemd[1]: systemd 237 running in system mode.
[    5.480138] systemd[1]: Detected architecture x86-64.
[    5.481767] systemd[1]: Set hostname to <torre>.
[    5.636607] systemd[1]: Reached target User and Group Name Lookups.
[    5.636866] systemd[1]: Created slice System Slice.
[    5.637000] systemd[1]: Listening on Journal Audit Socket.
[    5.637085] systemd[1]: Listening on Journal Socket.
[    5.637827] systemd[1]: Mounting POSIX Message Queue File System...
[    5.638639] systemd[1]: Started Read required files in advance.
[    5.641661] systemd[1]: Starting Load Kernel Modules...
[    5.661672] EXT4-fs (sda1): re-mounted. Opts: errors=remount-ro
[    5.694322] lp: driver loaded but no devices found
[    5.702609] ppdev: user-space parallel port driver
[    5.705384] parport_pc 00:02: reported by Plug and Play ACPI
[    5.705468] parport0: PC-style at 0x378 (0x778), irq 7, dma 3 [PCSPP,TRISTATE,COMPAT,EPP,ECP,DMA]
[    5.800146] lp0: using parport0 (interrupt-driven).
[    5.897421] systemd-journald[352]: Received request to flush runtime journal from PID 1

The output of dmesg can be hundreds of lines long, so the previous listing contains only the excerpt showing the kernel calling the systemd service manager. The values in the beginning of the lines are the amount of seconds relative to when kernel load begins.

In systems based on systemd, command journalctl will show the initialization messages with options -b, --boot, -k or --dmesg. Command journalctl --list-boots shows a list of boot numbers relative to the current boot, their identification hash and the timestamps of the first and last corresponding messages:

$ journalctl --list-boots
 -4 9e5b3eb4952845208b841ad4dbefa1a6 Thu 2019-10-03 13:39:23 -03—Thu 2019-10-03 13:40:30 -03
 -3 9e3d79955535430aa43baa17758f40fa Thu 2019-10-03 13:41:15 -03—Thu 2019-10-03 14:56:19 -03
 -2 17672d8851694e6c9bb102df7355452c Thu 2019-10-03 14:56:57 -03—Thu 2019-10-03 19:27:16 -03
 -1 55c0d9439bfb4e85a20a62776d0dbb4d Thu 2019-10-03 19:27:53 -03—Fri 2019-10-04 00:28:47 -03
  0 08fbbebd9f964a74b8a02bb27b200622 Fri 2019-10-04 00:31:01 -03—Fri 2019-10-04 10:17:01 -03

Previous initialization logs are also kept in systems based on systemd, so messages from prior operating system sessions can still be inspected. If options -b 0 or --boot=0 are provided, then messages for the current boot will be shown. Options -b -1 or --boot=-1 will show messages from the previous initialization. Options -b -2 or --boot=-2 will show the messages from the initialization before that and so on. The following excerpt shows the kernel calling the systemd service manager for the last initialization process:

$ journalctl -b 0
oct 04 00:31:01 ubuntu-host kernel: EXT4-fs (sda1): mounted filesystem with ordered data mode. Opts: (null)
oct 04 00:31:01 ubuntu-host kernel: ip_tables: (C) 2000-2006 Netfilter Core Team
oct 04 00:31:01 ubuntu-host systemd[1]: systemd 237 running in system mode.
oct 04 00:31:01 ubuntu-host systemd[1]: Detected architecture x86-64.
oct 04 00:31:01 ubuntu-host systemd[1]: Set hostname to <torre>.
oct 04 00:31:01 ubuntu-host systemd[1]: Reached target User and Group Name Lookups.
oct 04 00:31:01 ubuntu-host systemd[1]: Created slice System Slice.
oct 04 00:31:01 ubuntu-host systemd[1]: Listening on Journal Audit Socket.
oct 04 00:31:01 ubuntu-host systemd[1]: Listening on Journal Socket.
oct 04 00:31:01 ubuntu-host systemd[1]: Mounting POSIX Message Queue File System...
oct 04 00:31:01 ubuntu-host systemd[1]: Started Read required files in advance.
oct 04 00:31:01 ubuntu-host systemd[1]: Starting Load Kernel Modules...
oct 04 00:31:01 ubuntu-host kernel: EXT4-fs (sda1): re-mounted. Opts: commit=300,barrier=0,errors=remount-ro
oct 04 00:31:01 ubuntu-host kernel: lp: driver loaded but no devices found
oct 04 00:31:01 ubuntu-host kernel: ppdev: user-space parallel port driver
oct 04 00:31:01 ubuntu-host kernel: parport_pc 00:02: reported by Plug and Play ACPI
oct 04 00:31:01 ubuntu-host kernel: parport0: PC-style at 0x378 (0x778), irq 7, dma 3 [PCSPP,TRISTATE,COMPAT,EPP,ECP,DMA]
oct 04 00:31:01 ubuntu-host kernel: lp0: using parport0 (interrupt-driven).
oct 04 00:31:01 ubuntu-host systemd-journald[352]: Journal started
oct 04 00:31:01 ubuntu-host systemd-journald[352]: Runtime journal (/run/log/journal/abb765408f3741ae9519ab3b96063a15) is 4.9M, max 39.4M, 34.5M free.
oct 04 00:31:01 ubuntu-host systemd-modules-load[335]: Inserted module 'lp'
oct 04 00:31:01 ubuntu-host systemd-modules-load[335]: Inserted module 'ppdev'
oct 04 00:31:01 ubuntu-host systemd-modules-load[335]: Inserted module 'parport_pc'
oct 04 00:31:01 ubuntu-host systemd[1]: Starting Flush Journal to Persistent Storage...

Initialization and other messages issued by the operating system are stored in files inside the directory /var/log/. If a critical error happens and the operating system is unable to continue the initialization process after loading the kernel and the initramfs, an alternative boot medium could be used to start the system and to access the corresponding filesystem. Then, the files under /var/log/ can be searched for possible reasons causing the interruption of the boot process. Options -D or --directory of command journalctl can be used to read log messages in directories other than /var/log/journal/, which is the default location for systemd log messages. As systemd’s log messages are not stored in raw text, command journalctl is required to read them.

Guided Exercises

  1. On a machine equipped with a BIOS firmware, where is the bootstrap binary located?

  2. UEFI firmware supports extended features provided by external programs, called EFI applications. These applications, however, have their own special location. Where on the system would the EFI applications be located?

  3. Bootloaders allow the passing of custom kernel parameters before loading it. Suppose the system is unable to boot due to a misinformed root filesystem location. How would the correct root filesystem, located at /dev/sda3, be given as a parameter to the kernel?

  4. The boot process of a Linux machine ends up with the following message:

    ALERT! /dev/sda3 does not exist. Dropping to a shell!

    What is the likely cause of this problem?

Explorational Exercises

  1. The bootloader will present a list of operating systems to choose from when more than one operating system is installed on the machine. However, a newly installed operating system can overwrite the MBR of the hard disk, erasing the first stage of the bootloader and making the other operating system inaccessible. Why would this not happen on a machine equipped with a UEFI firmware?

  2. What is a common consequence of installing a custom kernel without providing an appropriate initramfs image?

  3. The initialization log is hundreds of lines long, so the output of dmesg command is often piped to a pager command — like command less — to facilitate the reading. What dmesg option will automatically paginate its output, eliminating the need to use a pager command explicitly?

  4. A hard drive containing the entire filesystem of an offline machine was removed and attached to a working machine as a secondary drive. Assuming its mount point is /mnt/hd, how would journalctl be used to inspect the contents of the journal files located at /mnt/hd/var/log/journal/?

Summary

This lesson covers the boot sequence in a standard Linux system. Proper knowledge of how the boot process of a Linux system works helps prevent errors that can make the system inaccessible. The lesson goes through the following topic areas:

  • How BIOS and UEFI boot methods differ.

  • Typical system initialization stages.

  • Recovering boot messages.

The commands and procedures addressed were:

  • Common kernel parameters.

  • Commands to read boot messages: dmesg and journalctl.

Answers to Guided Exercises

  1. On a machine equipped with a BIOS firmware, where is the bootstrap binary located?

    In the MBR of the first storage device, as defined in the BIOS configuration utility.

  2. UEFI firmware supports extended features provided by external programs, called EFI applications. These applications, however, have their own special location. Where on the system would the EFI applications be located?

    EFI applications are stored in the EFI System Partition (ESP), located at any available storage block with a compatible filesystem (usually a FAT32 filesystem).

  3. Bootloaders allow the passing of custom kernel parameters before loading it. Suppose the system is unable to boot due to a misinformed root filesystem location. How would the correct root filesystem, located at /dev/sda3, be given as a parameter to the kernel?

    The root parameter should be used, as in root=/dev/sda3.

  4. The boot process of a Linux machine ends up with the following message:

    ALERT! /dev/sda3 does not exist. Dropping to a shell!

    What is the likely cause of this problem?

    The kernel was unable to find the device /dev/sda3, informed as the root filesystem.

Answers to Explorational Exercises

  1. The bootloader will present a list of operating systems to choose from when more than one operating system is installed on the machine. However, a newly installed operating system can overwrite the MBR of the hard disk, erasing the first stage of the bootloader and making the other operating system inaccessible. Why would this not happen on a machine equipped with a UEFI firmware?

    UEFI machines do not use the hard disk’s MBR to store the first stage of the bootloader.

  2. What is a common consequence of installing a custom kernel without providing an appropriate initramfs image?

    The root filesystem may be inaccessible if its type was compiled as an external kernel module.

  3. The initialization log is hundreds of lines long, so the output of dmesg command is often piped to a pager command — like command less — to facilitate the reading. What dmesg option will automatically paginate its output, eliminating the need to use a pager command explicitly?

    Commands dmesg -H or dmesg --human will enable the pager by default.

  4. A hard drive containing the entire filesystem of an offline machine was removed and attached to a working machine as a secondary drive. Assuming its mount point is /mnt/hd, how would journalctl be used to inspect the contents of the journal files located at /mnt/hd/var/log/journal/?

    With commands journalctl -D /mnt/hd/var/log/journal or journalctl --directory=/mnt/hd/var/log/journal

Linux Professional Insitute Inc. All rights reserved. Visit the Learning Materials website: https://learning.lpi.org
This work is licensed under the Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 International License.

Next Lesson

101.3 Change runlevels / boot targets and shutdown or reboot system (101.3 Lesson 1)

Read next lesson

Linux Professional Insitute Inc. All rights reserved. Visit the Learning Materials website: https://learning.lpi.org
This work is licensed under the Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 International License.

LPI is a non-profit organization.

© 2023 Linux Professional Institute (LPI) is the global certification standard and career support organization for open source professionals. With more than 200,000 certification holders, it's the world’s first and largest vendor-neutral Linux and open source certification body. LPI has certified professionals in over 180 countries, delivers exams in multiple languages, and has hundreds of training partners.

Our purpose is to enable economic and creative opportunities for everybody by making open source knowledge and skills certification universally accessible.

  • LinkedIn
  • flogo-RGB-HEX-Blk-58 Facebook
  • Twitter
  • Contact Us
  • Privacy and Cookie Policy

Spot a mistake or want to help improve this page? Please let us know.

© 1999–2023 The Linux Professional Institute Inc. All rights reserved.