How To Reset Root User Password In CentOS/RHEL 7

How To Reset Root User Password In CentOS/RHEL 7 – Complete Recovery Guide

If you’ve ever locked yourself out of a CentOS 7 or RHEL 7 server by forgetting the root password, you know the panic that sets in. Unlike resetting a regular user password, recovering root access requires booting into a special mode and manually remounting the filesystem. This tutorial walks you through the exact steps to reset a lost root password on CentOS/RHEL 7, including critical SELinux relabeling that most quick guides skip. You’ll also learn why this process differs from older RHEL 6 systems, how to troubleshoot common pitfalls, and how to verify your changes took effect.

This procedure is essential knowledge for any DevOps engineer managing RHEL-based systems and is a core requirement for the RHCSA certification exam. We’ll cover the entire workflow from GRUB2 boot menu edits to final verification, with real-world context for each command.

Prerequisites

• Physical or console access to the server (KVM, IPMI, or direct terminal). You cannot reset the root password remotely via SSH.
• A CentOS 7 or RHEL 7 system (this guide applies to both; tested on CentOS 7.9 and RHEL 7.9).
• Basic familiarity with Linux command line and vi or nano text editing.
• A backup or snapshot of the system (recommended but not strictly required for this procedure).
• Approximately 5-10 minutes of downtime, plus additional time if SELinux relabeling is needed (2-5 minutes for a typical system).

Step 1: Access the GRUB2 Boot Menu

When the system boots, the GRUB2 bootloader presents a menu of available kernels. You’ll need to interrupt the normal boot process to edit the kernel parameters.

1. Start or reboot the system. If it’s already running, use:

   # reboot

2. As soon as the GRUB2 menu appears (usually within 5 seconds), press the e key to edit the default boot entry. The default entry is typically the first one listed.
3. You’ll see a screen similar to this (output may vary slightly based on your system configuration):

   setparams 'CentOS Linux (3.10.0-1160.el7.x86_64) 7 (Core)'
   
           load_video
           set gfxpayload=keep
           insmod gzio
           insmod part_msdos
           insmod xfs
           set root='hd0,msdos1'
           if [ x$feature_platform_search_hint = xy ]; then
             search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos1 --hint-efi=hd0,msdos1 --hint-baremetal=ahci0,msdos1  5a5b5c5d-5e5f-5g5h-5i5j-5k5l5m5n5o5p
           else
             search --no-floppy --fs-uuid --set=root 5a5b5c5d-5e5f-5g5h-5i5j-5k5l5m5n5o5p
           fi
           linux16 /vmlinuz-3.10.0-1160.el7.x86_64 root=/dev/mapper/centos-root ro crashkernel=auto rd.lvm.lv=centos/root rd.lvm.lv=centos/swap rhgb quiet
           initrd16 /initramfs-3.10.0-1160.el7.x86_64.img

4. Use the arrow keys to navigate to the line starting with linux16 (or linuxefi on UEFI systems). This line contains the kernel boot parameters.
5. Move the cursor to the end of the line (press Ctrl+E to jump to the end quickly).
6. Locate the rhgb quiet parameters and replace them with rd.break. The modified line should look like this:

   linux16 /vmlinuz-3.10.0-1160.el7.x86_64 root=/dev/mapper/centos-root ro crashkernel=auto rd.lvm.lv=centos/root rd.lvm.lv=centos/swap rd.break

7. Press Ctrl+X to boot with these modified parameters. The system will boot into the initramfs emergency shell.

Step 2: Remount the Root Filesystem as Read-Write

When the system boots into the initramfs shell, the root filesystem is mounted in read-only mode under /sysroot. You’ll need to remount it with read-write permissions to modify the password file.

1. At the switch_root:/# prompt, verify the current mount status:

   # mount | grep sysroot

   Output:

   /dev/mapper/centos-root on /sysroot type xfs (ro,relatime,attr2,inode64,noquota)

   The ro flag confirms the filesystem is read-only.
2. Remount the filesystem as read-write:

   # mount -o remount,rw /sysroot

3. Verify the change:

   # mount | grep sysroot

   Output should now show rw:

   /dev/mapper/centos-root on /sysroot type xfs (rw,relatime,attr2,inode64,noquota)

Step 3: Change the Root Password

With the filesystem writable, you can now reset the root password. However, you’ll need to use a chroot jail to ensure commands operate on the correct filesystem.

1. Change into a chroot environment where /sysroot becomes the new root:

   # chroot /sysroot

   The prompt will change to sh-4.2#, indicating you’re now operating within the chroot.
2. Reset the root password using the passwd command:

   # passwd

   You’ll be prompted to enter and confirm the new password:

   Changing password for user root.
       New password:
       Retype new password:
       passwd: all authentication tokens updated successfully.

3. Exit the chroot environment:

   # exit

Step 4: Handle SELinux Relabeling

CentOS/RHEL 7 uses SELinux in enforcing mode by default. When you reset the root password, the /etc/shadow file is modified, but SELinux contexts aren’t applied because SELinux isn’t active in the initramfs environment. Without relabeling, you’ll be unable to log in with the new password.

1. Create an .autorelabel file to trigger a full SELinux relabel on the next boot:

   # touch /sysroot/.autorelabel

2. Exit the initramfs shell to reboot the system:

   # exit

   The system will now reboot. During the next boot, you’ll see a message like:

   *** Warning -- SELinux relabel is required.
       *** Relabeling could take a very long time, depending on file
       *** system size and speed of hard drives.

   The relabeling process may take several minutes, especially on systems with large filesystems. Do not interrupt this process.

Step 5: Verify the Password Reset

After the system reboots, verify that you can log in with the new root password and that SELinux contexts are correctly applied.

1. Log in as root using the new password.
2. Check the SELinux status to confirm it’s enforcing:

   # getenforce

   Expected output:

   Enforcing

3. Verify the /etc/shadow file has the correct SELinux context:

   # ls -Z /etc/shadow

   Expected output (context may vary slightly):

   -rw-------. root root system_u:object_r:shadow_t:s0 /etc/shadow

4. Test sudo or su functionality if other users rely on root access:

   # su - someuser

   Then attempt to switch back to root:

   $ su -

   Enter the new root password to confirm it works.

Common Pitfalls and Troubleshooting

1. GRUB2 Menu Doesn’t Appear

If the GRUB2 menu flashes by too quickly or doesn’t appear at all:

• Check if the system is configured to hide the GRUB2 menu. Edit /etc/default/grub and ensure GRUB_TIMEOUT is set to a positive value (e.g., GRUB_TIMEOUT=5). Then run:

  # grub2-mkconfig -o /boot/grub2/grub.cfg

• For UEFI systems, you may need to press a specific key (e.g., Esc or F12) to access the boot menu. Consult your hardware documentation.

2. Filesystem Remains Read-Only After Remount

If mount -o remount,rw /sysroot doesn’t work:

• Check for filesystem errors. If the filesystem is corrupted, you may need to run fsck first:

  # fsck -y /dev/mapper/centos-root

• If the filesystem is XFS, ensure it wasn’t mounted with the norecovery option. XFS requires a clean shutdown to remount as read-write.

3. SELinux Relabeling Fails or Takes Too Long

If the relabeling process hangs or fails:

• Check the system logs for SELinux errors:

  # journalctl -b | grep -i selinux

• If relabeling is interrupted, manually trigger it again:

  # touch /.autorelabel
      # reboot

• For large filesystems, consider temporarily setting SELinux to permissive mode to speed up the process (not recommended for production):

  # setenforce 0

  After relabeling, set it back to enforcing:

  # setenforce 1

4. Password Reset Doesn’t Persist After Reboot

If the password reverts after reboot:

• Ensure you ran touch /.autorelabel before rebooting. Without this, SELinux may block access to the modified /etc/shadow file.
• Verify the filesystem was properly remounted as read-write before running passwd. If it was read-only, the password change wouldn’t persist.
• Check for immutable flags on /etc/shadow:

  # lsattr /etc/shadow

  If the i flag is set, remove it:

  # chattr -i /etc/shadow

Key Takeaways

• GRUB2 is your entry point: Editing the boot parameters to include rd.break is the only way to interrupt the boot process and gain root access without the password.
• SELinux relabeling is mandatory: Skipping touch /.autorelabel will leave you locked out, even with the correct password. This is the most common mistake in root password recovery.
• Filesystem permissions matter: The root filesystem is mounted read-only by default in the initramfs environment. You must remount it as read-write before making changes.
• Chroot is required for consistency: Using chroot /sysroot ensures commands like passwd operate on the correct filesystem paths.
• Verification is critical: Always confirm SELinux is enforcing and the /etc/shadow context is correct after rebooting. A quick getenforce and ls -Z /etc/shadow can save hours of troubleshooting.

FAQ

Can I reset the root password remotely via SSH?

No. Resetting the root password requires direct console access to interrupt the boot process and edit GRUB2 parameters. SSH access is not available during the early boot stages where this procedure is performed.

What’s the difference between rd.break and init=/bin/bash?

rd.break stops the boot process in the initramfs environment, where the root filesystem is mounted under /sysroot. This is the recommended method for RHEL/CentOS 7. init=/bin/bash boots directly into a minimal shell, but the root filesystem may still be read-only, and SELinux contexts are not handled as cleanly. rd.break is more reliable for modern systems.

How do I reset the root password on RHEL 8 or CentOS 8?

The process for RHEL 8/CentOS 8 is nearly identical, but with a few key differences:

• The kernel boot parameter line starts with linux instead of linux16 or linuxefi.
• After remounting /sysroot as read-write, you may need to run mount -o bind /dev /sysroot/dev before chrooting to ensure device files are available.
• SELinux relabeling is still required, so touch /.autorelabel remains necessary.

What if I don’t have console access to the server?

If you lack direct console access (e.g., a cloud VM or remote server), you’ll need to:

• Use the cloud provider’s "rescue mode" or "serial console" feature (e.g., AWS EC2 "Get System Log" or "EC2 Serial Console," Azure "Boot Diagnostics").
• For physical servers, use IPMI or iDRAC/iLO to access the console remotely.
• As a last resort, attach the disk to another system and manually edit /etc/shadow (not recommended due to SELinux complexities).

🛒 Recommended gear on Amazon

Disclosure: some links above are affiliate links — if you buy through them I may earn a small commission at no extra cost to you. Thanks for supporting the channel!