The boot spinner that never stops
You power on your machine, the Fedora logo appears, and then nothing happens. The spinner keeps rotating for ten minutes, or the screen freezes on the manufacturer's logo. You are not looking at a crash. The system is waiting for something that will not arrive. This happens after a kernel update, a new GPU driver install, or a sudden power loss. The fix starts by escaping the graphical boot sequence and reading what systemd is actually complaining about.
What is actually happening
The boot logo is just a splash screen. Behind it, systemd is starting services, mounting filesystems, and loading kernel modules. If one service hits a timeout or a dependency fails, systemd pauses the boot process to prevent data corruption. The graphical interface never draws because the display manager is blocked by that stuck service. Think of it like a factory assembly line. One conveyor belt jams. The whole plant stops until someone clears the blockage. Your job is to find the jam, clear it, and restart the line.
Fedora uses a target-based boot sequence. The default target is graphical.target, which pulls in the display manager, network manager, and desktop environment. If any unit in that dependency tree fails to start or hangs, the boot process waits until the timeout expires. The timeout is usually ninety seconds. That is why you see a frozen spinner. The system is not dead. It is politely waiting for a service that has already given up.
Get to a working shell
You need a terminal to read the logs. There are two reliable paths. The first uses GRUB to drop you into a rescue environment before the graphical stack loads. The second switches to a virtual console if the system has partially booted but the display manager never appeared.
Here is how to interrupt GRUB and boot directly into a minimal shell. Hold Shift on legacy BIOS systems or tap Esc repeatedly on UEFI systems during the early boot phase. When the GRUB menu appears, highlight the latest Fedora entry and press e. Find the line starting with linux. Move to the end of that line and append systemd.unit=rescue.target. Press Ctrl+X to boot.
# Interrupt GRUB and append the rescue target parameter
# systemd.unit=rescue.target bypasses the graphical stack
# The system drops you to a root shell with minimal services
# Press Ctrl+X to continue booting with the modified parameters
If the system appears to boot but hangs at the spinner, switch to a virtual terminal instead. Press Ctrl+Alt+F2. You will see a login prompt. Enter your username and password. You now have a working shell on a partially booted system.
# Switch to virtual console 2 to escape the frozen display manager
# Log in with your regular user credentials
# Use sudo for commands that require root privileges
# Return to the graphical session later with Ctrl+Alt+F1 or F7
Reboot before you debug. Half the time the symptom is gone.
Find the stuck service
Once you have a shell, stop guessing and read the logs. The systemd journal stores every boot message. You want to see errors and timeouts from the current boot session. Run the journal command with the explanatory and end flags. This adds context to each line and jumps straight to the most recent entries.
# Show error-level messages from the current boot
# The -b flag filters to the current boot session
# The -p err flag limits output to error and critical levels
# Pipe to less for scrolling if the output is long
Scan the output for lines containing Failed, Timeout, or dependency failed. Those lines point directly to the unit that broke the boot chain. If the journal output is too noisy, check which jobs systemd is still trying to run.
# List all jobs currently in the systemd queue
# Active jobs show units that are starting, stopping, or waiting
# A stuck unit will remain in the starting state indefinitely
# Note the unit name for the next troubleshooting step
Check the unit status before you restart anything. The status command shows recent log lines, the current state, and dependency information in one view. Always verify the state before forcing a restart.
# Show detailed status for the problematic unit
# Replace stuck-service.service with the actual unit name
# The output shows active state, substate, and recent journal lines
# Look for the specific error message that caused the failure
Run journalctl first. Read the actual error before guessing.
Apply the fix
The solution depends entirely on what the logs reveal. Most boot hangs fall into three categories. A kernel module fails to load. A filesystem check is waiting for user input. A network or desktop service is timing out. Address each case with the correct tool.
If a kernel module is causing the hang, blacklist it temporarily. This tells the kernel to ignore the module during boot. Create a configuration file in the modprobe directory. Files in /etc/ are user-modified. Files in /usr/lib/ ship with the package. Always edit /etc/. Never edit /usr/lib/.
# Create a temporary blacklist file for the problematic module
# Replace bad-module with the actual kernel module name
# The blacklist directive prevents modprobe from loading it
# This change persists across reboots until you remove the file
If the journal shows a filesystem check waiting for confirmation, you need to run fsck manually. A corrupted filesystem can block the boot process if the automatic check requires user input. Run the check on an unmounted partition. From rescue mode, the root filesystem is usually mounted read-only. Remount it as read-write first if you are checking a non-root partition, or boot from a live USB if you need to check the root partition itself.
# Remount the root filesystem as read-write if needed
# The -o remount,rw flag changes mount options without unmounting
# This allows you to write to the filesystem from rescue mode
# Only run fsck on unmounted partitions to avoid data corruption
If a network service like NetworkManager-wait-online.service is timing out, disable it. This service waits for a network connection before proceeding, which hangs the boot if the cable is unplugged or the Wi-Fi fails. Disable it to let the system boot without waiting.
# Disable the network wait service to prevent boot timeouts
# The --now flag stops the service immediately and disables it
# This allows the boot sequence to continue past the network stage
# Re-enable it later if you require network availability at boot
If a kernel update caused the regression, boot the previous kernel from the GRUB menu. The older entry sits directly below the latest one. If the older kernel boots cleanly, report the regression to the Fedora bug tracker with your journal logs.
Snapshot the system before the upgrade. Future-you will thank you.
Verify the boot
After applying the fix, restart the machine. Use the systemctl reboot command to ensure a clean shutdown and startup sequence.
# Reboot the system to test the applied fix
# The systemctl command handles service shutdown gracefully
# This ensures all pending writes are flushed to disk
# The system will restart using the modified configuration
Once the system boots, check the journal again. Run the same error filter to confirm the previous failure is gone. If the system boots cleanly, refine or remove any temporary workarounds. Keep a blacklist file only if the hardware genuinely conflicts with the current kernel. Remove it once a driver update resolves the issue.
Trust the package manager. Manual file edits drift, snapshots stay.
Common pitfalls
Running fsck on a mounted filesystem will corrupt data. Always verify the mount status with mount or findmnt before touching disk utilities. Editing configuration files in /usr/lib/ will be overwritten on the next package update. Always place custom configurations in /etc/. Disabling critical services like systemd-journald or systemd-logind will break the session entirely. Only disable services that the journal explicitly identifies as blocking the boot. Ignoring SELinux denials will cause recurring failures. SELinux denials show up in journalctl -t setroubleshoot with a one-line summary. Read those before disabling SELinux.
When to use this approach
Use GRUB rescue mode when the graphical stack never loads and you need a clean root shell. Use virtual console switching when the system partially boots but the display manager freezes. Use journalctl filtering when you need to isolate the exact unit causing the timeout. Use temporary blacklisting when a kernel module conflicts with your hardware. Use service disabling when a non-critical daemon blocks the boot sequence. Use the previous kernel entry when a recent update introduced a regression. Stay on the current kernel if the issue resolves after a simple reboot or driver reload.