Reset root password
You changed the sudoers file to add a new user, made a typo, and now sudo refuses to run. Or you just forgot the root password after six months of using a desktop account. The system is running, but you have no administrative access. You need to reset the password from the outside. This requires physical access or a console connection. Remote SSH won't help if you can't authenticate. The recovery process interrupts the boot, mounts the disk manually, and updates the password file before the normal login system starts.
What's actually happens
The Fedora boot process is a chain of handoffs. GRUB loads the kernel. The kernel loads the initramfs. The initramfs mounts the real root filesystem and hands control to systemd. If you interrupt this chain early enough, you can drop into a shell before the normal login system starts. You are essentially pausing the boot, mounting the disk manually, and changing the password file directly.
The rd.break parameter tells the initramfs to stop and give you a shell instead of continuing to the real root. This is a standard recovery mechanism built into Fedora's boot stack. The initramfs mounts the actual disk at /sysroot inside the emergency environment. You remount that filesystem as read-write, switch your context to it, and run passwd. The command updates /etc/shadow just like it would in a normal session, but you are doing it from a privileged shell that doesn't require authentication.
Config files in /etc/ are user-modified. Files in /usr/lib/ ship with the package. Edit /etc/. The password reset modifies /etc/shadow and /etc/passwd, which live in /etc. The package manager never touches these files during upgrades, so your changes persist safely.
The boot chain is your lever. Pull it early enough, and you control the system before it locks you out.
Interrupt the boot and reset the password
Restart the system. Hold Shift on BIOS systems or tap Esc repeatedly on UEFI systems immediately after the firmware screen. This displays the GRUB boot menu. If the menu appears automatically, skip the key press.
Highlight the default Fedora kernel entry. Press e to edit the boot parameters. Use the arrow keys to find the line beginning with linux or linuxefi. This line contains the kernel path and boot arguments. Move the cursor to the end of that line. Append rd.break with a space before it. Press Ctrl+x or F10 to boot with the modified parameters.
The system will halt and drop you into a dracut emergency shell. You are now inside the initramfs. The real root filesystem is mounted read-only at /sysroot. You must remount it read-write to modify the password file.
Here is how to remount the filesystem and switch to the real system environment.
mount -o remount,rw /sysroot
# Remounts the real root filesystem as read-write.
# The initramfs mounts /sysroot read-only by default.
# You cannot modify /etc/shadow without write access.
chroot /sysroot
# Switches the execution environment to the mounted system.
# Commands now run against the real root, not the initramfs.
# This ensures passwd updates the correct shadow file.
Run the passwd command to set the new password. Enter the password twice when prompted. If you need to reset a regular user's password instead, replace root with the username.
Here is how to update the password and prepare SELinux for the change.
passwd root
# Updates the shadow file with the new password hash.
# The command prompts for the new password and confirmation.
# This works identically to a normal session but bypasses login.
touch /.autorelabel
# Creates a marker file for SELinux.
# SELinux checks for this file on next boot.
# If present, it relabels the filesystem to fix context on modified files.
If SELinux is enforcing, which is the default on Fedora, you must create the .autorelabel file. The passwd command modifies the shadow file, which changes its metadata. SELinux tracks security contexts. If the context drifts, SELinux will deny access to the authentication service on the next boot. The touch command creates the marker. The system detects it during boot and runs a full relabel. This takes extra time on the first reboot. Do not skip this step.
SELinux denials show up in journalctl -t setroubleshoot with a one-line summary. Read those before disabling SELinux. A missing relabel often results in Permission denied errors during login that look like a password failure but are actually context mismatches.
Exit the chroot and reboot the system. The exit command returns you to the initramfs shell. The reboot command triggers the restart.
Here is how to exit the recovery environment and restart the machine.
exit
# Exits the chroot and returns to the dracut shell.
# The system is ready to continue the boot process.
# You must exit chroot before rebooting to avoid errors.
reboot
# Restarts the system from the emergency shell.
# The bootloader will load normally on the next cycle.
# The first boot will be slower due to SELinux relabeling.
The first reboot may take several minutes while SELinux relabels the filesystem. The screen might show Relabeling... or just hang at the plymouth splash. Wait for the process to complete. Interrupting the relabel can leave the system in an inconsistent state.
Touch the autorelabel file. SELinux will fix the context, or you will lock yourself out again.
Verify the fix
Reboot the system normally. Log in with the new root password. If you are using a desktop environment, switch to a TTY with Ctrl+Alt+F3 and log in as root. Run sudo whoami to confirm access.
Here is how to verify the password reset and check for authentication errors.
sudo whoami
# Confirms sudo access is restored.
# Should output 'root' if the password works and sudoers is valid.
# This validates both the password and the sudo configuration.
journalctl -xeu systemd-logind
# Shows recent log lines from the login service.
# The -x flag adds explanatory text for common errors.
# The -e flag jumps to the end of the journal.
The journalctl -xe command reads better than journalctl alone. The x flag adds explanatory text and the e flag jumps to the end. Most sysadmins type journalctl -xeu <unit> muscle-memory style. Check the output for Failed to start user service or Authentication failure. If you see clean login messages, the reset succeeded.
If you see Permission denied or Access denied despite the correct password, SELinux relabeling may have failed or been skipped. Reboot and repeat the process, ensuring you run touch /.autorelabel.
Run journalctl first. Read the actual error before guessing.
Common pitfalls and what the error looks like
Forgetting the SELinux relabel is the most common mistake. If you skip touch /.autorelabel, the shadow file retains its old context or gets an incorrect one. The login service checks the context before validating the password. SELinux denies the access. You see Login incorrect or the session closes immediately. The error appears in the journal as an AVC denial.
The journalctl output will contain lines like audit: type=1400 audit(...): avc: denied { read } for pid=... comm="login" name="shadow". This indicates SELinux blocked the read of the shadow file. The password might be correct, but the security policy prevents the check. Relabeling fixes the context.
LUKS-encrypted systems require the disk passphrase before rd.break takes effect. The boot process stops at the LUKS prompt first. Enter the passphrase to unlock the disk. The system continues to the initramfs, where rd.break drops you into the shell. The steps are identical once you reach the emergency shell. If you cannot unlock the disk, no amount of GRUB editing will help. You must recover the LUKS passphrase first.
Silverblue and other immutable editions handle this differently. The root filesystem is read-only by design. However, the passwd command modifies /etc, which is a writable overlay even on immutable systems. The recovery shell works the same way. The overlay persists across reboots. You can reset passwords on Silverblue using the rd.break method. The overlay mechanism ensures your changes survive without breaking the atomic update model.
If the GRUB menu is hidden or password-protected, you cannot edit the boot entry. A hidden menu occurs when GRUB_TIMEOUT=0 is set in /etc/default/grub. A password-protected menu requires a GRUB password to edit entries. In these cases, boot from a Fedora Live USB. Mount the root partition manually and use chroot from the Live environment. This bypasses GRUB entirely.
Check the GRUB config. A hidden menu is a locked door.
When to use this vs alternatives
Use rd.break when you have console access and need to reset root or repair boot parameters. Use a Live USB chroot when GRUB is password-protected or the initramfs is corrupted and cannot drop to a shell. Use passwd from a working sudo session when you just forgot the root password but still have sudo access for a user. Use authselect when you need to change authentication backends, not just a password. Stay on the standard recovery shell if you only need to fix a password or a simple config file.