ExamFinch.com My Study

Study guide

15.3 Configure Systems to Boot into a Specific Target

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

15.3 Configure Systems to Boot into a Specific Target

Key Takeaways Explain This Topic AI

The persistent default boot goal is the target returned by systemctl get-default and set by systemctl set-default name.target (symlink default.target).

multi-user.target is text multi-user (analogous to old runlevel 3); graphical.target adds a graphical stack (old runlevel 5)—choose what the task specifies.

set-default changes future boots; systemctl isolate changes the current session toward a target without necessarily updating the default.

Verify with get-default, ls of default.target, and reboot into the expected environment (getty vs GUI).

rescue.target and emergency.target are maintenance modes—do not set them as the lasting default unless a task explicitly requires that unusual state.

Last updated: August 2026

15.3 Configure Systems to Boot into a Specific Target

Quick Answer: Show the persistent boot target with systemctl get-default . Set it with systemctl set-default multi-user.target or systemctl set-default graphical.target . Confirm the default.target symlink and reboot to prove the system comes up in the requested mode. Use isolate only for temporary live switches—not as a substitute for set-default when the exam wants a lasting default.

Deploy focus vs operate-boot (Ch8)

Section 8.2 taught manual target work: isolate , one-shot systemd.unit= on the kernel line, rescue/emergency for maintenance. Overlap is intentional. This section is the deploy skill: configure systems to boot into a specific target —the persistent default used on every normal boot.

  • Action Persistent? Typical use
  • systemctl set-default name.target Yes EX200 “boot into multi-user/graphical”
  • systemctl isolate name.target No (current transition) Live maintenance switch
  • GRUB systemd.unit=name.target No (one boot) Single recovery boot
  • systemctl get-default Read-only query Verification

If the grader reboots your VM, only set-default (or an equivalent correct change to default.target ) satisfies “always boot into X.”

What a target is

A target is a systemd unit that groups other units via dependencies—similar in spirit to SysV runlevels .

  • Target Role (practical) Classic runlevel analogy
  • poweroff.target Shutdown 0
  • rescue.target Single-user style maintenance 1
  • multi-user.target Non-graphical multi-user 3
  • graphical.target Multi-user + graphical stack 5
  • reboot.target Reboot 6
  • emergency.target Minimal emergency shell (stricter than rescue) systemctl get-default
  • ls -l /etc/systemd/system/default.target
  • readlink -f /etc/systemd/system/default.target

set-default updates the default.target symlink under /etc/systemd/system/ to point at the chosen target (usually under /usr/lib/systemd/system/ ).

  • set-default and get-default systemctl get-default
  • sudo systemctl set-default multi-user.target
  • systemctl get-default
  • # multi-user.target
  • sudo systemctl set-default graphical.target
  • systemctl get-default
  • # graphical.target # Inspect symlink after change
  • ls -l /etc/systemd/system/default.target
  • # default.target -> /usr/lib/systemd/system/multi-user.target

Idempotent habit: always get-default before and after changes. Some images already use multi-user; others use graphical.

Graphical requires bits

Setting graphical.target only works as a GUI boot if a display manager and graphical packages exist. On a minimal server image, set-default graphical.target may still set the symlink, but the boot may not present a full desktop—or may fall back/degrade depending on what is installed. For EX200:

If told multi-user (text/console multi-user), set-default multi-user.target is the standard answer.

If told graphical , ensure the environment has graphical components as the lab provides, then set-default graphical.target . systemctl is-enabled graphical.target 2>/dev/null

  • ls /usr/lib/systemd/system/graphical.target
  • systemctl list-dependencies graphical.target | head
  • multi-user vs graphical dependency relationship

Typically graphical.target includes multi-user.target (graphical is a superset goal). Enabled services with WantedBy=multi-user.target still start when booting graphical. Setting default to multi-user does not start the graphical stack on boot. systemctl list-dependencies graphical.target | head -n 40

systemctl list-dependencies multi-user.target | head -n 40

isolate is not set-default # Temporary switch toward multi-user (stops units not needed for that target—careful!)

sudo systemctl isolate multi-user.target

Effects:

Changes the running system toward that target.

May stop the GUI, user sessions, or other units not in the new tree.

Does not replace set-default for persistent exam configuration. systemctl get-default # may still show graphical.target after isolate to multi-user

Exam rule: For “configure the system to boot into multi-user.target,” use set-default , then reboot. Optional: isolate only if you also need the live system to switch immediately and the task allows the disruption—still set-default for persistence.

Rescue and emergency (do not set as casual defaults) sudo systemctl set-default rescue.target # almost never what you want long-term

sudo systemctl set-default multi-user.target # restore normal server default

rescue.target: maintenance mode with more mounted/local services than emergency; often requires root password via sulogin.

emergency.target: very minimal; root filesystem often read-only until remounted.

Ch8 covers booting once into these via GRUB. For 15.3 , unless a task explicitly says the default should be rescue (rare), keep defaults at multi-user or graphical .

How boot uses the default target

On normal boot, PID 1 (systemd) activates default.target , which is an alias to your selected target. That pulls in:

  • local-fs, sysinit, basic system
  • networking (e.g. NetworkManager when enabled)
  • gettys / display manager
  • enabled services WantedBy that target (or intermediate targets) systemctl status
  • systemctl is-system-running
  • who

After reboot into multi-user you expect text logins; into graphical you expect a display manager when installed.

  • Verification checklist (exam-complete) # 1) Set
  • sudo systemctl set-default multi-user.target
  • # 2) Read back
  • systemctl get-default
  • ls -l /etc/systemd/system/default.target
  • # 3) Reboot
  • sudo systemctl reboot
  • # 4) After login
  • systemctl get-default
  • systemctl status
  • # Confirm environment matches (no unexpected GUI requirement, services up)
  • systemctl --failed
  • Optional cross-checks: # runlevel compatibility display (may show N N or map-like output depending on tools)
  • runlevel 2>/dev/null || true
  • who -r 2>/dev/null || true

Do not rely on legacy runlevel alone— get-default is authoritative on systemd.

Changing default without set-default? (prefer set-default)

You could manually recreate the symlink: sudo ln -sf /usr/lib/systemd/system/multi-user.target /etc/systemd/system/default.target

Prefer systemctl set-default —it is the supported interface, validates the target, and matches Red Hat training. Avoid deleting default.target without replacing it.

Interaction with enabled services

Enabled services still need a boot that reaches their WantedBy target. If a service is WantedBy=multi-user.target and default is multi-user or graphical (which pulls multi-user), it should start. If someone incorrectly set default to a minimal target, multi-user services may not come up. systemctl show httpd -p WantedBy

systemctl is-enabled httpd

Deploy tasks often combine: set default target + enable --now critical services .

GRUB one-boot override (contrast only)

For a single boot into rescue without changing default:

Interrupt GRUB.

Edit kernel line: append systemd.unit=rescue.target .

Boot. systemctl get-default # still the old default after you return to normal boot

That is operate/recovery , not the persistent deploy configuration this section emphasizes. If the task says “configure the system to boot into,” it means set-default , not a one-time GRUB edit.

Server vs workstation mental model

  • Environment Common default
  • RHEL server / EX200-style VM multi-user.target
  • Workstation with GUI graphical.target

Many performance exams use server images defaulting to multi-user. Tasks that say “switch the default to multi-user” may be no-ops if already set—still run set-default and verify. Tasks that say “graphical” require the change and GUI stack awareness.

  • Exam workflows
  • Workflow A — Force multi-user default systemctl get-default
  • sudo systemctl set-default multi-user.target
  • systemctl get-default
  • sudo systemctl reboot
  • # verify: get-default still multi-user.target; console login works
  • Workflow B — Force graphical default sudo systemctl set-default graphical.target
  • systemctl get-default
  • # ensure graphical packages/DM present per lab
  • sudo systemctl reboot
  • Workflow C — Accidentally isolated; fix persistent default systemctl get-default

# if wrong:

  • sudo systemctl set-default multi-user.target
  • sudo systemctl reboot
  • # do not leave rescue as default after maintenance
  • Workflow D — Prove symlink sudo systemctl set-default multi-user.target
  • readlink -f /etc/systemd/system/default.target
  • # expect .../multi-user.target
  • Common traps

Only isolate multi-user.target then reboot—returns to old default if you never set-default .

Setting rescue/emergency as default and locking the box into maintenance every boot.

Assuming get-default changes live sessions —it does not switch the current target by itself.

Forgetting to reboot when the grader or self-check needs boot proof.

Typos: multiuser.target (wrong) vs multi-user.target (correct).

Confusing target enable with service enable: set-default ≠ enable httpd .

Hand-breaking the default.target symlink without a valid target destination.

Expecting GUI after set-default graphical.target on a headless minimal install without graphics packages.

Ignoring systemctl --failed after target change —some units may fail in the new graph.

Editing GRUB permanently for default target when set-default is the correct, simpler tool.

Relationship to other chapters

8.1 Boot/reboot: use orderly systemctl reboot to prove default target.

8.2 Manual targets: isolate and one-shot kernel parameters; this section owns persistence .

8.3 Recovery: when a bad default or failed local-fs blocks boot, interrupt GRUB—not a substitute for correct set-default once recovered.

15.2 Services: enabled services start when their target graph is reached.

Bootloader modify (later deploy chapter): kernel args and GRUB entries; still use set-default for target selection.

Section checkpoint

You should explain multi-user vs graphical targets, query with systemctl get-default , configure persistence with systemctl set-default , inspect default.target , distinguish isolate and one-boot systemd.unit= from lasting defaults, avoid rescue as a casual default, and verify with reboot plus get-default and system health checks. That is the EX200 deploy standard for booting into a specific target on RHEL 10.