8.3 Interrupt the Boot Process to Gain Access

8.3 Interrupt the Boot Process to Gain Access

Quick Answer: Interrupt GRUB, edit the kernel line, and use a recovery method such as rd.break (initramfs shell) or systemd.unit=emergency.target / rescue.target. For root password reset on RHEL: at the rd.break shell, remount /sysroot read-write, chroot /sysroot, run passwd, touch /.autorelabel (SELinux), exit, and reboot. Verify you can log in and that SELinux returns to enforcing after relabel.

Why “interrupt boot” is an RHCSA skill

Official wording: interrupt the boot process in order to gain access to a system. Real-world and exam situations include:

• Root password lost or never known on a lab clone
• Only console access; SSH keys broken
• System fails to reach multi-user because of a bad unit, but you can still edit from early boot
• Need a maintenance shell before services start

This is authorized recovery on systems you administer (including exam VMs). It is not a covert bypass of someone else’s machine security policy—treat it as break-glass administration.

Step 0: Reach the GRUB menu

1. Reboot the system (systemctl reboot if you still can; otherwise use the hypervisor reset).
2. At GRUB, interrupt the automatic boot. Common patterns:
   • Press Esc repeatedly during firmware/GRUB handoff
   • On some BIOS GRUB installs, hold Shift
   • UEFI systems vary—use whatever the lab shows (menu appears with kernel entries)
3. Highlight the default kernel entry.
4. Press e to edit.

You should see lines for linux/linuxefi and initrd/initrdefi. Only edit the kernel command line for these procedures unless a task says otherwise.

Boot the edited entry with Ctrl+x or F10 (platform-dependent).

Timeout tip: If the menu flies by, change GRUB timeout later with bootloader tools (separate objective). For recovery, be ready to press the interrupt key early.

Method A — rd.break (classic RHEL root password reset)

rd.break stops boot inside the initramfs before pivoting fully into the real root as a normal multi-user system. You get a shell with the real root filesystem available under /sysroot.

1) Edit GRUB kernel line

On the linux/linuxefi line, append:

rd.break

Optional hardening-related remove/alter: some guides also remove rhgb and quiet so messages are visible—not required for rd.break itself but helpful for seeing errors.

Do not invent random arguments. Keep existing root=, BOOT_IMAGE=, and resume parameters intact.

2) Boot and remount sysroot read-write

At the switch_root:/# style prompt:

mount -o remount,rw /sysroot

Without remount, passwd and file edits fail on a read-only tree.

3) chroot into the real system

chroot /sysroot

Now / is the real root filesystem. Standard paths (/etc/shadow, /bin/passwd) apply.

4) Reset root password

passwd
# enter new password twice

Or set a known password for a specific user if the task requires that account instead of root:

passwd student

5) SELinux relabel (critical on enforcing systems)

Changing /etc/shadow (and related auth files) outside normal SELinux-aware flows can leave incorrect labels or require a full filesystem relabel so the next boot is healthy. Standard exam-safe pattern inside the chroot:

touch /.autorelabel

On the next boot, SELinux performs a full relabel (can take noticeable time). The system may reboot again as part of the relabel workflow. Plan time for this on the exam.

Alternative approaches seen in docs/labs (know the idea):

# sometimes used in maintenance contexts
fixfiles -F onboot
# or restorecon on specific files when you know exactly what changed
restorecon /etc/shadow /etc/security/opasswd 2>/dev/null

For full root password reset via rd.break, touch /.autorelabel is the widely taught durable pattern. Skipping relabel is a common reason login still fails or SELinux denials appear after “successful” passwd.

6) Exit cleanly and continue boot

exit          # leave chroot
exit          # leave rd.break shell / continue init
# or reboot if instructed by the environment

Allow the system to boot; wait through autorelabel if scheduled; then log in with the new password.

7) Verify

# after login
whoami
getenforce                # expect Enforcing after relabel completes (unless task set permissive)
sudo -v                   # if exercising sudo user

If getenforce is Permissive because you temporarily changed mode during repair, restore Enforcing when the task expects production defaults:

sudo setenforce 1
# and ensure /etc/selinux/config is SELINUX=enforcing for persistence when required

Method B — Boot directly to emergency or rescue (systemd.unit=)

When the system can load the real root and systemd but you need a maintenance shell:

Append to the kernel line:

systemd.unit=emergency.target

or

systemd.unit=rescue.target

Then Ctrl+x to boot.

• Authenticate with the existing root password if sulogin demands it.
• If you do not know root’s password, emergency/rescue sulogin may block you—use rd.break (or equivalent initramfs break) instead, because that path lets you change the password before normal sulogin policies apply the same way.

In emergency, remount if needed:

mount -o remount,rw /
passwd
touch /.autorelabel
systemctl reboot

(Exact mount state varies; always check mount | grep ' / '.)

Method C — rw init=/bin/bash style (awareness)

Older or generic Linux materials sometimes replace init:

rw init=/bin/bash

on the kernel line. On modern RHEL with SELinux and complex initramfs, rd.break + chroot is the method Red Hat training historically emphasizes for password recovery. Prefer rd.break on RHEL 10 exam prep unless documentation for your exact release shows another supported flow.

SELinux and recovery — do not “fix” by leaving the machine insecure

Temporary kernel argument enforcing=0 can help some recovery scenarios (boot permissive for one boot). If you use it, understand it is one boot unless config files also change. Still run relabel after auth file changes when required.

When the problem is not the password

Interrupting boot also helps when:

Example fstab fix mindset:

mount -o remount,rw /
vim /etc/fstab
# comment out bad line or correct UUID
systemctl daemon-reload
reboot

Console security note (exam realism)

Anyone with console + GRUB edit ability can often reset root on an unencrypted disk without a GRUB password. Production systems mitigate with:

• Firmware passwords
• GRUB password requiring authentication to edit entries
• Full-disk encryption (LUKS)—recovery then needs the passphrase

EX200 environments typically allow the recovery procedures above on unencrypted training disks. If LUKS is in play, you must unlock volumes before chroot—follow prompts in initramfs.

End-to-end exam checklist (root password reset)

1. Reboot → interrupt GRUB → e.
2. Append rd.break on kernel line → Ctrl+x.
3. mount -o remount,rw /sysroot
4. chroot /sysroot
5. passwd (set root password meeting task policy)
6. touch /.autorelabel
7. exit ; exit (continue/reboot as needed)
8. Wait for relabel/boot; log in; getenforce
9. Confirm any task-specific users/services still correct

Common traps

1. Forgetting remount rw — passwd fails or changes do not persist as expected.
2. Editing files in initramfs / instead of /sysroot — wrong tree; changes vanish.
3. Skipping chroot — tools may not see the real /etc/shadow.
4. Skipping /.autorelabel — SELinux pain after reset.
5. Using rescue.target when root password is unknown — sulogin blocks you.
6. Leaving the system in permissive/disabled SELinux when the exam expects enforcing.
7. Not waiting long enough for autorelabel and thinking the box is hung.
8. Typos on the GRUB line that break root= UUID parameters.

Relationship to other chapters

• 8.1 assumes you can still shut down/reboot normally; this section is when normal access is gone.
• 8.2 supplies systemd.unit= target selection used as Method B.
• SELinux chapters deepen enforcing/permissive/restorecon; here you learn the must-not-skip relabel after offline credential changes.
• Bootloader modification objectives cover permanent GRUB changes; recovery edits are ephemeral unless you also change grub config files.

Section checkpoint

You should interrupt GRUB, apply rd.break or target-based recovery, remount and chroot to the real root, reset passwords, schedule SELinux autorelabel, complete reboot, and verify login plus SELinux state. That is the EX200 meaning of interrupting boot to gain access—and of leaving the system correctly secured afterward.