Booting into rescue mode when the system fights back
You updated the kernel and the display driver crashed, leaving the login screen as a black void. Or you edited /etc/fstab and the system hangs waiting for a disk that does not exist. You need a shell to fix the error, but the graphical interface is dead and the broken service is blocking the boot process. Single user mode and rescue mode are your escape hatches. They halt the boot sequence before the problematic services start and drop you into a root shell. You can repair the configuration, remove the bad package, or reset a password without the full system interfering.
How the boot chain and rescue target work
Fedora boots through a defined chain. GRUB loads the kernel and the initramfs image. The kernel initializes hardware and mounts the root filesystem. Systemd takes over as PID 1 and starts services based on the default target. By default, Fedora targets graphical.target, which starts the display manager, network, sound, and desktop environment. When you switch to rescue mode, you change the target to rescue.target. Systemd still starts, but it follows a minimal dependency tree. It mounts the root filesystem, starts the console, and drops you into a shell. It skips the display manager and most background services. This isolation prevents the broken service from running. The error cannot block the boot because the service never starts.
GRUB editing is temporary. Changes made in the GRUB editor apply only to the current boot. They do not modify the configuration files on disk. This design is safe. You can experiment with parameters without risking persistent boot failures. If the system boots successfully, the changes vanish. If it fails, you can reboot and try a different parameter.
Fedora's release cadence is six months. The N-2 release goes EOL when N+1 ships. If you are stuck on an old release, rescue mode still works, but package repositories may be archived. Plan upgrades on that cycle to avoid running into dead mirrors during recovery.
Accessing the GRUB editor and switching targets
Reboot the machine and interrupt the boot process to display the GRUB menu. Hold Shift during startup on legacy BIOS systems. Press Esc repeatedly on UEFI systems. Some systems respond to both keys. If the menu does not appear, the timeout has passed. Reboot and try again.
Highlight the default Fedora entry and press e. You are now in the GRUB editor. The screen shows the boot configuration for this entry. Locate the line starting with linux. This line contains the kernel path and boot parameters. Move the cursor to the end of that line. Append systemd.unit=rescue.target to the parameters.
Here is how to modify the kernel line to switch to rescue mode.
linux /vmlinuz-6.8.5-200.fc40.x86_64 root=UUID=a1b2c3d4-... ro quiet systemd.unit=rescue.target
# Append systemd.unit=rescue.target to the end of the linux line
# This parameter tells systemd to stop at rescue.target instead of graphical.target
# The change is temporary and applies only to this boot session
# Do not remove the 'ro' or 'quiet' flags unless you have a specific reason to debug the kernel
Press Ctrl+x or F10 to boot with the modified parameters. The system will load the kernel and switch to rescue mode. You will see a prompt asking for the root password. Enter the root password to gain access. If you are dropped into a shell, the switch succeeded.
Set the root password before the crisis. A locked root account turns a fixable configuration error into a full media rescue job.
Setting the root password for future recovery
Fedora disables the root account by default. This means the root user has no password set. Rescue mode requires a root password to authenticate. If you never set a root password, the rescue shell will deny access. You must set a password while the system is functional. Run sudo passwd root from a normal terminal. Enter a strong password. This creates the necessary authentication hash. The rescue shell can then verify your identity.
Here is how to enable root login for emergency recovery.
sudo passwd root
# Sets a password for the root account
# Fedora locks the root account by default, which blocks access to rescue mode
# Running this command enables root login for emergency recovery scenarios
# You will be prompted to enter and confirm the new password
Test the password immediately. Run su - to verify you can switch to root before you need it.
Remounting the filesystem and fixing the error
Rescue mode mounts the root filesystem as read-only. This matches the ro kernel parameter and protects the filesystem from accidental damage. You cannot edit configuration files or install packages until you change the mount options. Run mount -o remount,rw / to enable write access. This command updates the mount flags for the root directory. After remounting, standard editors and package managers work normally.
Here is how to enable write access to the root filesystem.
mount -o remount,rw /
# Remounts the root filesystem with read-write permissions
# Rescue mode mounts root as read-only by default to prevent corruption during repair
# Without this step, any attempt to edit files will fail with Permission denied
# Verify the change with mount | grep ' / ' to confirm rw flags are present
Network services do not start in rescue mode. If you need to download packages, bring up the network manually. Use ip link to list interfaces. Use ip link set <interface> up to activate the interface. Use dhclient <interface> to obtain an IP address. NetworkManager is not running, so nmcli may not function. Predictable interface names are used, so check for names like enp3s0 or wlp2s0.
Remount read-write before editing. The filesystem protects you until you explicitly request write access.
Breaking into the initramfs when GRUB rescue fails
If you lost the root password and cannot boot, GRUB rescue mode will not work. The shell will deny authentication. You need rd.break to reset the password. This parameter breaks the boot process inside the initramfs, before the root filesystem is mounted. You can remount root and chroot to reset the password.
Reboot and edit the GRUB entry as before. Instead of systemd.unit=rescue.target, append rd.break to the linux line. Boot with Ctrl+x. You will drop into a shell with a prompt like switch_root:/#. This is the initramfs shell. The root filesystem is mounted at /sysroot. Remount it read-write and chroot into it.
Here is how to reset the root password using rd.break.
mount -o remount,rw /sysroot
# Remounts the root filesystem from within the initramfs
# The root filesystem is mounted at /sysroot in this environment
# Write access is required to modify the password database
chroot /sysroot
# Changes the root directory to the actual system root
# You are now inside the installed system and can run standard commands
passwd root
# Resets the root password
# Enter the new password when prompted
touch /.autorelabel
# Triggers an SELinux relabel on next boot
# Required if SELinux is enforcing to prevent login denial after password change
exit
exit
# Exits the chroot and the initramfs shell
# The system continues booting with the new password
SELinux denials show up in journalctl -t setroubleshoot with a one-line summary. Read those before disabling SELinux. If you reset the password and skip the relabel, SELinux may block login even with the correct password.
Verifying the fix and returning to normal
Once you have repaired the configuration, verify the fix. Check the service status or test the command that failed. If the system is stable, reboot to return to the graphical environment. Run reboot to restart. The system will boot normally because the GRUB changes were temporary. The default target remains graphical.target.
Here is how to confirm the default target and reboot.
systemctl get-default
# Displays the default systemd target
# Output should be graphical.target, confirming the rescue change was temporary
# If the output shows rescue.target, the default was changed permanently and needs correction
reboot
# Restarts the system
# The boot parameters revert to their original values automatically
Reboot before you debug further. Half the time the symptom clears once the filesystem is remounted and the service is restarted.
Common pitfalls and error patterns
Missing root password is the most common blocker. If you see Login incorrect or are dropped back to GRUB, the root account is locked. You cannot proceed without the installation media or rd.break.
Read-only filesystem errors appear when you try to edit files. The error message is Permission denied or Read-only file system. Run the remount command to resolve this.
Boot loops occur if the fix is incomplete. If the system returns to rescue mode after reboot, the error persists. Check the journal for details. Run journalctl -xb to view the boot log. Look for Failed to start or Dependency failed messages. The logs identify the specific service causing the failure.
Config files in /etc/ are user-modified. Files in /usr/lib/ ship with the package. Edit /etc/. Never edit /usr/lib/. Changes in /usr/lib/ are overwritten by package updates and cause drift.
Run journalctl first. Read the actual error before guessing. The log tells you exactly which unit failed and why.
Choosing the right recovery method
Use GRUB rescue mode when you can access the boot menu and need a root shell to fix a config error or broken package. Use the installation media rescue option when the bootloader is corrupted or the kernel itself is broken and you cannot reach the GRUB menu. Use rd.break when you have lost the root password and need to reset it from the initramfs. Use systemctl rescue from a running session when you need to drop to a single-user shell without rebooting the machine. Stay on the graphical target when the system is healthy and you only need to run administrative commands via sudo.
Trust the package manager. Manual file edits drift, snapshots stay. If you are fixing a package conflict, use dnf in rescue mode rather than editing files manually.