You upgraded and the screen went black
You run sudo dnf upgrade --refresh, the terminal scrolls through package downloads, and you reboot. The screen stays black. The cursor blinks once and stops. Or you see a wall of text scrolling by and land on a login prompt instead of the GNOME desktop. Panic sets in. You need that machine. This is a common failure mode after a kernel update or a graphics driver change. The system is likely running, but the display server cannot initialize.
The kernel is usually loaded. Network services are probably active. The display subsystem is the bottleneck. Fedora separates the core system from the graphical interface so that a broken driver does not kill the whole machine. That design saves you here. You can recover the system without a reinstall.
Run journalctl -xe before you guess. The logs tell you whether the kernel rejected the driver, GDM crashed, or the system fell back to a safe mode. Read the actual error before forcing a fix.
What is actually happening
Fedora boots through a chain of components. GRUB loads the kernel. The kernel mounts the root filesystem and starts systemd. Systemd reaches multi-user.target, which brings up network, storage, and background services. Then systemd pulls in graphical.target. That target starts the display manager, GDM. GDM negotiates with the graphics stack to start the session.
If the kernel update changes how the GPU is initialized, the driver may fail to load. If a driver package conflicts with the new kernel, the module build fails. If GDM cannot talk to the graphics stack, it exits. You get a black screen because nothing is drawing pixels. Sometimes the system falls back to a TTY login because the graphical target cannot be reached.
Think of it like a theater. The kernel is the building. The driver is the stage crew. GDM is the director. If the crew is missing or the equipment is broken, the director has nothing to direct. The show does not start. The building is still standing. You just need to fix the crew or the equipment.
Check multi-user.target first. If that is inactive, the display manager is not the problem.
Diagnose before you fix
Switch to a text terminal to bypass the broken display server. Press Ctrl+Alt+F3. If that fails, try F4 through F6. Log in with your username and password. You are now in a TTY. The graphical session is not running, but the system is alive.
Here is how to check whether the display manager is active and see the recent error lines.
# Check the status of the display manager.
# GDM is the default on Fedora Workstation.
# This shows the current state and the last few log lines.
systemctl status gdm.service
# Review the journal with explanatory text and jump to the end.
# The x flag adds context. The e flag goes to the end.
# Look for lines marked with "Failed" or "Error".
journalctl -xe
If systemctl status gdm.service returns active, the display manager is running but the session might be failing. If it returns failed or inactive, GDM crashed or never started. The journal output points to the cause.
Run systemctl status before you restart. Restarting a service that is failing due to a missing dependency just wastes time.
Fix the partial update
A black screen often appears after a partial update. The repo metadata got out of sync, or the transaction was interrupted. The system has a mix of old and new packages. Dependencies are broken. The kernel and driver versions do not match.
Here is how to refresh the metadata and apply all pending updates.
# Refresh the metadata cache and apply all pending updates.
# A partial update often causes the black screen.
# --refresh forces dnf to download fresh repo data.
sudo dnf upgrade --refresh
# Reboot to load the new kernel and drivers.
# The update may have fixed the conflict.
sudo reboot
dnf upgrade --refresh is the normal weekly maintenance command. It ensures the package database is current and pulls in all updates. dnf system-upgrade is for crossing major Fedora releases. They are different commands. Do not conflate them.
Reboot before you debug. Half the time the symptom is gone.
Restart the display manager
Sometimes GDM crashes due to a transient error. A configuration file has a syntax error. A plugin failed to load. The kernel is fine. The drivers are fine. GDM just needs a fresh start.
Here is how to restart the display manager and verify it comes back.
# Restart the display manager to apply changes.
# This will log out all graphical sessions.
sudo systemctl restart gdm.service
# Confirm the service is running and not in a failed state.
# This returns "active" if the restart succeeded.
systemctl is-active gdm.service
If the restart fails, check the logs again. The error might be persistent. A crash loop indicates a deeper issue.
Restart GDM before you reboot. If the service comes back, the kernel is fine and the fix is immediate.
Fix proprietary graphics drivers
Proprietary drivers often break on kernel updates. The driver must compile a kernel module for the new kernel. If the build fails, the module is missing. The GPU falls back to a basic driver or nothing. The screen goes black.
Fedora uses akmod packages for NVIDIA drivers. akmod builds the module during boot if the kernel headers are present. If headers are missing, the build fails.
Here is how to check if the NVIDIA module is loaded and rebuild it if necessary.
# Check if the NVIDIA kernel module is loaded.
# lsmod lists currently loaded modules.
# If nvidia is missing, the driver failed to load.
lsmod | grep nvidia
# Verify kernel headers are installed.
# The build process fails without headers matching the running kernel.
rpm -q kernel-devel kernel-headers
# Reinstall the akmod package to trigger a rebuild.
# This downloads the package and runs the build script.
sudo dnf reinstall akmod-nvidia
If akmod fails, check the build log. The log shows why the compilation failed. Missing headers are the most common cause. Install kernel-devel and kernel-headers matching the running kernel.
Rebuild the module before you reinstall. akmod can fix itself if headers are present.
Fallback to Xorg
Fedora defaults to Wayland. Some hardware or driver combinations do not support Wayland well. GDM might fail to start a Wayland session. Switching to Xorg can restore the desktop.
Here is how to force GDM to use Xorg instead of Wayland.
# /etc/gdm/custom.conf
# Uncomment to force Xorg instead of Wayland.
# This helps if the GPU driver does not support Wayland.
[daemon]
WaylandEnable=false
Edit /etc/gdm/custom.conf, not the package files. Config files in /etc/ are user-modified. Files in /usr/lib/ ship with the package. Edit /etc/. Never edit /usr/lib/. Package updates overwrite /usr/lib/.
Restart GDM after the change. The session will start using Xorg.
Edit /etc/ only. Manual file edits drift, snapshots stay.
Recovery when TTY is unavailable
If Ctrl+Alt+F3 does not work, the TTY might be disabled or the system is stuck earlier in the boot process. You can edit the GRUB menu to boot into a TTY directly.
Reboot the machine. When the GRUB menu appears, press e to edit the boot entry. Find the line starting with linux. Add systemd.unit=multi-user.target to the end of that line. Press Ctrl+X to boot. The system will start in multi-user mode without the GUI. You get a login prompt.
Here is how to verify the target and fix the issue from the recovery boot.
# List the current default target.
# graphical.target pulls in multi-user.target.
systemctl get-default
# Check if the system reached multi-user.target.
# This confirms systemd is running even if the GUI is dead.
systemctl is-active multi-user.target
# Set the default target back to graphical after fixing the issue.
# This tells systemd to start the GUI on the next boot.
sudo systemctl set-default graphical.target
Fix the issue using the commands above. Reboot normally. Remove the systemd.unit=multi-user.target parameter from GRUB if you added it permanently.
If the boot menu is gone, GRUB rescue is your friend, not your enemy.
Common pitfalls and errors
You might see Error: Transaction test error: package python3-3.12.x conflicts with python3-3.13.y. The conflict is intentional. Read the next paragraph before forcing. The package manager is protecting you from a broken state. Resolve the conflict by upgrading all packages or removing the conflicting package.
You might see Failed to start gdm.service: Unit gdm.service is masked. A masked unit cannot be started. Unmask it with sudo systemctl unmask gdm.service. Masking is usually done by a script or a user. Check why it was masked.
SELinux denials show up in journalctl -t setroubleshoot with a one-line summary. Read those before disabling SELinux. A black screen is rarely SELinux, but a denied GDM transition can cause it. Fix the policy or restore contexts. Do not disable SELinux as a first step.
# Example error from journalctl when GDM cannot start.
# This usually indicates a configuration error or missing dependency.
gdm.service: Main process exited, code=exited, status=1/FAILURE
gdm.service: Failed with result 'exit-code'.
Trust the package manager. Manual file edits drift, snapshots stay.
When to use this versus alternatives
Use sudo dnf upgrade --refresh when the black screen appeared after a partial update or repo sync issue. Use sudo systemctl restart gdm when the system is running but the display manager crashed due to a transient error. Use sudo dnf reinstall akmod-nvidia when you have proprietary graphics and the kernel module failed to build. Use sudo dracut --regenerate-all --force when the initramfs is corrupted and the system cannot mount the root filesystem. Use a Live USB and chroot when you cannot access a TTY and the system is unbootable. Stay on the default GNOME stack if you do not need a specific window manager. Switch to a TTY permanently only when you are running a headless server.
Test the fix in a VM if you have one. A broken boot on a remote machine is a recovery nightmare.