8.2 Boot Systems into Different Targets Manually

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

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

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:

1. systemctl set-default multi-user.target
2. systemctl get-default confirms
3. systemctl reboot
4. 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:

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:

1. Reboot and interrupt GRUB (often Esc or hold Shift on BIOS systems; UEFI behavior varies—use the lab’s documented key).
2. Highlight the kernel entry → e to edit.
3. Find the line starting with linux / linuxefi.
4. Append a space and:

systemd.unit=rescue.target

or

systemd.unit=emergency.target

1. 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=

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

1. Using isolate when the task requires set-default (fails after grader reboot).
2. Setting graphical.target without a working GUI stack → failed/degraded boot experience.
3. Isolating rescue over SSH only → lost session, no console plan.
4. Confusing emergency with rescue and fighting a read-only root without remount.
5. Typos in systemd.unit= on GRUB line → unexpected target or ignored token.
6. 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.