RED HAT ENTERPRISE LINUX

Boot Management

Controlling Services and Troubleshooting Boot Problems

College-Level Course Module | RHEL System Administration

Welcome to this critical module on boot management in Red Hat Enterprise Linux. Understanding how Linux boots is essential for both daily administration and emergency troubleshooting. When a system won't start, you need to know what happens at each stage and how to intervene. In this module, you'll learn the complete RHEL boot process from firmware through login prompt. You'll master systemd targets - the modern replacement for runlevels - to control which services start and in what state the system operates. Most importantly, you'll learn to troubleshoot boot failures: using GRUB to modify boot parameters, entering rescue and emergency modes to fix problems, and recovering systems that won't boot normally. These skills are heavily tested on the RHCSA exam and are invaluable when production systems fail at 3 AM.

Learning Objectives

Understand the RHEL boot process

From firmware initialization through systemd to login

Manage systemd targets

Control system states and which services start at boot

Configure GRUB bootloader

Modify boot parameters and select different kernels

Troubleshoot boot problems

Use rescue mode, emergency mode, and reset root password

We have four main learning objectives. First, you'll understand the complete boot process - what happens from power-on to login prompt. This foundation helps you identify where failures occur and what components are responsible. Second, you'll manage systemd targets, which define system states. Targets determine which services run - whether you get a graphical desktop, a text console, or a minimal rescue environment. You'll learn to switch targets and set the default boot target. Third, you'll configure GRUB, the bootloader. GRUB lets you select which kernel to boot, pass parameters to the kernel, and access recovery options. Knowing GRUB is essential for troubleshooting. Fourth, you'll troubleshoot boot problems using rescue and emergency modes. You'll learn to reset forgotten root passwords, fix filesystem errors, and recover systems that won't boot normally.

The Boot Process

Firmware (BIOS/UEFI) - Hardware initialization, POST, find boot device

↓

GRUB2 Bootloader - Display menu, load kernel and initramfs into memory

↓

Kernel Initialization - Decompress, initialize hardware, mount initramfs as temporary root

↓

initramfs - Load drivers, find real root filesystem, pivot_root to real root

↓

systemd (PID 1) - Start services, reach default target, present login

Key insight: Each stage hands off to the next. Problems at any stage prevent reaching later stages. Identify which stage fails to know where to troubleshoot.

Understanding the boot sequence helps you diagnose where failures occur. Stage 1 - Firmware: BIOS or UEFI initializes hardware, runs POST (Power-On Self-Test), and finds the boot device. If this fails, you see no output at all or hardware error messages. This is before Linux is involved. Stage 2 - GRUB2: The bootloader loads from the boot device, displays a menu, and loads the selected kernel and initramfs into memory. GRUB failures show bootloader errors or no menu. Stage 3 - Kernel: The kernel decompresses itself, initializes hardware, and mounts initramfs as a temporary root filesystem. Kernel panics or hardware detection failures happen here. Stage 4 - initramfs: This temporary filesystem contains drivers and tools needed to find and mount the real root filesystem. LVM, RAID, and encrypted disk setup happens here. If the real root can't be found, you'll drop to an initramfs shell. Stage 5 - systemd: Once the real root is mounted, systemd (PID 1) takes over. It starts services according to the default target and eventually presents a login prompt. Service failures happen in this stage.

Firmware and GRUB

BIOS vs UEFI

BIOS: Legacy, MBR partitions, /boot on disk
UEFI: Modern, GPT partitions, EFI System Partition
UEFI supports Secure Boot
RHEL supports both

GRUB2 Bootloader

Config: /boot/grub2/grub.cfg
Defaults: /etc/default/grub
Regenerate: grub2-mkconfig
Supports multiple kernels

# Check if system uses UEFI or BIOS
[root@server ~]# [ -d /sys/firmware/efi ] && echo "UEFI" || echo "BIOS"
UEFI

# View GRUB configuration
[root@server ~]# cat /etc/default/grub
GRUB_TIMEOUT=5
GRUB_DISTRIBUTOR="$(sed 's, release .*$,,g' /etc/system-release)"
GRUB_DEFAULT=saved
GRUB_DISABLE_SUBMENU=true
GRUB_TERMINAL_OUTPUT="console"
GRUB_CMDLINE_LINUX="crashkernel=1G-4G:192M,4G-64G:256M,64G-:512M resume=/dev/mapper/rhel-swap rd.lvm.lv=rhel/root"

# List available kernels
[root@server ~]# grubby --info=ALL | grep ^kernel

The firmware and bootloader are the first software components in the boot process. BIOS is the legacy firmware. It uses MBR partition tables and loads GRUB from the MBR. GRUB's files live in /boot. Maximum disk size is 2TB with MBR. UEFI is modern firmware. It uses GPT partition tables and loads GRUB from an EFI System Partition (ESP), typically mounted at /boot/efi. UEFI supports Secure Boot, which verifies bootloader signatures. RHEL supports Secure Boot. GRUB2 is RHEL's bootloader. It displays a menu of available kernels, loads the selected kernel and initramfs, and passes control to the kernel. GRUB configuration is in /boot/grub2/grub.cfg, but you shouldn't edit it directly. Instead, edit /etc/default/grub and run grub2-mkconfig to regenerate. Key settings: GRUB_TIMEOUT sets how long the menu displays (5 seconds default), GRUB_DEFAULT sets the default entry, GRUB_CMDLINE_LINUX contains kernel parameters passed to every boot.

Kernel and initramfs

The kernel is the core of Linux. The initramfs (initial RAM filesystem) is a temporary root filesystem that contains drivers and tools needed to mount the real root.

# View installed kernels
[root@server ~]# rpm -qa kernel
kernel-5.14.0-362.8.1.el9_3.x86_64
kernel-5.14.0-362.13.1.el9_3.x86_64

# Current running kernel
[root@server ~]# uname -r
5.14.0-362.13.1.el9_3.x86_64

# Kernel and initramfs files in /boot
[root@server ~]# ls /boot/vmlinuz* /boot/initramfs*
/boot/vmlinuz-5.14.0-362.8.1.el9_3.x86_64
/boot/vmlinuz-5.14.0-362.13.1.el9_3.x86_64
/boot/initramfs-5.14.0-362.8.1.el9_3.x86_64.img
/boot/initramfs-5.14.0-362.13.1.el9_3.x86_64.img

# Rebuild initramfs (if drivers or config changed)
[root@server ~]# dracut -f /boot/initramfs-$(uname -r).img $(uname -r)

# View initramfs contents
[root@server ~]# lsinitrd /boot/initramfs-$(uname -r).img | head

Why initramfs? The kernel can't include drivers for every possible storage setup. initramfs provides drivers for your specific hardware (LVM, RAID, encryption) to mount the real root.

The kernel is the Linux operating system core - it manages hardware, memory, processes, and provides the interface between software and hardware. Kernel files are named vmlinuz-VERSION in /boot. RHEL keeps multiple kernel versions installed so you can boot an older kernel if a new one has problems. initramfs (initial RAM filesystem) solves a chicken-and-egg problem: the kernel needs drivers to access the root filesystem, but drivers might be on the root filesystem. initramfs is a compressed archive containing essential drivers and tools. It's loaded into memory by GRUB alongside the kernel. The kernel mounts initramfs as a temporary root, loads necessary drivers (LVM, RAID, encryption, filesystem drivers), finds and mounts the real root filesystem, then switches (pivot_root) to the real root and continues booting. If initramfs is missing or corrupted, the kernel can't find the root filesystem and drops to an initramfs emergency shell. dracut rebuilds initramfs if you need to add drivers or fix corruption.

systemd Targets

Targets are systemd units that define system states. They group services and other units that should be active together. Targets replaced traditional SysV runlevels.

Target	Purpose	Old Runlevel
poweroff.target	System shutdown	0
rescue.target	Single-user rescue mode	1
multi-user.target	Multi-user text mode (servers)	3
graphical.target	Multi-user with GUI (desktops)	5
reboot.target	System reboot	6
emergency.target	Minimal emergency shell	-

# View current target
[root@server ~]# systemctl get-default
graphical.target

# View active target
[root@server ~]# systemctl list-units --type=target --state=active

systemd is the init system and service manager in RHEL. It's the first process started (PID 1) and manages all other services and system state. Targets are systemd's way of defining system states - collections of services that should run together. They replace the old SysV runlevel concept but are more flexible. poweroff.target shuts down the system (runlevel 0). rescue.target is single-user mode with basic services, network disabled - used for maintenance when multi-user mode has problems (runlevel 1). multi-user.target is the standard server state - multiple users, network, services, but no graphical interface (runlevel 3). graphical.target adds the GUI on top of multi-user - standard for desktops (runlevel 5). reboot.target reboots the system (runlevel 6). emergency.target is even more minimal than rescue - just a shell with root filesystem mounted read-only. Use when rescue.target fails. Understanding targets helps you control what services run and troubleshoot boot problems.

Target Details

multi-user.target

Full system, multiple users, network active, all services. No GUI. Standard for servers.

graphical.target

Everything in multi-user plus display manager and desktop. Standard for workstations.

rescue.target

Single-user, root filesystem mounted, basic services only. Root password required. For maintenance.

emergency.target

Minimal shell, root filesystem read-only, no services. For when rescue fails. Requires root password.

# View what services are in a target
[root@server ~]# systemctl list-dependencies graphical.target | head -15

# Targets are hierarchical - graphical includes multi-user
[root@server ~]# systemctl list-dependencies graphical.target | grep target
graphical.target
├─multi-user.target
│ ├─basic.target
│ │ ├─paths.target
│ │ ├─sockets.target
│ │ └─sysinit.target

Target hierarchy: graphical.target depends on multi-user.target, which depends on basic.target, which depends on sysinit.target. Each adds more functionality.

Let's understand the key targets in more detail. multi-user.target is the standard server state. The system has networking, all enabled services are running, multiple users can log in via SSH or console. There's no graphical interface - just text consoles. This is the default for most RHEL servers. graphical.target includes everything in multi-user plus the display manager (login screen) and desktop environment. It depends on multi-user.target, so reaching graphical means multi-user is also reached. This is the default for RHEL workstations. rescue.target is for troubleshooting. It starts minimal services, mounts the root filesystem read-write, and drops to a single-user root shell. Network is down, most services stopped. Use it to fix configuration problems or perform maintenance. emergency.target is even more minimal. Root filesystem is mounted read-only, almost nothing is started. Use it when rescue.target itself won't start, like when there are problems with services that rescue needs. Both rescue and emergency require the root password - important for security.

Changing Default Target

# View current default target
[root@server ~]# systemctl get-default
graphical.target

# Change default to multi-user (text mode)
[root@server ~]# systemctl set-default multi-user.target
Removed /etc/systemd/system/default.target.
Created symlink /etc/systemd/system/default.target → /usr/lib/systemd/system/multi-user.target.

# Verify the change
[root@server ~]# systemctl get-default
multi-user.target

# Change default to graphical (GUI)
[root@server ~]# systemctl set-default graphical.target

# The default target is just a symlink
[root@server ~]# ls -l /etc/systemd/system/default.target
lrwxrwxrwx. 1 root root 40 Jan 20 10:00 /etc/systemd/system/default.target -> /usr/lib/systemd/system/multi-user.target

Takes effect on next boot: Changing the default target doesn't affect the running system. The new target is used on the next boot.

The default target determines what state the system boots into. systemctl get-default shows the current default. It's a symlink from /etc/systemd/system/default.target to the actual target unit file. systemctl set-default changes the default by updating this symlink. Common scenarios: switching a server from graphical to multi-user to save resources, or setting a desktop to boot to text mode for troubleshooting. The change takes effect on the next boot, not immediately. The current running system stays in whatever target it's in. If you need to change targets immediately on a running system, use systemctl isolate. On servers, multi-user.target is appropriate - graphical interface wastes memory and isn't needed for headless systems. On workstations and desktops, graphical.target provides the expected GUI experience.

Switching Targets at Runtime

# Switch to a different target immediately (isolate)
[root@server ~]# systemctl isolate multi-user.target
# GUI stops, drops to text console

# Switch to graphical
[root@server ~]# systemctl isolate graphical.target
# Display manager starts, GUI appears

# Enter rescue mode (single-user)
[root@server ~]# systemctl isolate rescue.target
# Services stop, single-user shell

# Reboot the system
[root@server ~]# systemctl isolate reboot.target
# Or simply:
[root@server ~]# systemctl reboot

# Shutdown the system
[root@server ~]# systemctl poweroff

isolate is disruptive! Switching targets stops services not needed by the new target. Users may be disconnected. Use carefully on production systems.

systemctl isolate switches the running system to a different target immediately. Unlike set-default (which only affects next boot), isolate changes the system state right now. isolate multi-user.target stops the graphical interface and drops to text console. Active GUI sessions are terminated. Users at the graphical console are logged out. isolate graphical.target starts the display manager and GUI. isolate rescue.target is how you enter single-user mode from a running system. Network stops, services stop, you get a maintenance shell. isolate reboot.target and isolate poweroff.target are equivalent to systemctl reboot and systemctl poweroff. The term "isolate" comes from the concept of isolating a target - making it the only active target by stopping units not required by it. Not all targets can be isolated. Only targets with AllowIsolate=yes in their unit file support this. The standard targets (multi-user, graphical, rescue, emergency, reboot, poweroff) all support isolation.

Modifying GRUB at Boot

GNU GRUB version 2.06

Red Hat Enterprise Linux (5.14.0-362.13.1.el9_3.x86_64) 9.3

Red Hat Enterprise Linux (5.14.0-362.8.1.el9_3.x86_64) 9.3

Red Hat Enterprise Linux (0-rescue-abc123) 9.3

Use ↑ and ↓ to change selection.
Press 'e' to edit commands, 'c' for command-line.

At GRUB menu:
• ↑/↓ - Select kernel
• Enter - Boot selected entry
• e - Edit boot parameters (temporary)
• c - GRUB command line

GRUB displays a menu when the system boots, allowing you to select which kernel to boot and modify boot parameters. By default, GRUB waits 5 seconds then boots the default entry. Press any key to stop the timeout and interact with the menu. Arrow keys select different entries. RHEL keeps multiple kernel versions, so you can boot an older kernel if the newest has problems. The rescue entry boots a special recovery kernel. Press 'e' to edit the selected entry's boot parameters. This is crucial for troubleshooting - you can add parameters to boot into different targets, enable debugging, or fix problems. Changes made with 'e' are temporary - they only affect this one boot. Press 'c' for a GRUB command prompt. This is useful for advanced troubleshooting when menu entries are broken. Knowing how to navigate GRUB is essential for the RHCSA exam and real-world troubleshooting. You'll use it to access rescue mode, reset passwords, and fix boot problems.

Editing Boot Parameters

# After pressing 'e' at GRUB menu, you see the boot entry:
setparams 'Red Hat Enterprise Linux (5.14.0-362.13.1.el9_3.x86_64) 9.3'
        
        load_video
        set gfxpayload=keep
        insmod gzio
        insmod part_gpt
        insmod xfs
        ...
        linux ($root)/vmlinuz-5.14.0-362.13.1.el9_3.x86_64 root=/dev/mapper/rhel-root 
              ro crashkernel=1G-4G:192M,4G-64G:256M,64G-:512M resume=/dev/mapper/rhel-swap 
              rd.lvm.lv=rhel/root rd.lvm.lv=rhel/swap
        initrd ($root)/initramfs-5.14.0-362.13.1.el9_3.x86_64.img

# Find the line starting with 'linux' and add parameters at the end:

# Boot to rescue mode:
linux ... rd.lvm.lv=rhel/swap systemd.unit=rescue.target

# Boot to emergency mode:
linux ... rd.lvm.lv=rhel/swap systemd.unit=emergency.target

# After editing, press Ctrl+x to boot with changes

Ctrl+x boots with your changes. Ctrl+c discards changes. Esc returns to menu.

Editing GRUB boot parameters is a key troubleshooting skill. Press 'e' at the menu to edit. You'll see a text editor with the boot entry configuration. Find the line starting with 'linux' - this is the kernel command line. It specifies the kernel to load and parameters to pass. Navigate with arrow keys. Go to the end of the linux line and add parameters. To boot into rescue mode, add systemd.unit=rescue.target at the end of the linux line. This tells systemd to boot to rescue target instead of the default. For emergency mode, use systemd.unit=emergency.target. Other useful parameters include 'rd.break' (break into initramfs before mounting root), 'single' or '1' (legacy way to request rescue mode), and 'init=/bin/bash' (bypass systemd entirely). Press Ctrl+x to boot with your modifications. The changes are temporary - they only affect this boot. If you need permanent changes, edit /etc/default/grub and run grub2-mkconfig.

Rescue Mode

Rescue mode boots to a single-user shell with root filesystem mounted read-write and basic services running. Use for maintenance and repairs.

# Method 1: From GRUB, edit boot entry, add to linux line:
systemd.unit=rescue.target

# Method 2: From running system
[root@server ~]# systemctl isolate rescue.target

# What you see in rescue mode:
Welcome to rescue mode! Type "systemctl default" or "systemctl reboot"...
Give root password for maintenance
(or press Control-D to continue):

# After entering root password:
[root@server ~]# # Full root shell, root filesystem mounted rw

# Do your maintenance work, then:
[root@server ~]# systemctl default     # Continue to normal boot
# Or:
[root@server ~]# systemctl reboot      # Reboot the system

Requires root password! Rescue mode prompts for the root password. If you've forgotten it, use emergency mode with rd.break instead.

Rescue mode is your first stop for system maintenance and troubleshooting. It boots to a single-user environment with the root filesystem mounted read-write. To enter rescue mode from GRUB, edit the boot entry and add systemd.unit=rescue.target to the linux line. Boot with Ctrl+x. You can also enter rescue mode from a running system with systemctl isolate rescue.target. Rescue mode prompts for the root password - this is a security measure. Only authorized administrators should be able to enter maintenance mode. Once authenticated, you have a full root shell. Network is down, most services are stopped. You can edit configuration files, fix fstab errors, repair filesystems, and perform other maintenance. When done, use systemctl default to continue booting to the normal target, or systemctl reboot to restart. If the root password is unknown, rescue mode won't help - you'll need emergency mode with rd.break instead.

Emergency Mode

Emergency mode is more minimal than rescue. Root filesystem is mounted read-only, almost no services run. Use when rescue mode itself fails.

# From GRUB, add to linux line:
systemd.unit=emergency.target

# What you see:
Welcome to emergency mode! After logging in, type "journalctl -xb"...
Give root password for maintenance
(or press Control-D to continue):

# After entering root password:
[root@server ~]# mount
/dev/mapper/rhel-root on / type xfs (ro,relatime,...)  # Read-only!

# Remount root filesystem read-write to make changes
[root@server ~]# mount -o remount,rw /

# Now you can edit files
[root@server ~]# vi /etc/fstab

# When done:
[root@server ~]# systemctl reboot

Emergency vs Rescue: Use rescue first. If rescue fails (bad service configuration, etc.), emergency is more minimal and might work.

Emergency mode is the most minimal recovery environment. Use it when rescue mode itself won't start - for example, if a service required by rescue.target is misconfigured and failing. In emergency mode, root filesystem is mounted read-only. This prevents accidental damage but means you can't change anything by default. To make repairs, first remount root read-write with mount -o remount,rw /. Emergency mode also requires the root password. If you don't know it, you'll need rd.break instead. journalctl -xb is suggested at the emergency prompt - it shows journal messages from this boot, which can help diagnose why the system won't boot normally. Use emergency mode to fix problems that prevent rescue mode from working, like a badly corrupted service unit file or critical filesystem issues. When you've made your repairs, reboot with systemctl reboot.

Breaking into initramfs

rd.break interrupts boot in initramfs before the real root is mounted. This bypasses systemd and the root password, allowing password reset.

# From GRUB, add to end of linux line:
rd.break

# Boot with Ctrl+x - you get an initramfs shell:
Entering emergency mode. Exit the shell to continue.
Type "journalctl" to view system logs.
You might want to save "/run/initramfs/rdsosreport.txt"

switch_root:/#

# The real root filesystem is mounted at /sysroot, read-only
switch_root:/# mount | grep sysroot
/dev/mapper/rhel-root on /sysroot type xfs (ro,relatime,...)

# Remount read-write
switch_root:/# mount -o remount,rw /sysroot

# Change root into the real root filesystem
switch_root:/# chroot /sysroot

Security implication: rd.break bypasses authentication! Physical access = root access. Protect servers physically and with GRUB passwords.

rd.break is the most powerful recovery option. It stops boot in the initramfs before systemd even starts, before the root filesystem is mounted normally. This means no password is required - you go straight to a shell. This is how you reset a forgotten root password. Add rd.break to the kernel command line in GRUB. Boot with Ctrl+x. You land in an initramfs shell with the prompt switch_root:/#. The real root filesystem is mounted at /sysroot but read-only. First, remount it read-write with mount -o remount,rw /sysroot. Then use chroot /sysroot to change your root directory to the real root filesystem. Now you can run passwd to change the root password. Important security note: anyone with physical access to the console can use rd.break to gain root access. This is why servers should be in locked rooms and GRUB can be password-protected. rd.break is for legitimate recovery, but it's also a security consideration.

Resetting Root Password

# 1. At GRUB, edit boot entry (press 'e')
# 2. Add rd.break to end of linux line
# 3. Boot with Ctrl+x

# 4. Remount /sysroot read-write
switch_root:/# mount -o remount,rw /sysroot

# 5. Change root into real filesystem
switch_root:/# chroot /sysroot

# 6. Reset the password
sh-5.1# passwd root
Changing password for user root.
New password: 
Retype new password:
passwd: all authentication tokens updated successfully.

# 7. CRITICAL: Fix SELinux context (or system won't boot!)
sh-5.1# touch /.autorelabel

# 8. Exit and reboot
sh-5.1# exit
switch_root:/# exit
# System reboots, SELinux relabels (may take several minutes)

Don't forget /.autorelabel! The password file gets wrong SELinux context. Without relabeling, you still won't be able to log in!

This is the complete procedure for resetting a forgotten root password on RHEL. It's a critical skill for the RHCSA exam. Step by step: Boot and interrupt GRUB by pressing a key. Select your kernel entry and press 'e' to edit. Find the linux line and add rd.break at the end. Press Ctrl+x to boot. At the switch_root prompt, remount /sysroot read-write. Use chroot /sysroot to enter the real filesystem. Run passwd root to set a new password. Critical step: touch /.autorelabel. When you changed the password file outside the normal boot process, its SELinux security context became incorrect. The /.autorelabel file tells SELinux to relabel the entire filesystem on next boot. Without this, the shadow file has wrong context and login fails even with correct password. Exit the chroot, exit the initramfs shell - system reboots. The relabel process runs automatically and can take several minutes on large filesystems. Be patient. After relabeling completes, the system boots normally and you can log in with the new password.

Troubleshooting Boot Failures

Symptom	Likely Cause	Solution
No video output	Hardware, firmware	Check cables, BIOS settings
No GRUB menu	Bootloader problem	Boot rescue media, reinstall GRUB
Kernel panic	Kernel/driver issue	Boot older kernel from GRUB
Drops to initramfs shell	Can't find root FS	Check root=, LVM, encryption
Stuck at "Started..." message	Service hanging	Boot with emergency.target
Can't login, password correct	SELinux, PAM	Boot rescue, check /var/log, relabel
Filesystem errors	Corrupted FS	Boot rescue, run fsck
Can't mount filesystem	Bad /etc/fstab	Boot emergency, fix fstab

# Check boot logs after successful boot
[root@server ~]# journalctl -b                  # This boot
[root@server ~]# journalctl -b -1               # Previous boot
[root@server ~]# journalctl -b -p err           # Errors only
[root@server ~]# systemctl --failed             # Failed services

Different symptoms indicate different problems. Use this table to narrow down where to look. No video output means the problem is before Linux - hardware or firmware. Check physical connections and BIOS settings. No GRUB menu means the bootloader is broken. You need to boot from rescue media and reinstall GRUB. Kernel panic means the kernel can't continue - usually a driver problem or missing initramfs. Try an older kernel. Initramfs shell means the kernel started but couldn't find the root filesystem. Check if root= parameter is correct, if LVM is being activated, or if disk encryption is configured. Stuck at a "Started..." message means a service is hanging. Boot to emergency.target to bypass services, then investigate. Login failures with correct password often mean SELinux context is wrong (common after password reset without relabel) or PAM configuration problems. Filesystem errors need fsck - boot to rescue mode, unmount the filesystem, run fsck. Bad fstab is common - a typo can prevent boot. Use emergency mode to fix since root is mounted read-only.

Recovering from fstab Errors

A bad /etc/fstab entry can prevent normal boot. The system may drop to emergency mode or fail to mount filesystems.

# System won't boot due to fstab error - you see:
Welcome to emergency mode! ...
Cannot open access to console, the root account is locked.
See sulogin(8) man page for more details.
Press Enter to continue.

# Solution: Boot with rd.break, fix fstab

# 1. Edit GRUB entry, add rd.break, boot with Ctrl+x
# 2. Remount /sysroot read-write
switch_root:/# mount -o remount,rw /sysroot

# 3. Edit fstab
switch_root:/# vi /sysroot/etc/fstab
# Fix or comment out the bad entry

# 4. Exit to continue boot
switch_root:/# exit

# Alternative: Add this to kernel line to ignore fstab errors:
systemd.unit=emergency.target
# Then remount root rw and fix fstab

fstab errors are a common cause of boot failures. A typo in UUID, wrong device name, or trying to mount a non-existent filesystem can all prevent boot. When this happens, the system may drop to emergency mode. If the root account is locked (no password set, which is default on RHEL), you'll see "Cannot open access to console, the root account is locked" and can't get a shell. The solution is rd.break. This gets you to a shell before fstab is processed. Remount /sysroot read-write and edit /sysroot/etc/fstab to fix or comment out the problematic line. Then exit to continue booting. An alternative is adding systemd.unit=emergency.target to the kernel line. This boots to emergency mode with root filesystem mounted (read-only). Remount read-write, fix fstab, reboot. Prevention: always test fstab changes with mount -a before rebooting. Catch errors while you still have a working system.

Persistent GRUB Changes

# Edit GRUB defaults
[root@server ~]# vi /etc/default/grub

# Common settings:
GRUB_TIMEOUT=5                    # Seconds before auto-boot
GRUB_DEFAULT=saved                # Remember last selection
GRUB_DISABLE_SUBMENU=true         # Flat menu, no submenus
GRUB_CMDLINE_LINUX="..."          # Kernel parameters for all boots

# After editing, regenerate grub.cfg:
# For BIOS systems:
[root@server ~]# grub2-mkconfig -o /boot/grub2/grub.cfg

# For UEFI systems:
[root@server ~]# grub2-mkconfig -o /boot/efi/EFI/redhat/grub.cfg

# Set default kernel to boot
[root@server ~]# grubby --default-kernel
/boot/vmlinuz-5.14.0-362.13.1.el9_3.x86_64

[root@server ~]# grubby --set-default /boot/vmlinuz-5.14.0-362.8.1.el9_3.x86_64

Never edit grub.cfg directly! It's regenerated by grub2-mkconfig. Edit /etc/default/grub instead.

For permanent GRUB changes, edit /etc/default/grub and regenerate the configuration. GRUB_TIMEOUT controls how long the menu shows before auto-booting. Set to 0 for instant boot (but you lose the chance to interrupt). GRUB_DEFAULT controls which entry boots by default. "saved" remembers your last choice. You can also use a number (0 for first entry) or the exact menu title. GRUB_CMDLINE_LINUX contains kernel parameters added to every boot. Add parameters here for things like console settings or debugging options. After editing, regenerate grub.cfg with grub2-mkconfig. The output file path differs between BIOS and UEFI systems - check which you have first. grubby is a tool for managing boot entries. It can show and change the default kernel without manually editing configs. This is useful when a kernel update causes problems and you need to boot the previous kernel by default.

Boot Diagnostics

# View boot messages from current boot
[root@server ~]# journalctl -b

# View boot messages from previous boot
[root@server ~]# journalctl -b -1

# Show only errors and worse
[root@server ~]# journalctl -b -p err

# View kernel messages (dmesg equivalent)
[root@server ~]# journalctl -k

# Follow boot in real-time (on another console)
[root@server ~]# journalctl -f

# Check for failed services
[root@server ~]# systemctl --failed
  UNIT                    LOAD   ACTIVE SUB    DESCRIPTION
● httpd.service           loaded failed failed Apache HTTP Server

# Analyze boot time
[root@server ~]# systemd-analyze
Startup finished in 1.512s (kernel) + 2.313s (initrd) + 8.765s (userspace) = 12.590s

[root@server ~]# systemd-analyze blame | head -5

After boot problems, or to understand what's happening during boot, use these diagnostic tools. journalctl -b shows all messages from the current boot. This is your primary diagnostic tool for boot problems. Add -p err to filter to errors only and reduce noise. journalctl -b -1 shows the previous boot. This is invaluable when a system crashed - you can see what happened last time even after the system recovers. journalctl -k shows kernel messages specifically - equivalent to dmesg but integrated with the journal. systemctl --failed lists services that failed to start. This quickly identifies problematic services after boot. systemd-analyze shows how long boot took, broken into kernel, initrd, and userspace phases. systemd-analyze blame shows which services took the longest - useful for identifying slow services that delay boot. These tools help you understand boot behavior both for troubleshooting and for optimization.

Best Practices

✓ Do

Keep multiple kernel versions installed
Test fstab changes with mount -a
Know how to access GRUB and edit entries
Practice password reset procedure
Document custom boot parameters
Use journalctl to review boot logs
Set appropriate default target
Create /.autorelabel after SELinux changes

✗ Don't

Edit grub.cfg directly
Remove all old kernels
Forget SELinux relabeling after password reset
Reboot without testing fstab changes
Ignore failed services after boot
Leave GRUB timeout at 0 on servers
Skip documentation of boot changes
Panic when boot fails - use systematic troubleshooting

RHCSA tip: Practice boot recovery until it's automatic. The exam will test password reset, rescue mode, and fstab recovery.

These best practices come from real-world experience and exam preparation. Keep multiple kernels - RHEL does this by default. If a new kernel has problems, you can boot the previous one. Never remove all old kernels. Always test fstab with mount -a before rebooting. This catches errors while you still have access to fix them. Know GRUB navigation by heart. In an emergency, you need to edit boot parameters without looking up instructions. Practice the password reset procedure multiple times. It's a common RHCSA task and you need to do it quickly and correctly under exam pressure. Don't forget /.autorelabel - this trips up many people. The password change works but login fails without relabeling. Don't edit grub.cfg directly - it's overwritten by grub2-mkconfig. Always edit /etc/default/grub and regenerate. Set GRUB timeout to at least 3-5 seconds on servers. Zero timeout means you can't interrupt boot if something goes wrong. When boot fails, don't panic. Systematically identify the stage, use the appropriate recovery method, and fix the problem.

Key Takeaways

Boot Process: Firmware → GRUB → Kernel → initramfs → systemd. Know each stage for troubleshooting.

Targets: multi-user.target (servers), graphical.target (desktops). Use systemctl set-default and isolate.

GRUB: Press 'e' to edit boot parameters. Add systemd.unit=rescue.target or rd.break for recovery.

Recovery: rescue.target for maintenance, emergency.target for minimal access, rd.break for password reset.

LAB EXERCISES

Change the default target to multi-user.target and reboot
Use systemctl isolate to switch between targets
Edit GRUB to boot into rescue.target
Practice the complete root password reset procedure
Intentionally break /etc/fstab and recover using rd.break
Analyze boot performance with systemd-analyze

Next: Managing Network Security with Firewall

Let's summarize the key boot management skills. The boot process has five stages: firmware, GRUB, kernel, initramfs, and systemd. Each hands off to the next. Problems at any stage prevent reaching later stages. Identifying the failing stage tells you where to troubleshoot. Targets define system states. multi-user.target is standard for servers, graphical.target for desktops. set-default changes the boot target, isolate changes it immediately. Know rescue and emergency targets for troubleshooting. GRUB is your gateway to recovery. Press 'e' to edit, add parameters like systemd.unit=rescue.target or rd.break. Changes from the GRUB editor are temporary - perfect for one-time recovery. For recovery: use rescue.target for general maintenance (requires root password), emergency.target when rescue fails, and rd.break to bypass authentication entirely for password reset. Remember /.autorelabel after password reset! Your lab exercises give you hands-on practice with all recovery scenarios. Practice until these procedures are automatic - you'll need them both for the exam and in production emergencies.