ExamFinch.com My Study

Study guide

8.2 Boot Systems into Different Targets Manually

Practice this exam

Red Hat Certified System Administrator RHCSA

Track your progress as you read

Finished sections get a check mark.

1 Introduction & Exam Overview

1.1 Current Exam Facts 1.2 Lab Setup & Performance-Based Study Strategy

2 Essential Tools: Shell, Redirection & Text Analysis

2.1 Shell Prompt and Command Syntax 2.2 Input-Output Redirection and Pipes 2.3 grep and Regular Expressions for Text Analysis

3 Essential Tools: Remote Access, Users & Text Editing

3.1 Access Remote Systems Using SSH 3.2 Log In and Switch Users in Multiuser Targets 3.3 Create and Edit Text Files

4 Essential Tools: Files, Links & Archives

4.1 Create, Delete, Copy, and Move Files and Directories 4.2 Hard and Soft Links 4.3 Archive and Compress with tar, gzip, and bzip2

5 Essential Tools: Permissions & System Documentation

5.1 List, Set, and Change Standard ugo/rwx Permissions 5.2 System Documentation: man, info, and /usr/share/doc

6 Manage Software: RPM and Flatpak

6.1 Configure Access to RPM Repositories 6.2 Install and Remove RPM Software Packages 6.3 Configure Access to Flatpak Repositories 6.4 Install and Remove Flatpak Software Packages

7 Create Simple Shell Scripts

7.1 Conditional Execution: if, test, and [] 7.2 Looping Constructs for Files and Input 7.3 Process Script Inputs ($1, $2, and Beyond) 7.4 Process Shell Command Output in Scripts

8 Operate Running Systems: Boot and Recovery

8.1 Boot, Reboot, and Shut Down a System Normally 8.2 Boot Systems into Different Targets Manually 8.3 Interrupt the Boot Process to Gain Access

9 Operate Running Systems: Processes and Tuning

9.1 Identify and Kill CPU/Memory Intensive Processes 9.2 Adjust Process Scheduling 9.3 Manage Tuning Profiles

10 Operate Running Systems: Logs, Services & File Transfer

10.1 Locate and Interpret System Log Files and Journals 10.2 Preserve System Journals 10.3 Start, Stop, and Check Status of Network Services 10.4 Securely Transfer Files Between Systems

11 Configure Local Storage: Partitions and LVM

11.1 List, Create, and Delete Partitions on GPT Disks 11.2 Create and Remove Physical Volumes 11.3 Assign Physical Volumes to Volume Groups 11.4 Create and Delete Logical Volumes

12 Configure Local Storage: Mounting and Expansion

12.1 Mount File Systems at Boot by UUID or Label 12.2 Add Partitions, Logical Volumes, and Swap Non-Destructively

13 Create and Configure File Systems: Local FS and Permissions

13.1 Create, Mount, and Use VFAT, ext4, and XFS File Systems 13.2 Extend Existing Logical Volumes 13.3 Diagnose and Correct File Permission Problems

14 Create and Configure File Systems: NFS and autofs

14.1 Mount and Unmount Network File Systems Using NFS 14.2 Configure autofs

15 Deploy and Maintain: Scheduling, Services & Targets

15.1 Schedule Tasks with at, cron, and systemd Timers 15.2 Start, Stop, and Enable Services at Boot 15.3 Configure Systems to Boot into a Specific Target

16 Deploy and Maintain: Time, Software Updates & Bootloader

16.1 Configure Time Service Clients 16.2 Install and Update Software from CDN, Remote Repos, and Local Files 16.3 Modify the System Bootloader

17 Manage Basic Networking

17.1 Configure IPv4 and IPv6 Addresses 17.2 Configure Hostname Resolution 17.3 Configure Network Services to Start Automatically at Boot 17.4 Restrict Network Access Using firewalld and firewall-cmd

18 Manage Users and Groups

18.1 Create, Delete, and Modify Local User Accounts 18.2 Change Passwords and Adjust Password Aging 18.3 Create, Delete, and Modify Local Groups and Memberships 18.4 Configure Privileged Access

19 Manage Security: Firewall, umask & SSH Keys

19.1 Configure Firewall Settings with firewall-cmd and firewalld 19.2 Manage Default File Permissions 19.3 Configure Key-Based Authentication for SSH

20 Manage Security: SELinux Modes and Contexts

20.1 Set Enforcing and Permissive Modes for SELinux 20.2 List and Identify SELinux File and Process Contexts 20.3 Restore Default File Contexts

21 Manage Security: SELinux Ports and Booleans

21.1 Manage SELinux Port Labels 21.2 Use Boolean Settings to Modify SELinux Settings

8.2 Boot Systems into Different Targets Manually

Key Takeaways Explain This Topic AI

systemd targets group units into boot goals; common ones are multi-user.target, graphical.target, rescue.target, and emergency.target.

systemctl get-default and systemctl set-default manage the persistent default target used on normal boots.

systemctl isolate name.target switches the running system toward that target immediately (manual change, not only at boot).

Rescue is a single-user maintenance mode with more services than emergency; emergency is minimal with root filesystem often read-only.

You can select a target for one boot from the GRUB kernel command line (systemd.unit=) without permanently changing the default.

Last updated: August 2026

8.2 Boot Systems into Different Targets Manually

Quick Answer: systemd targets are boot/operation goals. Check the default with systemctl get-default ; set it with systemctl set-default multi-user.target (or graphical.target ). Switch live with systemctl isolate rescue.target (careful). For one boot only, edit the GRUB kernel line to add systemd.unit=rescue.target (or another target). Know multi-user , graphical , rescue , and emergency for EX200.

Why targets matter

Classic SysV runlevels (3, 5, 1, …) map conceptually onto systemd targets . EX200 expects you to boot systems into different targets manually —maintenance modes, text multi-user without GUI, or graphical when required—and to understand how temporary switches differ from the default target stored on disk.

Related deploy objective (“configure systems to boot into a specific target”) emphasizes persistence via set-default . This section focuses on manual selection and the target model you need for both.

Targets vs services

  • Concept Role
  • Unit A systemd object: service, socket, mount, target, timer, …
  • Service Runs a daemon or oneshot process ( sshd.service )
  • Target A synchronization point / goal that pulls in other units via dependencies

Starting multi-user.target does not mean one binary named multi-user; it means “bring the system to a state where multi-user networking and gettys are up,” by activating many Wants/Requires relationships.

  • List targets: systemctl list-units --type=target
  • systemctl list-units --type=target --all
  • systemctl list-unit-files --type=target
  • Essential targets for RHCSA
  • multi-user.target
  • Non-graphical multi-user system
  • Networking, sshd (if enabled), text logins (gettys)
  • Common server default
  • Rough SysV analogy: runlevel 3
  • graphical.target
  • Multi-user plus graphical display manager / GUI stack
  • Typical desktop default when a GUI is installed
  • Rough SysV analogy: runlevel 5

If GUI packages are missing, setting this default can yield a degraded or failed graphical path—install needed groups/packages first in real life

  • rescue.target
  • Single-user-style maintenance mode
  • More of the base system is up than emergency (including more mounts/services depending on dependencies)
  • Often used for repair when you still want a relatively complete single-user environment
  • Requires root authentication for the rescue shell in normal configurations
  • Rough SysV analogy: runlevel 1 / rescue
  • emergency.target
  • Minimal environment for emergency repair
  • Sulogin prompt; root filesystem may be mounted read-only
  • Fewer dependencies—useful when rescue itself cannot start because of a broken unit
  • You may need mount -o remount,rw / before editing files
  • Other targets you will see
  • Target Notes
  • default.target Alias to the configured default (symlink under /etc/systemd/system/default.target )
  • network-online.target Synchronization point for “network is up” (services pull it; not a full boot mode)
  • reboot.target / poweroff.target / halt.target Shutdown-related goals
  • initrd-root-fs.target etc. Early boot inside initramfs—advanced

For EX200, master multi-user , graphical , rescue , and emergency first.

  • Inspecting the default and current state systemctl get-default
  • # example output: multi-user.target
  • ls -l /etc/systemd/system/default.target
  • # symlink to /usr/lib/systemd/system/multi-user.target or graphical.target
  • systemctl status multi-user.target
  • systemctl status graphical.target
  • systemctl is-active multi-user.target

get-default is the operator-friendly check. The symlink under /etc/systemd/system/default.target is what systemd uses as the default boot goal on a normal start.

  • Changing the default target (persistent) # Prefer multi-user (no GUI goal at boot)
  • sudo systemctl set-default multi-user.target
  • # Prefer graphical
  • sudo systemctl set-default graphical.target

systemctl get-default

set-default adjusts the symlink so the next normal boots use that target. It does not by itself rebuild the live session into a GUI; use isolate or reboot to experience the new default.

Exam pattern:

  • systemctl set-default multi-user.target
  • systemctl get-default confirms
  • systemctl reboot

After boot, confirm no display-manager requirement if that was the intent; who -r / target active state as applicable

Never only isolate if the task says the system must boot into a target by default—graders reboot.

  • systemctl isolate — manual switch on a running system sudo systemctl isolate multi-user.target
  • sudo systemctl isolate graphical.target
  • sudo systemctl isolate rescue.target

isolate activates the named target and stops units not belonging to its dependency tree . That is powerful and dangerous:

Isolating multi-user.target from a GUI session tears down graphical services.

Isolating rescue.target drops the machine toward rescue maintenance mode— SSH and multi-user services can die .

You can lock yourself out of a remote-only host if you isolate rescue without console access.

Use isolate when:

You have console access (or accept session loss).

You need to manually enter a maintenance mode without full reboot.

  • A task explicitly asks to switch targets now. # See what isolate would imply—still read man systemctl
  • man systemctl
  • # isolate is related to starting a target and stopping conflicting units

To leave rescue after maintenance (from the rescue environment), boot/isolate back to multi-user or reboot: sudo systemctl isolate multi-user.target

  • # or
  • sudo systemctl reboot
  • emergency vs rescue — choosing and entering sudo systemctl isolate emergency.target
  • sudo systemctl isolate rescue.target

Comparison for exams and real break/fix:

  • Concern rescue.target emergency.target
  • Footprint Larger single-user maintenance Minimal
  • Root FS Typically read-write capable path Often read-only until remount
  • When to use General maintenance, many repair tasks When even rescue fails or you need minimalism
  • Auth root password / sulogin style access root sulogin

If local root password is unknown, isolate alone may not help—you need Section 8.3 boot interrupt / password reset techniques.

One-shot boot into a target (GRUB kernel command line)

To boot once into a target without changing default.target :

Reboot and interrupt GRUB (often Esc or hold Shift on BIOS systems; UEFI behavior varies—use the lab’s documented key).

Highlight the kernel entry → e to edit.

Find the line starting with linux / linuxefi .

  • Append a space and: systemd.unit=rescue.target
  • or systemd.unit=emergency.target

Boot with Ctrl+x (or F10 on some systems).

This affects only that boot unless you also change the default on disk. Excellent for temporary recovery without forgetting to set the default back.

Alternative historical aliases sometimes seen in docs ( 1 , s , single ) may map to rescue-like behavior on some systems; prefer explicit systemd.unit= on modern RHEL for clarity.

  • Practical scenarios
  • Scenario A — Server should not boot to GUI systemctl get-default
  • sudo systemctl set-default multi-user.target
  • sudo systemctl reboot
  • # verify
  • systemctl get-default
  • systemctl status graphical.target # likely inactive if not pulled in
  • Scenario B — Enter rescue for maintenance, then return
  • From console: sudo systemctl isolate rescue.target
  • # authenticate; perform repairs
  • sudo systemctl isolate multi-user.target

Or reboot with systemd.unit=rescue.target once from GRUB if the system is unhealthy for isolate.

  • Scenario C — emergency shell, remount root RW, fix fstab typo # after emergency shell
  • mount -o remount,rw /
  • vim /etc/fstab
  • systemctl daemon-reload # if needed for unit changes
  • systemctl reboot

(Exact emergency tooling depends on how far the system got; initramfs emergencies differ slightly—see storage failures and Section 8.3.)

set-default vs isolate vs systemd.unit=

  • Method Persistence Scope
  • systemctl set-default … Permanent until changed Future normal boots
  • systemctl isolate … Temporary live switch Current boot session path
  • GRUB systemd.unit=… Single boot only Next boot only

Trap: Isolating multi-user.target is not the same as set-default multi-user.target . After reboot, the symlink default wins again.

Dependencies and “why did SSH die?”

Targets pull units through Wants= / Requires= / Conflicts= . Isolating a smaller target stops conflicting multi-user services. That is expected. Document for yourself: console first before rescue isolate on remote machines.

  • Inspect a target’s dependencies: systemctl show multi-user.target -p Wants -p Requires
  • systemctl list-dependencies multi-user.target
  • systemctl list-dependencies rescue.target
  • Common traps

Using isolate when the task requires set-default (fails after grader reboot).

Setting graphical.target without a working GUI stack → failed/degraded boot experience.

Isolating rescue over SSH only → lost session, no console plan.

Confusing emergency with rescue and fighting a read-only root without remount.

Typos in systemd.unit= on GRUB line → unexpected target or ignored token.

Editing GRUB for one boot but forgetting Ctrl+x to boot the edited entry.

Section checkpoint

You should name the major targets, read and set the default with get-default / set-default , manually switch with isolate when appropriate, boot once via GRUB systemd.unit= , compare rescue vs emergency, and choose the method that matches temporary vs persistent exam wording.