The black screen after login
You type your password at the GDM login screen. The cursor spins for a second, then the screen goes black. You can hear the system humming, but there is no desktop, no wallpaper, and not even a mouse cursor. You are stuck. This happens after a dnf upgrade, a kernel update, or sometimes for no obvious reason. The system is running, but the graphical session failed to start.
What is actually happening
Think of the login process as a relay race. GDM is the first runner. It authenticates you and passes the baton to the display server, which then hands it to your desktop environment. A black screen means the baton dropped somewhere between GDM and the desktop. The system is running, but nothing is drawing pixels to the screen.
The failure usually stems from one of three areas. The graphics driver crashed during initialization. A user configuration file is corrupted and causes the desktop environment to abort. Or a startup script is hanging and preventing the session from completing. Fedora updates the kernel weekly. When the kernel changes, kernel modules must be rebuilt to match. If that rebuild fails, the driver stops working and the display server cannot initialize the GPU.
Run journalctl first. Read the actual error before guessing.
Get to a terminal
When the GUI is broken, you need a text console to diagnose and fix the issue. Fedora provides multiple virtual terminals that run independently of the graphical session.
Here is how to escape the black screen and get a command line.
# Switch to TTY3 to access a text console
# The GUI is broken, so keyboard shortcuts are your only way in
# Press Ctrl+Alt+F3 to switch
# You will see a login prompt on a black screen with text
Log in with your username and password. The password will not show as you type. Press Enter. You now have a root-capable shell to investigate the problem.
Convention aside: Ctrl+Alt+F3 through Ctrl+Alt+F6 are available TTYs. Ctrl+Alt+F1 or Ctrl+Alt+F2 usually returns to the graphical session. If the GUI is broken, switching back will just show the black screen again.
Check the logs
The logs tell you exactly why the session failed. GDM logs its activity to the journal. You can filter the journal to see only GDM messages and get explanatory text for common errors.
Here is how to check the logs for the specific failure reason.
# Check GDM logs for the specific failure reason
# -x adds explanatory text to help interpret errors
# -u filters the output to only show the gdm unit
journalctl -xeu gdm
Look for lines marked (EE) or Error. These indicate the point of failure. Common errors include driver initialization failures, permission denials, or missing configuration schemas.
If you see Failed to start GNOME Display Manager, GDM itself is not running. If you see gnome-shell: GLib-GIO-ERROR, the desktop environment crashed after GDM started. The distinction matters. GDM failures often point to system-level issues. GNOME shell failures often point to user configuration or extension problems.
Fix the session configuration
Corrupted user configuration files are a frequent cause of black screens. The monitor layout file can become invalid after a display change or a crash. When the desktop environment tries to load an invalid layout, it may abort.
Here is how to reset the monitor configuration to force a regeneration.
# Rename the monitor config to force GNOME to regenerate it
# Corrupted monitor layouts often crash the session startup
# The mv command preserves the old file in case you need to restore it
mv ~/.config/monitors.xml ~/.config/monitors.xml.bak
If the issue is caused by a Flatpak application interfering with the session, removing the Flatpak portal cache can help. This is less common but worth checking if the black screen started after installing a Flatpak.
# Remove the Flatpak portal cache if a Flatpak app is causing conflicts
# This forces Flatpak to rebuild its portal connections on next login
rm -rf ~/.local/share/flatpak/exports/share
Restart GDM to test the fix. This brings you back to the login screen without a full reboot.
# Restart GDM to apply configuration changes
# This drops you back to the login screen to test the session
sudo systemctl restart gdm
Restart GDM after config changes. sudo systemctl restart gdm brings you back to the login screen without a full reboot.
Reinstall graphics drivers
If the logs show driver errors, the graphics packages may be corrupted or mismatched with the kernel. Fedora uses mesa-dri-drivers for open-source GPU drivers. A reinstall ensures all files are intact and checksums match.
Here is how to reinstall core graphics packages to replace corrupted files.
# Reinstall core graphics packages to replace corrupted files
# --refresh forces dnf to check for updates before reinstalling
# This ensures you get the latest package metadata from the repos
sudo dnf reinstall --refresh xorg-x11-server-Xorg mesa-dri-drivers
Convention aside: dnf upgrade --refresh is the normal weekly maintenance command. dnf system-upgrade is for crossing major Fedora releases. They are different commands. Use reinstall to fix packages without changing versions. Use upgrade to get new versions.
If you use an NVIDIA GPU, the open-source drivers will not help. You need the proprietary driver packages. The kernel update cycle on Fedora can break NVIDIA modules if akmods fails to rebuild them.
Here is how to check if NVIDIA modules are loaded.
# Check if NVIDIA modules are loaded
# If this returns nothing, the driver failed to load
# lsmod lists all loaded kernel modules
lsmod | grep nvidia
If the modules are missing, reinstall the NVIDIA driver and trigger a rebuild.
# Reinstall NVIDIA drivers and rebuild kernel modules
# akmods rebuilds kernel modules for the current kernel
# This is required after a kernel update on Fedora
sudo dnf reinstall --refresh kmod-nvidia xorg-x11-drv-nvidia
sudo akmods --force
Reboot before you debug. Half the time the symptom is gone after a driver reinstall and reboot.
Check for disk space and startup scripts
A full disk can prevent the session from starting. The desktop environment needs to write temporary files and lock files. If the root partition is full, the session will fail silently.
Here is how to check disk usage across all mounted partitions.
# Check disk usage across all mounted partitions
# Look for usage at 100% on / or /home
# df -h shows sizes in human-readable format
df -h
If the root partition is at 100%, free up space. Remove old package caches or large temporary files.
# Clean the dnf cache to free up disk space
# This removes downloaded package metadata and RPM files
sudo dnf clean all
Startup scripts can also hang the session. A script in ~/.bashrc or ~/.xprofile that waits for input or fails will block the desktop from appearing.
Here is how to temporarily disable custom shell profiles to rule out startup scripts.
# Temporarily disable custom shell profiles to rule out startup scripts
# Rename .bashrc to prevent it from running during login
# This helps isolate whether a user script is causing the hang
mv ~/.bashrc ~/.bashrc.disabled
Test with a clean profile. If the desktop loads, your startup script is the culprit. Restore the file and fix the script.
Switch display servers
Fedora supports both Wayland and X11. Wayland is the default. Some hardware or applications work better on X11. If Wayland is crashing, you can force GDM to use X11.
Here is how to configure GDM to use X11 instead of Wayland.
# /etc/gdm/custom.conf
# Uncomment WaylandEnable=false to force X11 if Wayland is crashing
# Edit this file in /etc, never in /usr/lib
# Config files in /etc are user-modified. Files in /usr/lib ship with the package.
[daemon]
WaylandEnable=false
After editing the file, restart GDM.
# Restart GDM to apply the display server change
# This switches the login screen to X11 mode
sudo systemctl restart gdm
Check the status before you restart. systemctl status shows recent logs and the current state in one view.
Verify the fix
Once you have applied a fix, verify that GDM is running and the session can start. The status command shows the service state and recent log lines.
Here is how to verify GDM is running and accepting connections.
# Verify GDM is running and accepting connections
# Look for "active (running)" in the output
# systemctl status shows state and recent logs in one view
systemctl status gdm
Switch back to the graphical session. If you see the login screen, try logging in. If the desktop appears, the fix worked. If the black screen returns, check the logs again for new errors.
Check the status before you restart. systemctl status shows recent logs and the current state in one view.
Common pitfalls
SELinux denials can block the session. SELinux logs denials with a one-line summary. Read those before disabling SELinux.
# Check for SELinux denials that might block the session
# setroubleshoot provides human-readable summaries of denials
journalctl -t setroubleshoot
If you see denials related to gnome-shell or gdm, restore the file contexts or adjust the policy. Disabling SELinux is a last resort.
The dnf upgrade command will refuse to proceed and print 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. This error indicates a dependency conflict, not a graphics issue. Resolve the conflict before proceeding.
If you see [FAILED] Failed to start NetworkManager.service during boot, your network configuration probably references a missing interface name. This is unrelated to the black screen but can confuse diagnosis. Fix the network config separately.
When to use each approach
Use TTY recovery when the GUI is completely unresponsive and you need immediate access to the system.
Use monitors.xml reset when the black screen started after moving a window or changing display resolution.
Use driver reinstall when the issue appeared immediately after a dnf upgrade or kernel update.
Use NVIDIA module rebuild when lsmod shows no NVIDIA modules and you have a proprietary GPU.
Use disk cleanup when df -h shows the root partition at 100% usage.
Use Wayland fallback to X11 when you see Wayland-specific errors or use hardware that lacks full Wayland support.
Use startup script disable when the session hangs indefinitely without a clear error in the logs.