Losing or forgetting the root password can happen for a variety of reasons – you might inherit a system from someone else or simply misplace the credentials. As a system administrator, you may eventually encounter a critical moment where immediate root access is needed but the password is unknown. Fortunately, Linux provides a straightforward recovery method using the GRUB bootloader to enter single-user/emergency mode and reset the root password. This guide explains when and why a root password reset is needed, and provides a step-by-step walkthrough for Red Hat Enterprise Linux (RHEL) or CentOS versions 7 and 8.
When and Why Would You Reset the Root Password?
There are a few common scenarios that call for resetting the root password:
-
Forgotten Password: The most typical case is simply forgetting the root password on a server you administer. Without root access, you cannot perform critical system changes or maintenance.
-
Inherited Systems: You might be handed a system (in a job role or from another team) where the root password was never documented or passed on.
-
Locked or Expired Password: In some cases, security policies or misconfigurations could lock the root account or expire the password, requiring a manual reset via recovery mode.
-
Emergency Access: During disaster recovery or troubleshooting in single-user mode, you might find you need to ensure the root password is known to log in.
In such situations, resetting the root password via the GRUB bootloader is a reliable solution. The process involves rebooting into a special mode where you have root shell access without needing the password. Below, we will walk through this process in detail.
Prerequisites: You will need physical or console access to the server. This method requires interacting with the GRUB boot menu during startup, so you either need to be at the machine with a keyboard/monitor or use a virtual console (for a VM or via out-of-band management). Remote SSH access alone is not sufficient since you must interrupt the boot sequence.
Step-by-Step Guide to Resetting the Root Password via GRUB
Follow these steps to reset the root password on RHEL/CentOS 7 or 8 using the GRUB bootloader. The process is very similar for both versions, with only minor differences noted in the steps.
1. Reboot and Access the GRUB Menu:
Initiate a reboot of the system. As the system restarts, watch for the GRUB bootloader menu (a list of kernel or OS choices). If your system normally boots without showing a menu, press Esc or Shift (on some systems) to bring up the GRUB menu. Once the menu appears, quickly press an arrow key to pause the countdown so you have time to make changes. Use the ↑/↓ keys to highlight the kernel you want to boot (usually the default latest kernel). Now press e
to edit the selected boot entry. This will open the GRUB editor interface where you can modify boot parameters.
GRUB boot menu on a RHEL 8 system. Use the arrow keys to select the latest kernel entry, then press e to edit its boot options. This interrupts the normal boot process so you can enter recovery commands.
2. Edit Kernel Parameters to Enter Single-User Mode: In the GRUB edit screen, find the line that starts with linux16
(for RHEL/CentOS 7) or linux
(for RHEL/CentOS 8). This line contains the kernel path and boot parameters (for example, it may include rhgb quiet
and other settings). Using the keyboard, navigate to the end of this linux16/linux
line, add a space, and then type **rd.break**
. The rd.break
parameter instructs the system to break out of the normal boot process and drop you into an initramfs emergency shell before the root filesystem is mounted. (In older documentation, you might see recommendations to use single
or init=/bin/bash
– however, rd.break
is the modern and reliable method for RHEL7/8.) After appending rd.break
, press Ctrl + X (or Ctrl + Ctrl on some systems) to boot with the edited parameters. This change is not permanent – it’s a one-time boot alteration that will be forgotten on the next normal boot.
Editing the GRUB entry to append the rd.break
parameter (highlighted in green). On RHEL/CentOS 7, the kernel line begins with linux16
(or linuxefi
on UEFI systems); on RHEL/CentOS 8 it begins with linux
. Add rd.break
to the end of this line and press Ctrl+X to start booting into emergency mode.
3. Boot into the Emergency Single-User Shell: After the edited entry boots, the system will stop early in the boot process and you will be presented with a minimal root shell on the initramfs (initial RAM disk) – you might see a prompt like **switch_root:/#**
or similar. This shell is running as the root user without a password (because we interrupted the normal boot). However, at this point the real root filesystem of your OS is mounted in read-only mode at a temporary mount point (usually /sysroot). Before we can change the password, we need to remount the filesystem with write access and switch into it.
4. Remount the Root Filesystem as Read/Write: By default, the system mounted your root filesystem under /sysroot in read-only mode (ro
). You can verify this by running mount | grep sysroot
(this will show that /sysroot is mounted ro
). To reset the password, we must allow writing to the disk. Remount the filesystem with read-write permissions using the following command:
mount -o remount,rw /sysroot
This command re-mounts the /sysroot mount point with read-write (rw
) access. Next, “change root” into the sysroot to make it the active root filesystem:
chroot /sysroot
After running chroot /sysroot
, your shell context changes to the actual installed system’s root (/
) instead of the initramfs. (Your prompt might change, for example, from switch_root:/#
to something like sh-4.4#
or similar.) Now any command you run (like passwd
) will affect the actual system installation rather than the temporary initramfs environment.
5. Reset the Root Password: Now that you have write access and are operating within the real system, you can change the forgotten root password. Use the Linux passwd
command to set a new root password:
passwd root
When prompted, enter the new root password and confirm it by entering it again. (If you omit the username and just run passwd
, it defaults to changing the password of the current user, which in this chroot environment is root, so passwd
alone is equivalent in this case.) Upon success, you will see a message indicating the password was updated. At this point, the root account now has the new password you entered. Make sure to choose a strong password and remember it for future use.
6. Handle SELinux (Create Autorelabel Flag): If your system has SELinux enabled (which is the default on RHEL/CentOS), an extra step is required before rebooting. Because we reset the password while in this minimal mode, SELinux was not active to properly label the new /etc/shadow
file. The result is that the file containing passwords may have incorrect SELinux context, potentially preventing login. To fix this, you need to schedule a filesystem relabel on next boot. This is done by creating an empty file named .autorelabel
at the root:
touch /.autorelabel
This touch
command creates the file /.autorelabel (in the chrooted system). When the system reboots, the presence of this file tells SELinux to relabel the entire filesystem on boot, applying the correct security contexts to all files (including /etc/shadow
). Note: The relabel process can take several minutes if you have a lot of files, so be patient on the next boot. If SELinux is disabled or in permissive mode on your system, this step isn’t strictly necessary, but it doesn’t hurt to do it regardless. Skipping this step on an SELinux-enforced system will likely result in being unable to log in with the new password, as SELinux might deny access due to context mismatch.
7. Reboot the System: We’re almost done. Exit the chroot environment and reboot the system to apply changes. First, exit the chroot shell by typing exit
. This will drop you back to the initramfs prompt (the one with switch_root:/#
). Now type exit
once more (or use the Ctrl+Alt+Del shortcut) to exit the initramfs emergency shell. The system will continue the boot process and reboot. (In some cases, you might instead type reboot
directly after exiting the chroot.) After the reboot, the system will perform the SELinux relabeling (if .autorelabel
was created). You’ll see messages on screen about file contexts being relabeled; once it finishes, the system will reboot itself one more time automatically. Finally, you should get to the normal login prompt.
Now test the new root password by logging in as root. If everything was done correctly, you will be able to authenticate with the new password and regain full root access to the system. Congratulations – you have recovered the root password!
Post-Reset Security Precautions
Resetting the root password should be treated as a sensitive operation. Here are some important security considerations and follow-up actions:
-
Update Credentials Securely: Ensure the new root password is stored securely (in your password manager or vault) and shared only with authorized personnel. If the root password was lost due to miscommunication, establish a better secret management policy.
-
Audit for Unauthorized Access: If you had to reset the password unexpectedly, consider checking system logs for any unusual access attempts. An unauthorized person with console access could potentially reset the root password in the same way. Ensuring that this password change was authorized and that the system’s integrity is intact is important.
-
Secure Bootloader Access: Because the GRUB menu allows root access without a password, anyone with physical or console access could reboot and reset the root password using the same steps you just performed. This is a known security trade-off for convenience. To mitigate this, you can set a GRUB bootloader password to prevent unauthorized edits to boot parameters. With a GRUB password set, an attacker would need that password to enter single-user/emergency mode from the boot menu.
-
BIOS/UEFI and Boot Security: Additionally, secure the BIOS/UEFI settings. Set a firmware password and configure the system to boot only from the primary disk (or disable booting from external media), so that an unauthorized person cannot boot from a live CD/USB to bypass security. For extremely sensitive systems, consider enabling full disk encryption (LUKS) so that even if someone tries to modify the disk (like editing
/etc/shadow
directly), they cannot access it without the decryption passphrase. -
Regular Backups: As a best practice, maintain regular configuration backups (including hashing the root password or having an SSH key for emergency access) so that you have alternative ways to access or restore the system if needed. Also, consider creating an emergency recovery user with sudo privileges as a fallback, which you store safely, to avoid complete lockout if the root account is inaccessible.
By taking these precautions, you reduce the risk of unauthorized password resets and make recovery easier for authorized admins in the future. Always remember that physical access equals full access in most computing environments, so physical security is as important as digital security for your servers.
RHEL 7 vs RHEL 8: Notable Differences in the Procedure
The process for resetting the root password is virtually the same for RHEL/CentOS 7 and 8, but there are a few minor differences to be aware of:
-
GRUB Kernel Line Naming: In the GRUB editor, RHEL7 boot entries typically show the kernel line beginning with
linux16
(for BIOS boot) orlinuxefi
(for UEFI). In RHEL8, the line might simply start withlinux
in the GRUB menu. Functionally, these serve the same purpose – identify the kernel and boot parameters – so you just need to find the line that starts withlinux...
in order to appendrd.break
to it. -
Default Kernel Parameters: Both RHEL7 and RHEL8 include parameters like
ro
(read-only), and possiblyrhgb quiet
. The steps above (addingrd.break
, remounting, etc.) apply to both versions. There’s no change needed in the procedure between 7 and 8 aside from the line name mentioned. After editing, both will drop you into a similar emergency shell environment. -
SELinux and Relabeling: Both RHEL7 and RHEL8 use SELinux in enforcing mode by default. The need to create
/.autorelabel
is the same on both to avoid issues with the changed password file. There is no difference in how this is handled between the two versions. -
Systemd Rescue vs rd.break: Both 7 and 8 use systemd, which means the concept of “single-user mode” is handled via rescue or emergency targets. While one could use kernel options like
systemd.unit=rescue.target
, those modes typically prompt for the root password if one is set (which defeats the purpose if you forgot it!). Therd.break
method we used works at the initramfs level and does not prompt for the password, which is why it is the recommended approach for both RHEL 7 and 8 when you don’t have the root credentials. -
GRUB Version: Technically, both RHEL7 and RHEL8 use GRUB2, so the interface and keystrokes (editing with
e
, booting with Ctrl+X) are the same. RHEL7’s grub might label menu entries slightly differently, but this does not affect the steps needed.
In summary, RHEL/CentOS 7 and 8 share the same root password recovery process. If you understand the steps on one, you can apply them to the other with minimal adjustment. The key difference is simply recognizing the correct kernel line in GRUB to edit (which is straightforward). Always double-check that you’ve added rd.break
correctly and performed the SELinux relabel step, regardless of version.
Conclusion
Resetting a forgotten root password on RHEL or CentOS is doable in a matter of minutes with the proper approach. By interrupting the boot process via GRUB and dropping into an emergency shell, you gain the ability to change the root password from outside the normal running system. We covered how to safely make this change, how to ensure SELinux doesn’t interfere, and how to secure your system afterward. Losing access to root can be stressful, but with this guide, you can regain control of your Linux system quickly and systematically. Always remember to handle the root password with care and bolster your system’s security to prevent unauthorized resets in the future.
Leave a Comment
You must be logged in to post a comment.