15.3 Configure Systems to Boot into a Specific Target

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.

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.

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:

1. Interrupt GRUB.
2. Edit kernel line: append systemd.unit=rescue.target.
3. 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

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

1. Only isolate multi-user.target then reboot—returns to old default if you never set-default.
2. Setting rescue/emergency as default and locking the box into maintenance every boot.
3. Assuming get-default changes live sessions—it does not switch the current target by itself.
4. Forgetting to reboot when the grader or self-check needs boot proof.
5. Typos: multiuser.target (wrong) vs multi-user.target (correct).
6. Confusing target enable with service enable: set-default ≠ enable httpd.
7. Hand-breaking the default.target symlink without a valid target destination.
8. Expecting GUI after set-default graphical.target on a headless minimal install without graphics packages.
9. Ignoring systemctl --failed after target change—some units may fail in the new graph.
10. 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.