RED HAT ENTERPRISE LINUX

Password Recovery

Gaining Administrative Access When Locked Out

College-Level Course Module | RHEL System Administration

Welcome to this essential module on password recovery in Red Hat Enterprise Linux. Every administrator will eventually face a locked system - a forgotten root password, a colleague who left without sharing credentials, or an inherited server with unknown access. Knowing how to regain administrative access is a critical skill. In this module, you'll learn the complete procedure for resetting the root password when it's unknown or when the account is locked. You'll understand why this works - the rd.break technique that interrupts boot before authentication is required. You'll also learn about the critical SELinux relabeling step that many people forget. Finally, we'll discuss the security implications - this same technique that saves administrators can be used by attackers, so we'll cover how to protect systems. This is a heavily tested RHCSA exam objective, and you need to perform these steps quickly and correctly under pressure.

Learning Objectives

Interrupt the boot process at GRUB

Edit boot parameters to add rd.break for initramfs access

Access the system without authentication

Use the initramfs shell to access the root filesystem

Reset or unlock the root password

Change password and handle locked accounts

Fix SELinux context and complete recovery

Ensure proper relabeling so login works after reboot

We have four main learning objectives. First, you'll learn to interrupt the boot process at GRUB. The bootloader is your gateway to recovery - by editing boot parameters, you can change how the system starts. Second, you'll access the system without authentication using rd.break. This parameter stops boot in the initramfs before systemd starts, before any password is required. You get a shell with access to the real root filesystem. Third, you'll reset or unlock the root password. This might mean setting a new password with passwd, or unlocking an account that was administratively locked. Fourth, you'll properly handle SELinux context. This is the step many people forget - when you change the password file outside normal operation, SELinux labels become incorrect. Without relabeling, you still won't be able to log in even with the correct password.

When You Need Recovery

Password recovery is needed when you cannot authenticate as root through normal means - the password is unknown, forgotten, or the account is locked.

Forgotten Password

Administrator forgot the root password. No one else knows it. Most common scenario.

Inherited System

Took over a system from someone who left. Credentials weren't documented or handed over.

Locked Account

Root account locked due to failed attempts or administrative action. Password correct but can't login.

Emergency Access

No sudo users available. Need root for emergency repairs. Only option is console recovery.

Requirement: Physical or console access to the system. This procedure cannot be done remotely - you must be able to interact with GRUB.

There are several scenarios where password recovery is necessary. Forgotten password is the most common. Someone set up the system, used root initially, then relied on sudo and forgot the root password. Or documentation was lost. Inherited systems are common in organizations. An administrator leaves, credentials weren't in the password vault, and now you have a server you can't fully manage. Locked accounts happen when security policies lock root after failed login attempts, or when an administrator intentionally locks root and then can't unlock it. Emergency access is needed when the only sudo user's account has problems, or when you need to fix something that requires root and normal paths aren't available. Critical requirement: you need physical or console access. This procedure requires interacting with GRUB at boot time. Remote-only access won't work unless you have out-of-band console access (like IPMI, iLO, or virtual machine console).

Recovery Method Overview

Interrupt Boot at GRUB Press a key to stop automatic boot, select kernel entry

Edit Boot Parameters Press 'e' to edit, add rd.break to the linux line

Boot to initramfs Shell Press Ctrl+x to boot, land at switch_root:/# prompt

Mount Root Filesystem Read-Write Remount /sysroot with write permissions

Change Root and Reset Password chroot /sysroot, run passwd root

Fix SELinux Context Create /.autorelabel to trigger filesystem relabeling

Exit and Reboot Exit shells, system reboots, relabels, then normal boot

Let me walk you through the complete recovery method before we dive into details. Step 1: Interrupt boot at GRUB. The system shows a boot menu briefly - you must press a key to stop automatic boot. Step 2: Edit boot parameters. With a kernel entry selected, press 'e' to edit. Find the linux line and add rd.break at the end. Step 3: Boot to initramfs. Press Ctrl+x to boot with your modified parameters. rd.break stops boot in the initial RAM filesystem before mounting the real root. Step 4: Mount root read-write. The real root filesystem is at /sysroot but mounted read-only. Remount it with write permissions. Step 5: Change root and reset password. Use chroot to make /sysroot your root, then run passwd to change the password. Step 6: Fix SELinux context. This critical step creates /.autorelabel so SELinux relabels the filesystem on next boot. Skip this and login will fail. Step 7: Exit and reboot. Exit the chroot and initramfs shell. System reboots, performs SELinux relabeling (may take several minutes), then boots normally with your new password.

Step 1: Interrupt GRUB

When the system starts, GRUB displays a boot menu briefly (default 5 seconds). Press any key to stop the countdown and interact with the menu.

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-abc123def456) 9.3

Use ↑ and ↓ keys to change selection.
Press 'e' to edit the selected entry.
Press 'c' for a command-line.

Be quick! Default timeout is 5 seconds. Watch the screen carefully during POST and press a key as soon as you see the GRUB menu appear.

The first step is intercepting the boot process at GRUB. When you power on or reboot, the system runs through POST (Power-On Self-Test), then GRUB loads. GRUB shows a menu of available boot entries - typically multiple kernel versions plus a rescue entry. By default, GRUB waits only 5 seconds before automatically booting the default entry. You must press a key during this window to stop the countdown. Once the countdown stops, you can use arrow keys to select different entries. The most recent kernel is usually selected by default - that's fine for our purpose. The key commands shown at the bottom are important: 'e' to edit the selected entry's boot parameters, 'c' for a GRUB command line. We'll use 'e' to add our recovery parameter. If you miss the GRUB window and the system boots normally, just reboot and try again. On virtual machines, you may need to act very quickly - the boot process is faster than physical hardware.

Step 2: Edit Boot Parameters

# After pressing 'e', you see the boot entry configuration:
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
        set root='hd0,gpt2'
        if [ x$feature_platform_search_hint = xy ]; then
          search --no-floppy --fs-uuid --set=root --hint='hd0,gpt2' abc123...
        else
          search --no-floppy --fs-uuid --set=root abc123...
        fi
        linux   ($root)/vmlinuz-5.14.0-362.13.1.el9_3.x86_64 root=/dev/mapper/rhel-root 
                ro crashkernel=1G-4G:192M resume=/dev/mapper/rhel-swap rd.lvm.lv=rhel/root 
                rd.lvm.lv=rhel/swap rhgb quiet
        initrd  ($root)/initramfs-5.14.0-362.13.1.el9_3.x86_64.img

# Find the line starting with 'linux' (highlighted above)
# Navigate to the END of that line
# Add: rd.break

Navigation: Use arrow keys to move. The linux line may wrap across multiple screen lines. Go to the very end after all existing parameters.

After pressing 'e', you enter GRUB's built-in editor showing the boot entry configuration. This looks complex but you only need to modify one thing. Find the line starting with 'linux' - this is the kernel command line that tells GRUB which kernel to load and what parameters to pass to it. The linux line contains the kernel path and parameters like root= (where the root filesystem is), ro (mount read-only initially), and various other options. Navigate to the END of the linux line. This line often wraps across multiple screen lines - keep pressing the right arrow or End key until you're truly at the end, after all existing parameters. Add a space, then type rd.break. That's it - just those eight characters. rd.break tells the initramfs to stop and give you a shell before it tries to mount the real root filesystem and start systemd. The 'rd' stands for dracut (the initramfs generator), and 'break' means break/stop execution.

Adding rd.break

rd.break interrupts the boot process in the initramfs, before the real root filesystem is fully mounted and before systemd starts. No authentication is required.

# Before (end of linux line):
... rd.lvm.lv=rhel/root rd.lvm.lv=rhel/swap rhgb quiet

# After adding rd.break:
... rd.lvm.lv=rhel/root rd.lvm.lv=rhel/swap rhgb quiet rd.break

# Optionally, remove 'rhgb quiet' to see boot messages:
... rd.lvm.lv=rhel/root rd.lvm.lv=rhel/swap rd.break

✓ Checkpoint

The linux line should now end with rd.break. Double-check before proceeding. Press Ctrl+x to boot with these parameters.

Why rd.break works: The initramfs runs before systemd, before login, before authentication is configured. It's a minimal environment designed to prepare the real root - and it trusts whoever has console access.

Let's be clear about exactly what to add and why it works. At the end of the linux line, add a space and rd.break. Nothing else needs to change. Optionally, you can remove 'rhgb quiet' to see boot messages instead of a graphical boot screen. This isn't necessary but can be helpful if something goes wrong - you'll see text messages instead of a blank screen. Why does rd.break work? The boot process goes: firmware, GRUB, kernel, initramfs, then systemd. The initramfs is a temporary mini-system whose job is to prepare the real root filesystem (activate LVM, decrypt disks, load drivers) and hand off to the real system. rd.break stops this handoff. You get a shell in the initramfs environment. The real root filesystem is available but not fully active. No authentication is configured because initramfs doesn't have your /etc/shadow - it has its own minimal environment. This is why physical security matters - anyone with console access can use this technique.

Step 3: Boot to initramfs

# Press Ctrl+x to boot with your modified parameters
# System boots, then stops with:

Entering emergency mode. Exit the shell to continue.
Type "journalctl" to view system logs.
You might want to save "/run/initramfs/rdsosreport.txt" to a USB stick or /boot
after mounting them and attach it to a bug report.

switch_root:/#

# You now have an initramfs shell!
# The prompt "switch_root:/#" indicates you're in initramfs

# Check what's mounted
switch_root:/# mount | grep sysroot
/dev/mapper/rhel-root on /sysroot type xfs (ro,relatime,seclabel,attr2,...)

# Notice: /sysroot is mounted READ-ONLY (ro)
# The real root filesystem is at /sysroot, not /

You're in! The switch_root:/# prompt means you're in the initramfs shell with access to the system. No password was required.

Press Ctrl+x to boot with your modified parameters. The system starts booting - you may see various messages as hardware initializes and the initramfs loads. Then it stops with the message shown and drops you to a shell prompt. The prompt switch_root:/# tells you where you are - in the initramfs, about to switch to the real root. But rd.break stopped that switch. Check what's mounted with mount | grep sysroot. You'll see the real root filesystem is mounted at /sysroot - not at / like normal. And critically, it's mounted read-only (ro). This is important - you can't change anything yet, including the password file. The current / is the initramfs - a temporary filesystem in memory. /sysroot is your real system. We need to remount /sysroot as read-write, then enter it to make changes.

Step 4: Mount Root Read-Write

# The root filesystem at /sysroot is read-only
# We need to remount it with write permissions

switch_root:/# mount -o remount,rw /sysroot

# Verify it's now read-write
switch_root:/# mount | grep sysroot
/dev/mapper/rhel-root on /sysroot type xfs (rw,relatime,seclabel,attr2,...)

# Notice: now shows 'rw' instead of 'ro'

✓ Checkpoint

Verify mount shows rw (read-write) for /sysroot. If it still shows ro, the remount didn't work - check for typos and try again.

Why remount? The initramfs mounts your root read-only as a safety measure during the boot preparation phase. We override this to make changes.

Step 5: Reset Password

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

# Your prompt changes - you're now "in" the real system
sh-5.1# 

# Reset the root password
sh-5.1# passwd root
Changing password for user root.
New password:         # Type new password (not displayed)
Retype new password:  # Type again to confirm
passwd: all authentication tokens updated successfully.

# If the account was locked, unlock it:
sh-5.1# passwd -u root
Unlocking password for user root.
passwd: Success

# Alternatively, check account status:
sh-5.1# passwd -S root
root PS 2024-01-20 0 99999 7 -1 (Password set, SHA512 crypt.)

Don't exit yet! The password is changed, but we still need to fix SELinux context. Continue to the next step.

chroot changes your root directory to /sysroot. After this command, / means /sysroot, and all paths resolve relative to it. The prompt changes from switch_root:/# to sh-5.1# indicating you're now in a shell from the real system. Now run passwd root to change the password. You'll be prompted to enter the new password twice. Passwords aren't displayed as you type - this is normal. The message "all authentication tokens updated successfully" means the password was changed. If the account was locked (not just password forgotten), use passwd -u root to unlock it. You can check account status with passwd -S root. The output shows password status (PS = password set, LK = locked), last change date, and password aging info. At this point, the password is changed in /etc/shadow. But we're not done - there's a critical SELinux step remaining. Don't reboot yet!

Locked vs Forgotten Accounts

Forgotten Password

Password unknown but account active
Solution: passwd root
Sets new password, account works

Locked Account

Account administratively locked
Password might be known but can't login
Solution: passwd -u root to unlock
May also need new password

# Check if account is locked
sh-5.1# passwd -S root
root LK 2024-01-20 0 99999 7 -1 (Password locked.)  # LK = Locked!

# Or check /etc/shadow directly
sh-5.1# grep ^root /etc/shadow
root:!!$6$abc123...:19742:0:99999:7:::  # !! means locked

# Unlock the account
sh-5.1# passwd -u root

# For both problems - set new password and ensure unlocked:
sh-5.1# passwd root       # Set new password
sh-5.1# passwd -u root    # Ensure unlocked

It's important to understand the difference between a forgotten password and a locked account - they have different solutions. A forgotten password means the account is fine, you just don't know what to type. Running passwd root sets a new password and solves it. A locked account means the account is administratively disabled. The password field in /etc/shadow has !! or ! prepended, which prevents all password authentication. Even if you know the password, login fails. Locked accounts need passwd -u (unlock) to work again. You can check account status with passwd -S. Look at the second field: PS means password set (normal), LK means locked. Or examine /etc/shadow directly - !! or ! before the password hash indicates locked. For complete recovery, do both: set a new password with passwd root, then ensure it's unlocked with passwd -u root. This handles both scenarios. The passwd command automatically unlocks when you set a new password, but running -u explicitly ensures it.

Step 6: Fix SELinux Context

Critical step! When we changed /etc/shadow outside the normal boot process, its SELinux security context became incorrect. Without fixing this, login will still fail.

# Still in chroot, create the autorelabel trigger file
sh-5.1# touch /.autorelabel

# Verify it was created
sh-5.1# ls -la /.autorelabel
-rw-r--r--. 1 root root 0 Jan 20 10:00 /.autorelabel

# This file tells SELinux to relabel the entire filesystem on next boot

⚠ Most common failure! Forgetting this step is the #1 reason password reset doesn't work. You changed the password correctly, but SELinux blocks login because /etc/shadow has the wrong context.

What happens: On next boot, before login, SELinux examines every file and restores correct labels. This can take several minutes on large filesystems. Be patient.

This is the most important step that people forget. Let me explain why it's necessary. SELinux (Security-Enhanced Linux) labels every file with a security context. The shadow file where passwords are stored has a specific context that allows the login process to read it. When we changed /etc/shadow using chroot, we bypassed the normal mechanisms. The file was modified but didn't get the correct SELinux label. PAM (the authentication system) runs in a confined SELinux domain. When it tries to read /etc/shadow with wrong context, SELinux denies access. Result: correct password, but "login incorrect." The /.autorelabel file is a trigger. When the system boots and SELinux sees this file in the root directory, it performs a complete filesystem relabel before continuing boot. Every file gets examined and labeled correctly. Creating this file is simple: touch /.autorelabel. That's it. But forgetting it means you'll reboot, try to log in with your new password, and fail. You'd have to go through the entire rd.break process again just to create this file.

Alternative: Targeted Relabel

# Instead of relabeling entire filesystem (slow),
# you can fix just the shadow file's context

# Method 1: Load SELinux policy and fix context manually
sh-5.1# load_policy -i
sh-5.1# restorecon -v /etc/shadow
Relabeled /etc/shadow from system_u:object_r:unlabeled_t:s0 
          to system_u:object_r:shadow_t:s0

# Method 2: If load_policy isn't available, use /.autorelabel
sh-5.1# touch /.autorelabel

# Full relabel takes time but is more reliable
# Targeted restorecon is faster but requires working SELinux tools

Exam tip: The touch /.autorelabel method is simpler and always works. Use it unless you have a specific reason for targeted relabeling. Full relabel might take 5-10 minutes but is foolproof.

There's an alternative to full filesystem relabeling. If you can load the SELinux policy in the initramfs environment, you can fix just the shadow file's context. load_policy -i loads the SELinux policy. restorecon -v /etc/shadow then restores the correct context to that specific file. The -v flag shows what changed. This is faster than full relabeling - seconds instead of minutes. But it has requirements: the SELinux policy must be loadable in the initramfs environment, and the tools must be available. The touch /.autorelabel method always works because it delegates the relabeling to the normal boot process where everything is available. It just takes longer. For the RHCSA exam, the simple /.autorelabel method is recommended. It's reliable, easy to remember, and you're not under time pressure for the relabeling itself - it happens during boot while you wait. In production, if you're frequently resetting passwords (you shouldn't be), the targeted method saves time.

Step 7: Exit and Reboot

# Exit the chroot environment
sh-5.1# exit

# Back at initramfs prompt
switch_root:/# 

# Exit initramfs to continue boot (which triggers reboot)
switch_root:/# exit

# System reboots automatically
# During boot, you'll see SELinux relabeling messages:
*** Warning -- SELinux targeted policy relabel is required.
*** Relabeling could take a very long time, depending on file
*** system size and speed of hard drives.
****

# Wait for relabeling to complete (may take several minutes)
# System reboots again after relabeling
# Normal boot proceeds, login with new password!

✓ Final Checkpoint

After relabeling completes and system boots, log in as root with your new password. If it fails, you likely forgot /.autorelabel.

Time to complete the recovery. First, type exit to leave the chroot. You return to the initramfs prompt (switch_root:/#). Then type exit again to leave the initramfs shell. This tells the initramfs to continue, but since we interrupted mid-boot, it effectively triggers a reboot. The system restarts. This time, it boots normally - no rd.break, normal kernel parameters. But before reaching the login prompt, SELinux checks for /.autorelabel. Finding it, SELinux enters relabeling mode. You'll see a warning that relabeling is happening. The system examines every file, checks its context, and fixes any that are wrong. On a minimal system, this might take 2-3 minutes. On a large server with many files, it could take 10+ minutes. Be patient - don't interrupt. After relabeling completes, the /.autorelabel file is removed (so it doesn't relabel on every boot), and the system reboots once more. This final boot is normal. You should see the login prompt. Enter root and your new password. Success!

Complete Procedure

1 Reboot system, press any key to interrupt GRUB countdown

2 Select kernel entry, press 'e' to edit

3 Find linux line, add rd.break at the end

4 Press Ctrl+x to boot

5 mount -o remount,rw /sysroot

6 chroot /sysroot

7 passwd root (enter new password twice)

8 touch /.autorelabel ← DON'T FORGET!

9 exit, exit (exit chroot, then exit initramfs)

10 Wait for relabeling, login with new password

Here's the complete procedure in a quick-reference format. Memorize these steps - you need to execute them quickly and correctly on the RHCSA exam and in production emergencies. Step 1-4 is GRUB interaction: interrupt boot, edit entry, add rd.break, boot. Step 5-6 prepares the environment: remount read-write, chroot into real system. Step 7-8 makes the changes: new password, relabel trigger. Step 9-10 completes: exit both shells, wait for relabeling, verify login. The most commonly forgotten step is 8 - touch /.autorelabel. Write it on your hand during the exam if you have to. Without it, everything else was wasted effort. Practice this procedure multiple times until it's automatic. Set up a test VM, break into it, reset the password, verify you can login. Do it again until you can complete the whole process in under 5 minutes.

Security Implications

Physical access = Root access. The rd.break technique requires no authentication. Anyone with console access can reset the root password and take control of the system.

Physical Security

Servers must be in locked rooms. Limit who has physical access to machines.

GRUB Password

Set a GRUB password to prevent unauthorized boot parameter editing.

BIOS/UEFI Password

Prevent booting from external media. Lock BIOS configuration.

Disk Encryption

LUKS encryption protects data even if attacker boots their own media.

Defense in depth: Combine multiple protections. No single measure is sufficient - physical security, GRUB password, BIOS password, and encryption together provide robust protection.

The rd.break technique is powerful - and that's a security concern. Anyone with physical or console access can become root in minutes. This is why physical security matters enormously for servers. Servers should be in locked data centers or server rooms. Access should be logged and limited. Even cleaning staff shouldn't have unsupervised access. GRUB passwords add a layer of protection. You can configure GRUB to require a password before allowing boot parameter editing. This prevents casual rd.break attacks. BIOS/UEFI passwords prevent changing boot order or booting from external media. An attacker could boot a live Linux USB and access files that way - BIOS passwords help prevent this. Full disk encryption with LUKS is the strongest protection. Even if someone boots alternative media, the data is encrypted. Without the passphrase, they can't read or modify anything. The key insight: these are layers of defense. Physical security is first - if someone shouldn't touch the machine, keep them away. But assume physical security can fail and add additional layers.

Setting GRUB Password

# Generate password hash
[root@server ~]# grub2-setpassword
Enter password: 
Confirm password: 

# This creates /boot/grub2/user.cfg with hashed password
[root@server ~]# cat /boot/grub2/user.cfg
GRUB2_PASSWORD=grub.pbkdf2.sha512.10000.ABC123...

# Now GRUB requires password to edit entries or access command line
# Normal booting still works without password

# To remove GRUB password
[root@server ~]# rm /boot/grub2/user.cfg

# For UEFI systems, file location may differ:
[root@server ~]# cat /boot/efi/EFI/redhat/user.cfg

Don't lock yourself out! If you set a GRUB password and forget it, legitimate recovery becomes very difficult. Document the password securely.

GRUB password protection adds security against unauthorized boot parameter modification. grub2-setpassword is the simple way to set it. You enter the password twice, and it creates a file with the hashed password. With a GRUB password set, pressing 'e' to edit boot entries now prompts for the password. Unauthorized users can't add rd.break. Normal booting works without password - users can select different kernels, but can't edit parameters. This balances security with usability. If you need to remove the password (perhaps for legitimate maintenance), just delete the user.cfg file. Important warning: document this password carefully and store it securely. If you forget the GRUB password and need to do recovery, you'd need to boot from external media (which might be blocked by BIOS password) or use other complex methods. A forgotten GRUB password can make legitimate recovery very difficult. Store it in your organization's password vault alongside other critical credentials.

Troubleshooting

Problem	Cause	Solution
Can't stop GRUB countdown	Timeout too fast	Keep pressing keys, try arrow keys
No GRUB menu appears	Hidden menu	Hold Shift (BIOS) or press Esc repeatedly
Can't find linux line	Wrong entry	Look for line with vmlinuz and root=
rd.break doesn't work	Typo or wrong location	Must be on linux line, space before rd.break
No switch_root prompt	Boot continued	rd.break not added correctly, try again
mount remount fails	Filesystem error	May need fsck, or disk hardware issue
passwd command fails	Not in chroot	Must chroot /sysroot first
Login fails after reboot	Forgot /.autorelabel	Repeat process, add autorelabel file
Relabeling takes forever	Large filesystem	Normal - wait 10-15+ minutes

Most common issue: Login fails because /.autorelabel was forgotten. If this happens, go through the rd.break process again - you don't need to change the password again, just create /.autorelabel and reboot.

Various things can go wrong during recovery. Here's how to handle them. Can't stop GRUB: the countdown is fast. Press and hold keys, especially arrow keys which GRUB recognizes. On VMs, be ready immediately after POST. No GRUB menu: some systems hide the menu. Hold Shift during BIOS boot, or tap Esc repeatedly during UEFI boot. Can't find linux line: look for a line containing 'vmlinuz' (the kernel filename) and 'root=' (specifying root filesystem). It might be named 'linuxefi' on UEFI systems. rd.break doesn't work: verify it's on the correct line, with a space before it, at the end. No switch_root prompt: either rd.break wasn't added correctly, or you booted before changes took effect. Try again. mount remount fails: rare, usually indicates filesystem corruption or hardware failure. May need rescue media. Login fails after reboot: 95% chance you forgot /.autorelabel. The good news: just repeat rd.break, create the file (no need to change password again), and reboot.

Alternative Methods

init=/bin/bash

Add init=/bin/bash to linux line
Kernel starts bash instead of systemd
Even more minimal than rd.break
Root filesystem may be read-only
Same remount and chroot needed

Rescue Media

Boot from RHEL installation ISO
Select "Troubleshooting" → "Rescue"
System mounts at /mnt/sysimage
chroot /mnt/sysimage
Works when GRUB is broken

# init=/bin/bash method (at GRUB, add to linux line):
linux ... rhgb quiet init=/bin/bash

# After boot:
bash-5.1# mount -o remount,rw /
bash-5.1# passwd root
bash-5.1# touch /.autorelabel
bash-5.1# exec /sbin/init    # Or: /sbin/reboot -f

When to use alternatives: init=/bin/bash works when rd.break doesn't. Rescue media works when GRUB is broken or you can't modify boot parameters.

There are alternative methods for password recovery. init=/bin/bash replaces systemd with a simple shell. Add it to the linux line instead of rd.break. This is slightly different - you land directly in the real root filesystem (mounted read-only), not in initramfs. You still need to remount read-write, change password, and create /.autorelabel. To exit, either exec /sbin/init to start normal boot, or /sbin/reboot -f to force immediate reboot. Rescue media is useful when GRUB itself is broken or you can't access it. Boot from the RHEL installation ISO, select Troubleshooting, then Rescue a Red Hat Enterprise Linux system. It finds and mounts your installation at /mnt/sysimage. Use chroot /mnt/sysimage, then proceed with password change. rd.break is the standard method and what you should know for RHCSA. But knowing alternatives helps when the standard method doesn't work due to unusual system configurations or GRUB problems.

Best Practices

✓ Do

Practice the procedure on test systems
Always remember /.autorelabel
Document root passwords securely
Use password managers/vaults
Implement physical security
Consider GRUB passwords for sensitive systems
Verify login works after recovery
Audit who performs recovery

✗ Don't

Skip SELinux relabeling step
Use this on systems you don't own
Leave recovery procedure documented publicly
Rely solely on root password knowledge
Forget to test the new password
Interrupt the relabeling process
Ignore the security implications
Perform on production without approval

Ethics reminder: Only perform password recovery on systems you're authorized to administer. Unauthorized access is illegal regardless of technical ability.

Following best practices ensures successful recovery and appropriate security. Practice on test systems first. The RHCSA exam is stressful - you don't want to be remembering steps for the first time under pressure. Set up a VM and practice until it's automatic. Always remember /.autorelabel. This is the difference between success and having to do everything twice. Make it part of your muscle memory: passwd, then immediately touch /.autorelabel. Document passwords properly. Use a password vault or manager. Share credentials appropriately within your team. A forgotten password requiring recovery indicates a documentation failure. Physical security is your first defense. If unauthorized people can't reach the console, they can't use this technique. GRUB passwords add another layer for sensitive systems. Verify your work - after recovery, actually test that login works before walking away. There's nothing worse than thinking you're done and finding out you still can't log in. Finally, ethics: this technique works on any Linux system you have console access to. Only use it on systems you're authorized to administer.

Key Takeaways

GRUB Access: Interrupt boot, press 'e' to edit, add rd.break to linux line, Ctrl+x to boot.

initramfs Shell: Land at switch_root:/# prompt. Remount: mount -o remount,rw /sysroot

Reset Password: chroot /sysroot, then passwd root. Use passwd -u root if locked.

SELinux Fix: touch /.autorelabel — CRITICAL! Then exit twice to reboot.

LAB EXERCISES

Practice the complete password reset procedure on a test VM
Intentionally forget /.autorelabel to see SELinux denial
Lock root account with passwd -l root, then recover
Set a GRUB password and verify it blocks editing
Time yourself - aim for under 5 minutes total
Try the init=/bin/bash alternative method

Next: Configuring Time Synchronization

Let's summarize the essential password recovery skills. GRUB access is your entry point. Interrupt boot, press 'e', find the linux line, add rd.break at the end, boot with Ctrl+x. This must become automatic. The initramfs shell gives you access without authentication. The key command is mount -o remount,rw /sysroot to enable writing. Verify with mount | grep sysroot showing 'rw'. Reset the password with chroot /sysroot followed by passwd root. If the account is locked, also run passwd -u root to unlock it. SELinux fix with touch /.autorelabel is critical. This single step is the difference between success and failure. Don't skip it, don't forget it. Make it automatic: password change, then immediately touch /.autorelabel. Your lab exercises provide essential practice. Intentionally forget /.autorelabel once to see what happens - you'll never forget again after experiencing the failure. Time yourself and aim for speed - on the exam, efficiency matters. Master this procedure - it's a guaranteed RHCSA objective and a skill you'll use throughout your career.