How to Reset a Forgotten Root or User Password on Fedora

Reset a forgotten Fedora root or user password by booting into single-user mode, chrooting to the system, and running the passwd command.

You are locked out of your own machine

You sit down at your Fedora desktop after a weekend away. You type your usual password at the GNOME login screen. It rejects you. You try again. Same result. You did not change it. You did not mistype it. The system simply refuses to let you in. This happens. Passwords fade from memory, or a rushed terminal command earlier left you locked out. The fix does not require reinstalling. It does not require wiping the drive. You just need to interrupt the normal boot sequence and drop into a maintenance shell. Physical access to the hardware is the only requirement.

What is actually happening

Fedora boots through a chain of stages. The firmware hands control to GRUB. GRUB loads the kernel and an initial ramdisk. The initial ramdisk mounts your real root filesystem, starts systemd, and systemd launches the display manager where you type your password. When you forget that password, you cannot pass the display manager. The workaround bypasses systemd entirely. You tell the kernel to skip the normal init process and launch a plain shell instead. That shell runs inside the initial ramdisk, which means your actual system files are mounted under /sysroot. You switch your environment to that mounted filesystem, change the password hash in /etc/shadow, and tell SELinux to rebuild its security labels. Then you boot normally. The system never knew you were locked out.

The initial ramdisk is a temporary root environment built by dracut. It contains only the drivers and tools needed to mount your real disk and hand control to the main OS. When you append init=/sysroot/bin/sh to the kernel command line, you override the default init=/usr/lib/systemd/systemd parameter. The kernel still mounts your root partition, but instead of starting the full service stack, it executes a basic POSIX shell. You are now inside a minimal environment with direct access to your installed system. Running chroot /sysroot changes your active root directory to the mounted partition. All subsequent commands operate on your actual Fedora installation. Running passwd updates /etc/shadow through the standard PAM stack. Creating /.autorelabel triggers a full SELinux context scan on the next boot. The mechanism is straightforward, but the order of operations matters. A misstep leaves you with a broken filesystem or a system that refuses to boot.

The fix

Follow these steps exactly. The sequence is strict. Changing the order breaks the recovery.

  1. Reboot the system and hold Shift or tap Esc repeatedly as the hardware posts. The GRUB menu appears. If you do not see it, your bootloader is likely configured with GRUB_TIMEOUT=0, but the menu still shows if you interrupt early enough.

  2. Highlight the default Fedora entry. Press e. The screen changes to a text editor showing the boot configuration. Find the line starting with linux or linux16. It ends with quiet or rhgb quiet. Move the cursor to the very end of that line. Add rw init=/sysroot/bin/sh. Do not remove the existing words. Just append. Press Ctrl+X or F10 to boot.

  3. The system boots to a plain text prompt. You are inside the initial ramdisk. Your real system is mounted at /sysroot. Switch your environment to the installed system.

chroot /sysroot
# Changes the active root directory to the mounted system partition
# All subsequent commands now operate on your actual Fedora installation
# The prompt usually changes to reflect the new root environment
  1. Change the password. Run passwd for root, or append a username for a regular account.
passwd
# Prompts for a new root password twice
# Replaces the existing hash in /etc/shadow through the PAM stack
# Use 'passwd username' to target a regular account instead
  1. Handle SELinux. Fedora enforces mandatory access control. Changing password files or booting in single-user mode can leave security contexts out of sync. You must trigger a full relabel on the next boot.
touch /.autorelabel
# Creates a trigger file that the initramfs detects during startup
# Forces a complete scan of all filesystem labels before handing control to systemd
# Skipping this step causes login failures or application permission denials later
  1. Exit the chroot environment. Force a clean restart.
exit
# Returns you to the initial ramdisk shell
# Unmounts the chroot environment and restores the temporary root
reboot -f
# Bypasses systemd shutdown hooks and restarts the hardware immediately
# Ensures the autorelabel trigger is processed on the next boot cycle

Reboot before you debug. Half the time the symptom is gone.

Verify it worked

The system will take longer than usual to reach the login screen. The screen might show Relabeling filesystem... or sit at a black screen with a blinking cursor. This is normal. A full SELinux relabel on a modern drive can take five to fifteen minutes depending on file count. Do not interrupt it. When the login screen finally appears, enter your new password. Open a terminal and run lastlog or check your session. If you get a clean login and your desktop environment loads, the reset succeeded. You can also verify the password hash changed by checking the timestamp on /etc/shadow, though that requires root access which you now have.

Run journalctl -xe after logging in. The x flag adds explanatory text and the e flag jumps to the end. Look for systemd-logind entries confirming a successful authentication. If you see repeated pam_unix failures, your password was not applied correctly or you are typing the wrong username. Check /etc/passwd to confirm the account exists and has the correct shell. Config files in /etc/ are user-modified. Files in /usr/lib/ ship with the package. Edit /etc/. Never edit /usr/lib/. Trust the package manager. Manual file edits drift, snapshots stay.

Common pitfalls and what the error looks like

Several things can go wrong during this process. The most common is a GRUB password. If your system requires a password to edit boot entries, you cannot bypass it this way. You will see Enter password: immediately after pressing e. You will need to boot from a Fedora Live USB, mount the root partition, and chroot from there. Another frequent issue is LUKS disk encryption. If your root partition is encrypted, the initramfs will stop at the Enter passphrase for /dev/mapper/fedora-root: prompt. Type your LUKS passphrase first. The rest of the procedure remains identical.

You might also encounter a read-only filesystem error when running passwd. The kernel sometimes mounts the root partition as read-only even with the rw flag if the filesystem has errors. The terminal will print passwd: Authentication token manipulation error. Run fsck /dev/mapper/fedora-root from the chroot environment to repair it. The command will print Pass 1: Checking inodes, blocks, and sizes followed by repair actions. After fsck completes, remount with mount -o remount,rw / and try passwd again.

SELinux denials are the silent killer. If you skip the touch /.autorelabel step, you will log in successfully but applications will crash with permission errors. The journalctl -t setroubleshoot output will show SELinux is preventing /usr/bin/gnome-shell from 'write' accesses on the file /home/username/.config. Read those messages before disabling SELinux entirely. The relabel fixes the mismatch without weakening your security posture. Fedora's release cadence is six months. The N-2 release goes EOL when N+1 ships. Plan upgrades on that cycle. A botched upgrade can leave you unable to boot. Run this from a backup VM first if you can.

Run journalctl first. Read the actual error before guessing.

When to use this vs alternatives

You have multiple ways to recover access to a Fedora system. Choose the right tool for your situation.

Use the GRUB single-user method when you have physical access to the machine and the bootloader is not password protected. Use a Fedora Live USB chroot when GRUB is locked or the bootloader is corrupted. Use sudo passwd username when you still have an active session with sudo privileges and just need to change a password. Use usermod -L username when you need to temporarily disable an account without deleting it. Stay on the upstream Workstation if you only deviate from the defaults occasionally.

Pick the path that matches your access level. Forcing a method you do not understand breaks recovery.

Where to go next