8.1 Boot, Reboot, and Shut Down a System Normally

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.1 Boot, Reboot, and Shut Down a System Normally

Key Takeaways Explain This Topic AI

On RHEL 10, prefer systemctl reboot, systemctl poweroff, and systemctl halt for orderly restarts and shutdowns under systemd.

Legacy reboot, poweroff, halt, and shutdown commands usually map into the same systemd logic—know both styles for the exam.

A normal boot loads firmware → GRUB → kernel/initramfs → systemd (PID 1) → default target units and services.

Orderly shutdown stops services, unmounts filesystems cleanly, and avoids journal/filesystem damage that a hard power cut can cause.

EX200 expects configurations that survive reboot; after reboot/poweroff cycles, re-verify services, mounts, and network state.

Last updated: August 2026

8.1 Boot, Reboot, and Shut Down a System Normally

Quick Answer: On RHEL 10, reboot with systemctl reboot , power off with systemctl poweroff , and halt with systemctl halt . These perform orderly transitions through systemd. A normal boot ends in the configured default target (often multi-user.target or graphical.target ). Prefer graceful commands over pulling virtual power—EX200 grades post-reboot state , so clean restarts matter.

Why this skill is on EX200

Official study points under Operate running systems include boot, reboot, and shut down a system normally . Performance exams constantly imply reboot: enable a service, write /etc/fstab , change network config, set a default target—then prove it still works after restart. You must:

Understand what “normal boot” means on a systemd RHEL system.

Restart or power off cleanly so units stop and filesystems unmount correctly.

Know the modern systemctl verbs and the classic command names still present on the box.

This section is operational hygiene. Later sections cover targets, recovery, and bootloader work; here the focus is everyday power control.

High-level boot sequence (normal path)

A healthy RHEL boot roughly follows:

Stage What happens
Firmware (BIOS/UEFI) Hardware init; handoff to bootloader
GRUB2 Loads kernel and initramfs ( initrd ); may present a menu
Kernel + initramfs Mounts real root (often after LVM/crypto hooks); starts systemd as PID 1
systemd Reads default target; starts dependency tree of units

Local-fs / sysinit Mounts local filesystems, applies sysctl, etc.

Multi-user / graphical Starts networking, gettys/login, optional GUI

You do not need to memorize every unit name for this objective, but you must know that systemd is PID 1 and that “the system is up” means the default target and its dependencies reached active state.

Check the default target and recent boots: systemctl get-default
systemctl status
who -b
last reboot | head
journalctl -b # current boot
journalctl -b -1 # previous boot

who -b and last reboot are quick proof that a reboot occurred—useful when documenting lab work or confirming a remote host came back.

Orderly reboot and shutdown with systemctl
On RHEL 10, systemctl is the preferred control surface: # Restart the machine (orderly)
sudo systemctl reboot

# Power off (orderly halt + power cut when hardware supports it)
sudo systemctl poweroff

# Halt the system (stop OS; power state depends on hardware/firmware)
sudo systemctl halt

# Optional: go to firmware setup on next boot when supported
sudo systemctl reboot --firmware-setup

Command Typical intent
systemctl reboot Clean restart; return to default target
systemctl poweroff Clean shutdown and power off
systemctl halt Stop the system (often similar end state to poweroff on VMs—know the difference conceptually)
systemctl suspend / hibernate Sleep states (usually not EX200 focus)
What “orderly” means

When you request reboot/poweroff through systemd:

systemd broadcasts a shutdown/reboot job.

Services receive stop jobs according to dependencies and timeouts.

Processes are terminated; stubborn ones may be killed after timeouts.

Filesystems are remounted read-only / unmounted as designed.

Final sync and reboot or power-off syscall runs.

That sequence protects journals, databases, and dirty page cache better than a hard power-off. In a VM lab, “Power off” from the hypervisor without guest-initiated shutdown is closer to yanking the cord—avoid it when testing config persistence unless you are deliberately testing crash recovery.

Wall messages and delayed shutdown
Operators sometimes schedule shutdowns: sudo shutdown -r now # reboot now (legacy-friendly)
sudo shutdown -h now # halt/power off now
sudo shutdown -r +5 "Reboot in 5 minutes"
sudo shutdown -c # cancel a pending shutdown

On systemd systems, shutdown , reboot , and poweroff binaries typically delegate into systemd . You can use either style; many Red Hat docs emphasize systemctl . Know both so a task that says “reboot the system” never stalls you on syntax. sudo reboot

sudo poweroff
sudo halt
Forced options (use carefully) sudo systemctl reboot -f

# or older habit:

sudo reboot -f

Force flags skip parts of the graceful unit teardown. They are for stuck systems, not routine exam reboots. Prefer normal reboot first. If a unit hangs at stop, fix the unit or wait for timeout rather than building a habit of -f .

systemctl --force variants exist for poweroff/halt as well—same caution.

Multi-user context: who is logged in?

Before rebooting a shared lab host: who
w
loginctl list-sessions

EX200 is usually a private exam environment, but the habit of checking sessions and broadcasting ( wall or shutdown’s message) is professional practice. For your exam VM, the critical habit is different: save open configs , ensure systemctl enable and file edits are written to disk ( sync is rarely needed if editors flushed, but do not kill the VM mid-write).

Verifying a successful reboot cycle (exam mindset)

Many tasks are only complete if state persists after reboot . Workflow:

Make the change (unit enable, fstab line, sysctl drop-in, network connection).

Validate live ( systemctl is-enabled , mount , ip a , etc.).

systemctl reboot (or the method the environment allows).

Log back in; re-run the same checks.

Only then mark the task done in your head.

If the exam interface reboots for you, still re-verify. Graders effectively do post-reboot checks.

Useful post-boot health glances: systemctl is-system-running
systemctl --failed
journalctl -p err -b --no-pager | head
df -h
ip -br a

systemctl is-system-running may report running , degraded (some failed units), or other states. degraded means the system booted but something failed—investigate with systemctl --failed before assuming success.

Boot messages and emergency awareness (preview)

A normal boot does not require GRUB edits or rd.break . If the machine drops to emergency/rescue because of a bad fstab or failed local-fs dependency, that is not a normal boot—you fix the root cause (covered in storage chapters and Section 8.3 recovery patterns). For this section, aim for clean configs so reboot returns you to a login prompt on the default target.

Permissions and remote reboot
Reboot/poweroff require root privileges (direct root or sudo ). On SSH: sudo systemctl reboot
# Connection drops; wait; ssh back

Do not panic when SSH dies mid-reboot—that is expected. Wait long enough for firmware + GRUB + boot before reconnecting. In nested virtualization labs, reboot can take longer than bare metal.

If you reboot the wrong host in a multi-machine lab, you waste time—always confirm hostname first: hostnamectl
hostname
Distinguishing halt, poweroff, and reboot

Goal Prefer
Come back up immediately for re-test systemctl reboot
Leave the machine off (end of day, power savings) systemctl poweroff
Stop OS without necessarily cutting PSU (rare exam need) systemctl halt

On many VMs, halt and poweroff look similar in the hypervisor console (VM stops). Conceptually, reboot returns to the boot sequence; poweroff ends in powered-off hardware/VM state.

Relationship to other operate-running-systems skills

Targets (8.2): reboot returns you to the default target unless you interrupt GRUB or isolate temporarily.

Recovery (8.3): when normal login is impossible, you interrupt boot—not the same as normal reboot.

Services: systemctl reboot is not a substitute for systemctl restart httpd ; reboot restarts everything .

Logs: previous boot journals remain queryable with journalctl -b -1 if journal storage is persistent (separate objective).

Common traps

Hard power-off from the hypervisor as a routine “reboot” — risk filesystem checks and incomplete writes.

Assuming reboot is non-systemd — on RHEL it is integrated; still prefer systemctl reboot in modern write-ups.

Changing configs but never rebooting when the skill requires persistence proof.

Rebooting before writing the file (editor buffer not saved).

Confusing systemctl restart service with machine reboot.

Ignoring systemctl --failed after boot and missing a unit that broke on the new config.

Exam workflow: “Make X survive reboot” # Example pattern after enabling a service
sudo systemctl enable --now some.service
systemctl is-enabled some.service
systemctl is-active some.service
sudo systemctl reboot

# after login:

systemctl is-enabled some.service
systemctl is-active some.service

Same pattern applies to mounts, sysctl, tuned profiles, network scripts, and default targets— reboot is the honesty check .

Section checkpoint

You should describe the normal RHEL boot path to systemd’s default target, reboot and shut down cleanly with systemctl reboot / poweroff / halt (and recognize shutdown / reboot aliases), avoid unnecessary forced power loss, verify system health after restart, and treat reboot as a required proof step for persistent configuration on EX200.