About the day I found out my centOS 9 virtual machine didn’t have the “whatis” command enabled.

Today I started practicing some of the basics on a virtual machine I recently created on UTM. The linux distribution was CentOS 9 and I noticed the “whatis” command was not recognized for some odd reason. At some point I forgot the root password and I was unable to run the “mandb” command. So, here is how I Successfully Reset the Root Password on CentOS 9: A Step-by-Step Guide.

As a system administrator, there are few things more frustrating than losing access to the root account of a Linux system. Recently, I encountered this issue with my CentOS 9 virtual machine running on UTM for macOS. However, after a series of troubleshooting steps and persistent effort, I was able to regain full control. In this post, I’ll share the detailed process I followed to reset the root password, including the issues I faced along the way and how I resolved them.

The Problem: Root Password Lost

The problem began when I realized that I had lost access to the root password on my CentOS 9 virtual machine. I could no longer log in as root via the terminal or activities menu. This is a classic scenario where administrative access is essential, but the password is either forgotten or inaccessible. With no root access, I was unable to administer the system effectively.

Step 1: Booting into Single-User Mode Using GRUB

The first step to regain root access was to boot into single-user mode. Here’s how I did it:

1. Accessing GRUB: During the boot process, I pressed Esc to access the GRUB menu.
2. Editing the Boot Entry: I selected the CentOS 9 boot option, pressed e to edit the boot parameters, and added rw init=/bin/bash at the end of the linux line.
3. Booting into Single-User Mode: I pressed Ctrl + X to boot the system with these modified parameters.

At this point, the system successfully booted into a shell with limited access. This is where I encountered my first issue: the passwd command was not found.

Step 2: Missing passwd Command

In single-user mode, I tried to reset the password using the passwd command, but to my surprise, the system returned an error stating that passwd: command not found. This is a common issue in minimal environments, where not all utilities are available.

Resolution: I resolved this by manually mounting the filesystem in read-write mode and accessing the /etc/shadow file. I checked for any discrepancies and manually edited the file to clear the root password hash temporarily, allowing me to log in without a password.

Bash:

vi /etc/shadow
# Change the root line to:
# root::18822:0:99999:7:::

After saving the changes, I rebooted the system.

Step 3: Unable to Log In After Reboot

Once the system rebooted, I found that I still couldn’t log in as root through the text-based login screen. The system was not accepting the root password. This was a critical point in the troubleshooting process.

Resolution: I realized the problem might be linked to the system booting into a minimal mode, which could be preventing the full desktop environment from loading. To fix this, I booted the system back into GRUB, edited the boot entry again, and used the systemd.unit=multi-user.target parameter to boot into a non-graphical, multi-user target

Boot into Multi-User Mode

1. At the GRUB menu, pressed e.
2. Append systemd.unit=multi-user.target to the linux or linux16 line. Bash:
   linux /vmlinuz-<kernel-version> root=/dev/mapper/<root-volume> ro systemd.unit=multi-user.target
3. Booted with Ctrl + X or F10.
4. This should bring you to a text-based login screen. Log in as root and proceed to diagnose or fix the issue.

At this point the text-based login screen was not taking the password I was able to update.

Boot Back into Single-User Mode

• Rebooted the system.
• At the GRUB menu, press e to edit the default boot entry.
• Append rw init=/bin/bash to the linux or linux16 line again and boot with Ctrl + X or F10.
• Verified the Root Password
• Remounted the root filesystem as writable: mount -o remount,rw /
• Manually set the root password again: passwd

Step 4: Relabeling SELinux Contexts

After successfully logging in as root, I encountered another issue: SELinux contexts. Sometimes, changes made in single-user mode don’t properly reflect the security contexts needed for certain system files, including login configurations. This can result in the root password not being properly accepted or certain files being inaccessible.

Resolution: To resolve this, I created an .autorelabel file in the root directory, which would trigger an SELinux relabel process during the next boot. Here’s the command I used:

Bash:

touch /.autorelabel
reboot

But, guess what? the system was not recognizing the reboot command either. So, instead, here is what I did:

touch /.autorelabel
exec /sbin/init 6

I replaced the current shell with the init system to trigger a reboot.

This step ensured that all files were relabeled with the correct SELinux contexts, eliminating any issues with file access or password acceptance.

Step 5: Success — Gaining Full Access

After the system rebooted, I was finally able to log in successfully as root. The password reset worked, and I had regained full access to my CentOS 9 virtual machine. Finally, I was able to run the “mandb” command as root user and it worked fine.

Key Takeaways

• GRUB Editing: The ability to edit boot parameters in GRUB and boot into single-user mode is crucial when recovering a system with a lost root password.
• Missing Commands: In minimal environments, essential tools like passwd may not be available. In such cases, manual file edits (e.g., /etc/shadow) are often the best solution.
• SELinux Issues: If you encounter login issues after password changes, SELinux can sometimes interfere with the changes. Triggering an SELinux relabel (.autorelabel) can resolve these problems.
• Persistence Pays Off: It may take multiple attempts and methods to regain access, but with the right troubleshooting steps, even a complex root password issue can be resolved.

Changing a root password on CentOS 9 can be challenging, especially when you encounter issues with missing commands, inaccessible login screens, or SELinux context problems. However, with the right steps, editing GRUB, manually resetting the password, and relabeling SELinux contexts, I was able to regain access to my system and ensure everything was functioning correctly. If you find yourself in a similar situation, don’t panic; persistence and a systematic approach will help you resolve the issue.

For most cases, resetting the root password is the more efficient and practical solution, especially when you’re dealing with a virtual machine where data and configuration integrity is important. It’s a relatively simple fix and can save you a lot of time and effort in reconfiguring your environment.

However, if you feel like your system has accumulated too many issues or you’re looking for a completely fresh start, creating a new VM might be the better approach, but be aware of the time it will take to set up everything again.

In your specific case, since you were able to reset the root password and retain full access to the system, you made the most efficient choice, especially considering the time and resources involved in setting up a new VM.

Let me know in the comments if you’ve had similar experiences or if you have any questions about the process!