Managing and Understanding the Boot Procedure

Date: Nov 18, 2021

In this sample chapter from Red Hat RHCSA 8 Cert Guide: EX200, 2nd Edition, you will learn about Systemd targets and how the boot procedure on Red Hat Enterprise Linux is organized.

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?
1. Use the systemctl enable command.
2. Define the want in the unit file [Service] section.
3. Create a symbolic link in the /usr/lib/system/system directory.
4. 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?
1. graphical.target
2. server.target
3. multi-user.target
4. default.target
Which of the following is not an example of a system target?
1. rescue.target
2. restart.target
3. multi-user.target
4. graphical.target
Where do you define which target a unit should be started in if it is enabled?
1. The target unit file
2. The wants directory
3. The systemctl.conf file
4. 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?
1. AllowIsolate
2. Isolate
3. SetIsolate
4. Isolated
An administrator wants to change the current multi-user.target to the rescue.target. Which of the following should she do?
1. Use systemctl isolate rescue.target
2. Use systemctl start rescue.target
3. Restart the system, and from the GRUB boot prompt specify that rescue.target should be started
4. Use systemctl enable rescue.target --now
To which System V runlevel does multi-user.target correspond?
1. 2
2. 3
3. 4
4. 5
What is the name of the file where you should apply changes to the GRUB 2 configuration?
1. /boot/grub/menu.lst
2. /boot/grub2/grub.cfg
3. /etc/sysconfig/grub
4. /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?
1. grub2 -o /boot/grub/grub.cfg
2. grub2-mkconfig > /boot/grub2/grub.cfg
3. grub2 > /boot/grub2/grub.cfg
4. grub2-install > /boot/grub2/grub.cfg
What is the name of the GRUB2 configuration file that is generated on a UEFI system?
1. /boot/efi/redhat/grub.cfg
2. /boot/efi/EFI/redhat/grub.cfg
3. /boot/EFI/grub.cfg
4. /boot/EFI/efi/grub.cfg

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 learn how to set a default target and how to run a nondefault target to enter troubleshooting mode. But first let’s 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 yum install -y vsftpd, followed by 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.targetloaded    inactive dead   Initrd Root
                                                       Device
  initrd-root-fs.target    loaded    inactive dead   Initrd Root File
                                                       System      
  initrd-switch-root.targetloaded    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.

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.cfg. On a UEFI system the file is written to /boot/efi/EFI/redhat on RHEL and /boot/efi/EFI/centos on CentOS. 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 27, “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?

End-of-Chapter Labs

You have now learned how to work with Systemd targets and the GRUB 2 boot loader. Before you continue, 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.