Root Password Reset from Boot Loader
One objective, asked in some form on almost every attempt. The procedure is six commands and the failure mode is always the same: the password is changed, the machine reboots, and the new password does not work - because /etc/shadow was written with the wrong SELinux label. That mechanism is demonstrated here on a running system.
Operating Running Systems Guide 24 of 67 Advanced
- OSRHEL 10.0
- Kernel6.12.0-55.9.1.el10_0
- dnf4.20.0
- Flatpak1.16.0
- TimeAbout 16 min
rd.break drops you into the initramfs shell before the real root filesystem is handed over, which is why the disk is at /sysroot and mounted read-only. That is the whole reason for the mount -o remount,rw and the chroot - without both, you are editing a file in a temporary root that is about to disappear.
| Server Name | IP Address | OS | Roles | CPU | RAM | HDD |
|---|---|---|---|---|---|---|
| RHCSA-A01 | 192.168.0.31 | RHEL 10.0 | Practice node (graded) - spare /dev/sda | 2 Core | 4 GB | 50 GB + 15 GB |
This guide includes
Use this because it is asked in some form on almost every attempt. This matters because the SELinux step is the one people skip - and skipping it loses the mark even though the password change itself worked perfectly.
- reading the boot arguments you are about to edit
- interrupting at the boot menu, which needs a console
- finding where the password actually lives
- remounting, chrooting and changing it, in six commands
- doing the SELinux step people skip, then proving it took and locking others out
Before you start
- Console access to the machine - physical, or a hypervisor console. SSH is not enough.
- The session creates and removes a test account and a labelled test file; it does not change root's password.
-
The boot arguments you will be editing
-
At the boot menu
-
Where the password actually lives
-
Remount, chroot, change
-
The SELinux step people skip
-
`/.autorelabel`, and the targeted alternative
-
Proving the change took
-
Stopping anyone else doing this