Managing and Understanding the Boot Procedure
Date: Mar 5, 2020
In this sample chapter from Red Hat RHCSA 8 Cert Guide: EX200, explore how the boot procedure on Red Hat Enterprise Linux is organized, including how to use Systemd targets to boot your Linux system into a specific state and how to apply changes to the GRUB 2 boot loader.
The following topics are covered in this chapter:
Managing Systemd Targets
Working with GRUB 2
The following RHCSA exam objectives are covered in this chapter:
Configure systems to boot into a specific target automatically
Modify the system bootloader
In this chapter, you learn how the boot procedure on Red Hat Enterprise Linux is organized. In the first part of this chapter, you learn about Systemd targets and how you can use them to boot your Linux system into a specific state. The second part of this chapter discusses GRUB2 and how to apply changes to the GRUB 2 boot loader. Troubleshooting is not a topic in this chapter; it is covered in Chapter 18, “Essential Troubleshooting Skills.”
“Do I Know This Already?” Quiz
The “Do I Know This Already?” quiz allows you to assess whether you should read this entire chapter thoroughly or jump to the “Exam Preparation Tasks” section. If you are in doubt about your answers to these questions or your own assessment of your knowledge of the topics, read the entire chapter. Table 17-1 lists the major headings in this chapter and their corresponding “Do I Know This Already?” quiz questions. You can find the answers in Appendix A, “Answers to the ‘Do I Know This Already?’ Quizzes and ‘Review Questions.’”
Table 17-1 “Do I Know This Already?” Section-to-Question Mapping
Foundation Topics Section |
Questions |
|---|---|
Working with Systemd |
1–7 |
Working with GRUB 2 |
8–10 |
Which of the following is the most efficient way to define a system want?
Use the systemctl enable command.
Define the want in the unit file [Service] section.
Create a symbolic link in the /usr/lib/system/system directory.
Create a symbolic link in the unit wants directory in the /etc/system/system directory.
Which target is considered the normal target for servers to start in?
graphical.target
server.target
multi-user.target
default.target
Which of the following is not an example of a system target?
rescue.target
restart.target
multi-user.target
graphical.target
Where do you define which target a unit should be started in if it is enabled?
The target unit file
The wants directory
The systemctl.conf file
The [Install] section in the unit file
To allow targets to be isolated, you need a specific statement in the target unit file. Which of the following describes that statement?
AllowIsolate
Isolate
SetIsolate
Isolated
An administrator wants to change the current multi-user.target to the rescue.target. Which of the following should she do?
Use systemctl isolate rescue.target
Use systemctl start rescue.target
Restart the system, and from the GRUB boot prompt specify that rescue.target should be started
Use systemctl enable rescue.target --now
To which System V runlevel does multi-user.target correspond?
2
3
4
5
What is the name of the file where you should apply changes to the GRUB 2 configuration?
/boot/grub/menu.lst
/boot/grub2/grub.cfg
/etc/sysconfig/grub
/etc/default/grub
After applying changes to the GRUB 2 configuration, you need to write those changes. Which of the following commands will do that for you?
grub2 -o /boot/grub/grub.cfg
grub2-mkconfig > /boot/grub2/grub.cfg
grub2 > /boot/grub2/grub.cfg
grub2-install > /boot/grub2/grub.cfg
What is the name of the GRUB2 configuration file that is generated on a UEFI system?
/boot/efi/redhat/grub.cfg
/boot/efi/EFI/redhat/grub.cfg
/boot/EFI/grub.cfg
/boot/EFI/efi/grub.cfg
Answers
A. The systemctl enable command creates a want for the current unit in the target that is listed in the [Install] section in the service unit file.
C. Servers typically don’t run a graphical interface and will start the multi-user.target.
B. There is no restart.target.
D. Unit files contain an [Install] section that is used to specify in which target the unit should be started.
A. The required statement is AllowIsolate. All other statements mentioned here are invalid.
A. To switch from a target with more unit files to a target with fewer unit files, use systemctl isolate.
B. The multi-user.target corresponds roughly to runlevel 3 as used in a System V environment.
D. Changes to GRUB 2 need to be applied to /etc/default/grub, not to /boot/grub2/grub.cfg. The /boot/grub2/grub.cfg file cannot be edited directly; you have to apply changes to /etc/default/grub and run the grub2-mkconfig command to write them to the appropriate configuration file.
B. The grub2-mkconfig command enables you to regenerate the GRUB 2 configuration. The result, by default, is echoed to the screen. Use redirection to write it to a file.
B. The /boot/efi/EFI/redhat/grub.cfg file is used to store the GRUB 2 bootloader on a UEFI system.
Foundation Topics
Managing Systemd Targets
Systemd is the service in Red Hat Enterprise Linux 8 that is responsible for starting all kinds of things. Systemd goes way beyond starting services; other items are started from Systemd as well. In Chapter 11, “Working with Systemd,” you learned about the Systemd fundamentals; this chapter looks at how Systemd targets are used to boot your system into a specific state.
Understanding Systemd Targets
A Systemd target is basically just a group of units that belong together. Some targets are just that and nothing else, whereas other targets can be used to define the state a system is booting in, because these targets have one specific property that regular targets don’t have: they can be isolated. Isolatable targets contain everything a system needs to boot or change its current state. Four targets can be used while booting:
emergency.target: In this target only a minimal number of units are started, just enough to fix your system if something is seriously wrong. You’ll find that it is quite minimal, as some important units are not started.
rescue.target: This target starts all units that are required to get a fully operational Linux system. It doesn’t start nonessential services though.
multi-user.target: This target is often used as the default target a system starts in. It starts everything that is needed for full system functionality and is commonly used on servers.
graphical.target: This target also is commonly used. It starts all units that are needed for full functionality, as well as a graphical interface.
Working with Targets
Working with targets may seem complicated, but it is not. It drills down to three common tasks:
Adding units to be automatically started
Setting a default target
Running a nondefault target to enter troubleshooting mode
In Chapter 11 you learned how to use the systemctl enable and systemctl disable commands to add services to or remove services from targets. In this chapter you’ll learn how to set a default target and how to run a nondefault target to enter troubleshooting mode. But first we’ll take a closer look at the working of targets under the hood.
Understanding Target Units
Behind a target there is some configuration. This configuration consists of two parts:
The target unit file
The “wants” directory, which contains references to all unit files that need to be loaded when entering a specific target
Targets by themselves can have dependencies to other targets, which are defined in the target unit file. Example 17-1 shows the definition of the multi-user.target file, which defines the normal operational state of a RHEL server.
Example 17-1 The multi-user.target File
[root@localhost ~]# systemctl cat multi-user.target
# /usr/lib/systemd/system/multi-user.target
# SPDX-License-Identifier: LGPL-2.1+
#
# This file is part of systemd.
#
# systemd is free software; you can redistribute it and/or modify it
# under the terms of the GNU Lesser General Public License as
published by
# the Free Software Foundation; either version 2.1 of the License,
or
# (at your option) any later version.
[Unit]
Description=Multi-User System
Documentation=man:systemd.special(7)
Requires=basic.target
Conflicts=rescue.service rescue.target
After=basic.target rescue.service rescue.target
AllowIsolate=yes
You can see that by itself the target unit does not contain much. It just defines what it requires and which services and targets it cannot coexist with. It also defines load ordering, by using the After statement in the [Unit] section. The target file does not contain any information about the units that should be included; that is in the individual unit files and the wants (explained in the upcoming section “Understanding Wants”).
Systemd targets look a bit like runlevels used in previous versions of RHEL, but targets are more than that. A target is a group of units, and there are multiple different targets. Some targets, such as the multi-user.target and the graphical.target, define a specific state that the system needs to enter. Other targets just bundle a group of units together, such as the nfs.target and the printer.target. These targets are included from other targets, such as multi-user.target or graphical.target.
Understanding Wants
Understanding the concept of a want simply requires understanding the verb want in the English language, as in “I want a cookie.” Wants in Systemd define which units Systemd wants when starting a specific target. Wants are created when Systemd units are enabled using systemctl enable, and this happens by creating a symbolic link in the /etc/systemd/system directory. In this directory, you’ll find a subdirectory for every target, containing wants as symbolic links to specific services that are to be started.
Managing Systemd Targets
As an administrator, you need to make sure that the required services are started when your server boots. To do this, use the systemctl enable and systemctl disable commands. You do not have to think about the specific target a service has to be started in. Through the [Install] section in the service unit file, the services know for themselves in which targets they need to be started, and a want is created automatically in that target when the service is enabled. The following procedure walks you through the steps of enabling a service:
Type systemctl status vsftpd. If the service has not yet been enabled, the Loaded line will show that it currently is disabled:
[root@server202 ~]# systemctl status vsftpd vsftpd.service - Vsftpd ftp daemon Loaded: loaded (/usr/lib/systemd/system/vsftpd.service; disabled) Active: inactive (dead)Type ls /etc/systemd/system/multi-user.target.wants. You’ll see symbolic links that are taking care of starting the different services on your machine. You can also see that the vsftpd.service link does not exist.
Type systemctl enable vsftpd. The command shows you that it is creating a symbolic link for the file /usr/lib/systemd/system/vsftpd.service to the directory /etc/systemd/system/multi-user.target.wants. So basically, when you enable a Systemd unit file, in the background a symbolic link is created.
Isolating Targets
As already discussed, on Systemd machines there are several targets. You also know that a target is a collection of units. Some of those targets have a special role because they can be isolated. These are also the targets that you can set as the targets to get into after system start.
By isolating a target, you start that target with all of its dependencies. Only targets that have the isolate option enabled can be isolated. We’ll explore the systemctl isolate command later in this section. Before doing that, let’s take a look at the default targets on your computer.
To get a list of all targets currently loaded, type systemctl --type=target. You’ll see a list of all the targets currently active. If your server is running a graphical environment, this will include all the dependencies required to install the graphical.target also. However, this list shows only the active targets, not all the targets. Type systemctl --type=target --all for an overview of all targets that exist on your computer. You’ll now see inactive targets also (see Example 17-2).
Example 17-2 Showing System Targets
root@localhost ~]# systemctl --type=target --all
UNIT LOAD ACTIVE SUB DESCRIPTION
basic.target loaded active active Basic System
bluetooth.target loaded active active Bluetooth
cryptsetup.target loaded active active Local Encrypted
Volumes
dbus.target not-found inactive dead dbus.target
emergency.target loaded inactive dead Emergency Mode
getty-pre.target loaded active active Login Prompts
(Pre)
getty.target loaded active active Login Prompts
graphical.target loaded active active Graphical
Interface
initrd-fs.target loaded inactive dead Initrd File
Systems
initrd-root-device.target loaded inactive dead Initrd Root
Device
initrd-root-fs.target loaded inactive dead Initrd Root File
System
initrd-switch-root.target loaded inactive dead Switch Root
initrd.target loaded inactive dead Initrd Default
Target
local-fs-pre.target loaded active active Local File
Systems (Pre)
local-fs.target loaded active active Local File
Systems
multi-user.target loaded active active Multi-User
System
network-online.target loaded active active Network is
Online
network-pre.target loaded active active Network (Pre)
network.target loaded active active Network
nfs-client.target loaded active active NFS client
services
nss-lookup.target loaded inactive dead Host and Network
Name Lookups
nss-user-lookup.target loaded active active User and Group
Name Lookups
paths.target loaded active active Paths
remote-fs-pre.target loaded active active Remote File
Systems (Pre)
remote-fs.target loaded active active Remote File
Systems
rescue.target loaded inactive dead Rescue Mode
rpc_pipefs.target loaded active active rpc_pipefs.
target
rpcbind.target loaded active active RPC Port Mapper
shutdown.target loaded inactive dead Shutdown
slices.target loaded active active Slices
sockets.target loaded active active Sockets
sound.target loaded active active Sound Card
sshd-keygen.target loaded active active sshd-keygen.
target
swap.target loaded active active Swap
sysinit.target loaded active active System
Initialization
Of the targets on your system, a few have an important role because they can be started (isolated) to determine the state your server starts in. These are also the targets that can be set as the default targets. These targets also roughly correspond to runlevels used on earlier versions of RHEL. These are the following targets:
poweroff.target runlevel 0
rescue.target runlevel 1
multi-user.target runlevel 3
graphical.target runlevel 5
reboot.target runlevel 6
If you look at the contents of each of these targets, you’ll also see that they contain the AllowIsolate=yes line. That means that you can switch the current state of your computer to either one of these targets using the systemctl isolate command. Exercise 17-1 shows you how to do this.
Exercise 17-1 Isolating Targets
From a root shell, go to the directory /usr/lib/systemd/system. Type grep Isolate *.target. This shows a list of all targets that allow isolation.
Type systemctl isolate rescue.target. This switches your computer to rescue.target. You need to type the root password on the console of your server to log in.
Type systemctl isolate reboot.target. This restarts your computer.
Setting the Default Target
Setting the default target is an easy procedure that can be accomplished from the command line. Type systemctl get-default to see the current default target and use systemctl set-default to set the desired default target.
To set the graphical.target as the default target, you need to make sure that the required packages are installed. If this is not the case, you can use the yum group list command to show a list of all RPM package groups. The “server with gui” and “GNOME Desktop” package groups both apply. Use yum group install "server with gui" to install all GUI packages on a server where they have not been installed yet.
Working with GRUB 2
The GRUB 2 boot loader is one of the first things that needs to be working well to boot a Linux server. As an administrator, you will sometimes need to apply modifications to the GRUB 2 boot loader configuration. This section explains how to do so. The RHEL 8 boot procedure is discussed in more detail in Chapter 18, where troubleshooting topics are covered as well.
Understanding GRUB 2
The GRUB 2 boot loader makes sure that you can boot Linux. GRUB 2 is installed in the boot sector of your server’s hard drive and is configured to load a Linux kernel and the initramfs:
The kernel is the heart of the operating system, allowing users to interact with the hardware that is installed in the server.
The initramfs contains drivers that are needed to start your server. It contains a mini file system that is mounted during boot. In it are kernel modules that are needed during the rest of the boot process (for example, the LVM modules and SCSI modules for accessing disks that are not supported by default).
Normally, GRUB 2 works just fine and does not need much maintenance. In some cases, though, you might have to change its configuration. To apply changes to the GRUB 2 configuration, the starting point is the /etc/default/grub file, which has options that tell GRUB what to do and how to do it. Example 17-3 shows the contents of this file after an installation with default settings of RHEL 8.
Example 17-3 Contents of the /etc/default/grub File
[root@localhost ~]# cat /etc/default/grub GRUB_TIMEOUT=5 GRUB_DISTRIBUTOR="$(sed 's, release .*$,,g' /etc/system-release)" GRUB_DEFAULT=saved GRUB_DISABLE_SUBMENU=true GRUB_TERMINAL_OUTPUT="console" GRUB_CMDLINE_LINUX="crashkernel=auto resume=/dev/mapper/rhel-swap rd.lvm.lv=rhel/root rd.lvm.lv=rhel/swap rhgb quiet" GRUB_DISABLE_RECOVERY="true" GRUB_ENABLE_BLSCFG=true
As you can see, the /etc/default/grub file does not contain much information. The most important part that it configures is the GRUB_CMDLINE_LINUX option. This line contains boot arguments for the kernel on your server.
Apart from the configuration in /etc/default/grub, there are a few configuration files in /etc/grub.d. In these files, you’ll find rather complicated shell code that tells GRUB what to load and how to load it. You typically do not have to modify these files. You also do not need to modify anything if you want the capability to select from different kernels while booting. GRUB 2 picks up new kernels automatically and adds them to the boot menu automatically, so nothing has to be added manually.
Understanding GRUB 2 Configuration Files
Based on the configuration files mentioned previously, the main configuration file is created. If your system is a BIOS system, the name of the file is /boot/grub2/grub.cf. On a UEFI system the file is written to /boot/efi/EFI/redhat. After making modifications to the GRUB 2 configuration, you’ll need to regenerate the relevant configuration file, which is why you should know the name of the file that applies to your system architecture. Do not edit it, as this file is automatically generated.
Modifying Default GRUB 2 Boot Options
To apply modifications to the GRUB 2 boot loader, the file /etc/default/grub is your entry point. The most important line in this file is GRUB_CMDLINE_LINUX, which defines how the Linux kernel should be started. In this line, you can apply permanent fixes to the GRUB 2 configuration. Some likely candidates for removal are the options rhgb and quiet. These options tell the kernel to hide all output while booting. That is nice to hide confusing messages for end users, but if you are a server administrator, you probably just want to remove these options.
Another interesting parameter is GRUB_TIMEOUT. This defines the amount of time your server waits for you to access the GRUB 2 boot menu before it continues booting automatically. If your server runs on physical hardware that takes a long time to get through the BIOS checks, it may be interesting to increase this time a bit.
While working with GRUB 2, you need to know a bit about kernel boot arguments. There are many of them, and most of them you’ll never use, but it is good to know where you can find them. Type man 7 bootparam for a man page that contains an excellent description of all boot parameters that you may use while starting the kernel.
To write the modified configuration to the appropriate files, you use the grub2-mkconfig command and redirect its output to the appropriate configuration file. On a BIOS system, the command would be grub2-mkconfig -o /boot/grub2/grub.cfg, and on a UEFI system the command would be grub2-mkconfig -o /boot/efi/EFI/redhat/grub.cfg.
In Exercise 17-2, you learn how to apply modifications to the GRUB 2 configuration and write them to the /boot/grub2/grub.cfg configuration file.
Exercise 17-2 Applying Modifications to GRUB 2
Open the file /etc/default/grub with an editor and remove the rhgb and quiet options from the GRUB_CMDLINE_LINUX line.
From the same file, set the GRUB_TIMEOUT parameter to 10 seconds. Save changes to the file and close the editor.
From the command line, type grub2-mkconfig > /boot/grub2/grub.cfg to write the changes to GRUB 2. (Note that instead of using the redirector > to write changes to the grub.cfg file, you could use the -o option. Both methods have the same result.)
Reboot and verify that while booting you see boot messages scrolling by.
Summary
In this chapter you learned how Systemd and GRUB 2 are used to bring your server into the exact state you desire at the end of the boot procedure. You also learned how Systemd is organized, and how units can be configured for automatic start with the use of targets. Finally, you read how to apply changes to the default GRUB 2 boot loader. In the next chapter, you learn how to troubleshoot the boot procedure and fix some common problems.
Exam Preparation Tasks
As mentioned in the section “How to Use This Book” in the Introduction, you have several choices for exam preparation: the end-of-chapter labs; the memory tables in Appendix B; Chapter 26, “Final Preparation”; and the practice exams.
Review All Key Topics
Review the most important topics in the chapter, noted with the Key Topic icon in the outer margin of the page. Table 17-2 lists a reference of these key topics and the page number on which each is found.
Table 17-2 Key Topics for Chapter 17
Key Topic Element |
Description |
Page |
|---|---|---|
Section |
Understanding target units |
389 |
Section |
Managing Systemd targets |
390 |
Exercise 17-1 |
Isolating targets |
393 |
List |
Explanation of the role of kernel and initramfs |
394 |
Example 17-3 |
Contents of the /etc/default/grub file |
394 |
Exercise 17-2 |
Applying modifications to GRUB 2 |
396 |
Define Key Terms
Define the following key terms from this chapter and check your answers in the glossary:
unit
wants
target
Systemd
dependencies
initramfs
kernel
boot loader
GRUB
Review Questions
The questions that follow are meant to help you test your knowledge of concepts and terminology and the breadth of your knowledge. You can find the answers to these questions in Appendix A.
What is a unit?
Which command enables you to make sure that a target is no longer eligible for automatic start on system boot?
Which configuration file should you modify to apply common changes to GRUB 2?
Which command should you use to show all service units that are currently loaded?
How do you create a want for a service?
How do you switch the current operational target to the rescue.target?
Why can it happen that you get the message that a target cannot be isolated?
You want to shut down a Systemd service, but before doing that you want to know which other units have dependencies to this service. Which command would you use?
What is the name of the GRUB 2 configuration file where you apply changes to GRUB 2?
After applying changes to the GRUB 2 configuration, which command should you run?
Answer
A unit is a thing that is started by systemd. There are different types of units, such as services, mounts, sockets, and many more.
Use systemctl mask to make sure that a target is no longer eligible for automatic start on system boot.
Modify /etc/default/grub to apply common changes to GRUB 2.
systemctl --type=service shows all service units that are currently loaded.
Create a want for a service by using systemctl enable on that service.
systemctl isolate rescue.target switches the current operational target to the rescue target.
There are two types of targets: targets that can run independently and targets that cannot. Check the target unit file to find out more about this and ensure the target is isolatable (which means it can run independently).
systemctl list-dependencies --reverse shows which other units have dependencies to a systemd service.
Apply changes to GRUB 2 in /etc/default/grub.
Run grub2-mkconfig > /boot/grub2/grub.cfg after applying changes to the GRUB 2 configuration.
End-of-Chapter Labs
You have now learned how to work with Systemd targets and the GRUB 2 boot loader. Before continuing, it is a good idea to work on some labs that help you ensure that you can apply the skills that you acquired in this chapter.
Lab 17.1
Set the default target to multi-user.target.
Reboot to verify this is working as expected.
Lab 17.2
Change your GRUB 2 boot configuration so that you will see boot messages upon startup.