Managing the Boot Process

Mastering Systemd Targets

Systemd, a pivotal service manager in Red Hat Enterprise Linux, plays a multifaceted role beyond just launching services. Delving into the intricacies of Systemd targets enriches our understanding of system booting and management.

Understanding Systemd Targets

Systemd targets encapsulate a coherent grouping of units, extending beyond simple service activation. Of particular significance are isolatable targets, distinguished by their ability to define critical system boot states and undergo isolation when required, ensuring system integrity.

During the boot process, four primary targets shape system initialization:

• emergency.target: Serving as a lifeline during system emergencies, this target triggers only essential units, aiding in swift issue resolution with minimal resource allocation.
• rescue.target: Tailored for system recovery, this target activates all units necessary for a fully operational Linux environment while deliberately excluding non-essential services to streamline recovery operations.
• multi-user.target: Often serving as the default target, it orchestrates the activation of all components essential for comprehensive system functionality, a cornerstone in server environments.
• graphical.target: Prevalent in desktop setups, this target orchestrates the activation of all units needed for full functionality, including graphical interfaces, catering to user-centric environments.

Navigating Target Management

Effective management of Systemd targets revolves around three core tasks:

1. Automating Unit Startup: The inclusion of units for automatic startup streamlines system initialization, ensuring essential services are readily available.
2. Default Target Configuration: Setting a default target establishes the system’s baseline state, defining its behavior during boot and ensuring seamless operation.
3. Troubleshooting with Alternate Targets: Leveraging non-default targets for troubleshooting provides targeted access to system states, facilitating diagnostics and issue resolution.

Exploring Target Units

Each target’s configuration comprises two integral components:

• The Target Unit File: This file delineates the target’s properties, including dependencies and conflicts, providing crucial insights into its behavior.
• The “Wants” Directory: Housing references to unit files necessary for target activation, it ensures seamless transitioning into the desired system state.

Targets may exhibit dependencies on other targets, as specified within the target unit file. For example, the multi-user.target file signifies the standard operational state of a RHEL server, encompassing essential dependencies for server functionality.

Systemd targets, while reminiscent of older RHEL runlevels, offer enhanced versatility, grouping units to define specific system states or functionalities. Whether defining critical system states or bundling units for specific functionalities, Systemd targets serve as the linchpin for efficient system management and operation.

Understanding Wants

The concept of “wants” in Systemd is closely related to the English verb “want,” as in “I want a cookie.” In Systemd, “wants” define which units Systemd desires to start when initiating a specific target. These “wants” are established when Systemd units are enabled using the systemctl enable command, which creates symbolic links in the /etc/systemd/system directory. Within this directory, each target has a subdirectory containing symbolic links to specific services to be started. For instance, the multi-user.target includes its “wants” in /etc/systemd/system/multi-user.target.wants/.

Managing Systemd Targets

As an administrator, ensuring that required services start during server boot is paramount. This task is streamlined using the systemctl enable and systemctl disable commands. Administrators need not concern themselves with the specific target in which a service should start. Through the [Install] section in the service unit file, services autonomously determine the targets in which they need activation. When a service is enabled, a “want” is automatically created in the corresponding target. The following procedure outlines the steps for enabling a service:

1. Install the service using dnf install -y vsftpd, followed by checking its status with systemctl status vsftpd. If the service is not yet enabled, the status will indicate that it is currently disabled.
2. List the contents of /etc/systemd/system/multi-user.target.wants. Here, symbolic links manage the initiation of different services on the machine. Notice that the vsftpd.service link does not exist.
3. Enable the service with systemctl enable vsftpd. The command creates a symbolic link from the file /usr/lib/systemd/system/vsftpd.service to the directory /etc/systemd/system/multi-user.target.wants/. Essentially, enabling a Systemd unit file creates a symbolic link in the background.

Isolating Targets

Certain targets in Systemd machines hold special significance as they can be isolated. These targets define specific system states accessible after system start. By isolating a target, all its dependencies are initiated. Only targets with the isolate option enabled can be isolated. We’ll explore the systemctl isolate command later in this section. Before that, let’s examine the default targets on your computer.

To view all currently loaded targets, type systemctl --type=target. This command displays a list of all active targets. For a comprehensive overview of all targets, including inactive ones, type systemctl -t target --all.

Setting the Default Target

Setting the default target is a straightforward process achievable from the command line. To view the current default target, use systemctl get-default. Use systemctl set-default to designate the desired default target. For example, to set graphical.target as the default, ensure the necessary packages are installed. If not, use dnf group list to display all RPM package groups, install the “server with GUI” package group using dnf group install "server with gui" to install all GUI packages on the server where they haven’t been installed yet.

Working with GRUB 2

The GRUB 2 boot loader is a critical component for booting a Linux server smoothly. As an administrator, you may occasionally need to tweak its configuration to suit specific requirements. This section elucidates the process of modifying GRUB 2 settings.

Understanding GRUB 2

GRUB 2 ensures the successful booting of Linux systems. Installed in the server’s hard drive boot sector, GRUB 2 is tasked with loading the Linux kernel and the initramfs:

• The Kernel: This core component facilitates interaction between users and the server hardware.
• The initramfs: Containing essential drivers, it kickstarts the server by mounting a mini filesystem during boot, housing critical kernel modules for subsequent boot processes (e.g., LVM and SCSI modules).

While GRUB 2 typically operates smoothly without requiring much attention, there are instances where configuration adjustments become necessary. The starting point for modifying GRUB 2 configurations is the /etc/default/grub file, which contains directives guiding GRUB on its operations. Example 17-3 displays the contents of this file post-installation with default settings in RHEL.

Understanding GRUB 2 Configuration Files

Apart from /etc/default/grub, there are additional configuration files located in /etc/grub.d, housing complex shell code instructing GRUB on what to load and how to load it. However, modifications to these files are generally unnecessary. GRUB 2 automatically detects and adds new kernels to the boot menu, eliminating the need for manual intervention.

Modifying Default GRUB 2 Boot Options

To adjust GRUB 2 settings, focus on the /etc/default/grub file, where the pivotal GRUB_CMDLINE_LINUX line resides. This line defines kernel boot arguments, offering an avenue for permanent configuration fixes. Common modifications involve removing options like rhgb and quiet, which suppress boot messages. While convenient for end-users, server administrators may prefer these options removed to facilitate troubleshooting.

Another parameter of interest is GRUB_TIMEOUT, dictating the duration the server waits for user interaction before proceeding with automatic booting. For servers with lengthy BIOS checks, increasing this timeout provides more time to access the boot menu.

While navigating GRUB 2, familiarize yourself with kernel boot arguments. While numerous, understanding their whereabouts is advantageous. Refer to man 7 bootparam for an exhaustive list of boot parameters.

To finalize configuration changes, employ the grub2-mkconfig command, redirecting its output to the pertinent configuration file. On BIOS systems, execute grub2-mkconfig -o /boot/grub2/grub.cfg, while on UEFI systems, use grub2-mkconfig -o /boot/efi/EFI/redhat/grub.cfg.

Exercise 1: Isolating Targets

1. From a root shell, navigate to the directory /usr/lib/systemd/system.
2. Type grep Isolate *.target. This command displays a list of all targets allowing isolation.
3. Execute systemctl isolate rescue.target. This command switches your computer to rescue.target, requiring you to enter the root password on the server console to log in.
4. Type systemctl isolate reboot.target. This command initiates a system reboot.

Exercise 2: Applying Modifications to GRUB 2

1. Open the file /etc/default/grub with a text editor and remove the rhgb and quiet options from the GRUB_CMDLINE_LINUX line.
2. Within the same file, set the GRUB_TIMEOUT parameter to 10 seconds. Save the changes and close the editor.
3. From the command line, execute grub2-mkconfig > /boot/grub2/grub.cfg to write the changes to the GRUB 2 configuration file. (Alternatively, you could use the -o option instead of the redirector >; both methods yield the same result.)
4. Reboot the system and verify that boot messages are displayed during the boot process.