Story / scenario opener
You reboot after a dnf upgrade or a driver install. The GRUB menu vanishes. The screen goes black. The cursor might blink, or nothing happens. You hear the fan spin up, but no desktop appears. You are locked out of your graphical session. This happens. It usually means the display manager failed to start, crashed, or is missing. You can fix this from the command line.
What's actually happening
Fedora uses a display manager to hand you off from the kernel to your desktop environment. On Workstation, that is GDM. GDM handles authentication and starts the session. If GDM is broken, the system boots fine. The kernel is running. The network is up. Services are active. The graphical layer just never launches.
Think of it like a house where the plumbing and electricity work, but the front door is welded shut. You can't get in. The black screen is the result of the kernel handing control to a process that either doesn't exist or crashes immediately. The system is alive. You just need to talk to it.
Check the logs. Guessing is slower than reading.
Accessing the terminal
The graphical session is gone, but the kernel still manages virtual terminals. These are text-based consoles running in the background. You can switch to them with keyboard shortcuts.
Press Ctrl+Alt+F3. This switches to virtual terminal 3. F3, F4, F5, and F6 are usually available. F1 and F2 are often reserved for the graphical session. If you see a login prompt, you are in.
If F3 is also black, try F4, F5, or F6. If all terminals are black, the kernel might be stuck or the display driver is completely unresponsive. That requires a different recovery path. This article assumes the kernel is alive and a TTY is accessible.
Type your username and press Enter. Type your password and press Enter. The cursor won't show characters as you type the password. This is normal security behavior. You are now logged in as your user.
Run sudo su - to get a root shell if the commands require elevated privileges. Some operations need root access.
Diagnose the failure
Do not reinstall packages yet. Check the state of the service first. This tells you if GDM is missing, failed, or inactive.
systemctl status gdm
# WHY: Shows the current state of the GDM service. Look for the "Active:" line.
If the output shows Active: active (running), GDM is running but the session might be crashing. Check the user session logs. If it shows Active: failed, GDM tried to start and crashed. If it shows Active: inactive, the service is not enabled or not started.
When the service is failed, the logs contain the root cause. Use journalctl to inspect the output.
journalctl -xeu gdm
# WHY: -x adds explanatory hints, -e jumps to the end, -u filters for the gdm unit.
Look for error lines. Common patterns include Failed to start GNOME Display Manager, segfaults related to graphics drivers, or SELinux denials. The error message points to the fix.
Run journalctl first. Read the actual error before guessing.
Fix 1: Reinstall GDM and session components
Package updates can sometimes leave files in a corrupted state. A partial download or a disk error during upgrade can remove critical binaries. Reinstalling forces dnf to verify and replace files without changing your configuration.
sudo dnf reinstall gdm gnome-session gnome-shell -y
# WHY: Reinstalls the core display manager and session packages. Fixes missing binaries or corrupted libraries.
sudo systemctl enable gdm
# WHY: Ensures the GDM service starts on boot. Creates the symlink in the graphical target directory.
sudo reboot
# WHY: Restarts the system to apply changes and launch the display manager.
If the reinstall succeeds and the system reboots, the desktop should appear. If not, proceed to the next checks.
Trust the package manager. Manual file edits drift, snapshots stay.
Fix 2: NVIDIA driver and kernel parameters
Proprietary NVIDIA drivers are a common cause of black screens. The kernel must load the NVIDIA module and enable DRM modesetting for GDM to communicate with the GPU. If the module fails to load or modesetting is disabled, GDM cannot set the display mode and the screen stays black.
Check the kernel ring buffer for NVIDIA errors.
dmesg | grep -i nvidia
# WHY: Searches the kernel log for messages related to the NVIDIA driver.
If you see errors like NVRM: Xid or module load failures, the driver is the issue. Ensure the kernel parameter nvidia-drm.modeset=1 is set. This parameter tells the kernel to use the NVIDIA driver for display modesetting.
Use grubby to update the kernel arguments. Never edit grub.cfg manually. grubby manages the configuration safely.
sudo grubby --update-kernel=ALL --args="nvidia-drm.modeset=1"
# WHY: Adds the modesetting parameter to all installed kernels. Enables DRM support for NVIDIA.
sudo reboot
# WHY: Reboots to apply the new kernel parameters.
If you previously added nomodeset to debug a different issue, remove it. nomodeset disables hardware acceleration and breaks GDM.
sudo grubby --update-kernel=ALL --remove-args="nomodeset"
# WHY: Removes the nomodeset flag that disables hardware graphics acceleration.
sudo reboot
# WHY: Restarts the system with hardware acceleration enabled.
Reboot before you debug. Half the time the symptom is gone.
Fix 3: SELinux context restoration
SELinux protects system files by enforcing security contexts. If you copied files manually or modified permissions incorrectly, SELinux might block GDM from accessing its configuration or libraries. This results in a silent failure or a denial in the logs.
Check for SELinux denials related to GDM.
journalctl -t setroubleshoot
# WHY: Shows SELinux denial summaries. Look for messages mentioning gdm or gnome-shell.
If you see denials, restore the default contexts for the GDM configuration directory.
sudo restorecon -Rv /etc/gdm
# WHY: Resets SELinux contexts on GDM config files to their defaults. Fixes permission denials.
sudo systemctl restart gdm
# WHY: Restarts the display manager to pick up the corrected contexts.
If targeted fixes fail and you suspect widespread context corruption, force a full relabel. This takes time but resolves deep issues.
sudo touch /.autorelabel
# WHY: Creates a flag file that triggers a full filesystem relabel on the next boot.
sudo reboot
# WHY: Restarts the system. The relabel process runs before the desktop starts. Wait for it to finish.
The relabel process can take several minutes. The screen may stay black during this time. Do not interrupt the reboot.
Fix 4: Disable Wayland fallback
GDM defaults to Wayland. Some hardware configurations or driver versions do not support Wayland reliably. If GDM starts but the session crashes immediately, forcing Xorg can restore access.
Edit the GDM configuration file.
sudo nano /etc/gdm/custom.conf
# WHY: Opens the GDM configuration file for editing.
Find the line #WaylandEnable=false and remove the # to uncomment it. Save and exit.
[daemon]
WaylandEnable=false
# WHY: Disables Wayland sessions. Forces GDM to use the Xorg display server instead.
Restart GDM to apply the change.
sudo systemctl restart gdm
# WHY: Restarts the display manager. The next login attempt will use Xorg.
If the desktop appears, your hardware or driver combination requires Xorg. You can keep this setting or investigate Wayland compatibility later.
Verify the fix
Once the desktop appears, verify the service state to ensure the fix is stable.
systemctl is-active gdm
# WHY: Returns "active" if the service is running. Confirms GDM is healthy.
loginctl list-sessions
# WHY: Lists active user sessions. You should see your user ID and session type.
If the output shows active and your session is listed, the system is stable. Check the logs one last time to ensure no errors are recurring.
journalctl -u gdm --since "10 minutes ago"
# WHY: Shows recent GDM logs. Confirms no new errors appeared after the fix.
Common pitfalls and what the error looks like
- Xorg vs Wayland confusion: GDM manages the session type. If you force Xorg in
custom.conf, GDM still runs. The session backend changes. Do not confuse GDM with the session server. - Config drift in
/usr/lib: Configuration files in/usr/libship with packages. Do not edit them. Changes are overwritten on update. Edit files in/etc. Fedora follows the convention that/etcis for user modifications. - Corrupted user config: Sometimes a bad setting in
~/.configcrashes the session. If GDM starts but you get a black screen immediately after login, rename the config directory to test.
Reboot and log in. If it works, restore files from the backup one by one to find the culprit.mv ~/.config ~/.config.bak # WHY: Moves user config to test if a bad setting is crashing the session. dnf upgradevsdnf system-upgrade: Runningdnf upgradeonly updates packages within the current release. It does not cross major version boundaries. If you are on Fedora 40 and want Fedora 42, you must usednf system-upgrade. Mixing these commands can cause dependency hell and break the display stack.- Firewall reload: If you changed firewall rules to debug network issues, remember to reload.
firewall-cmd --reloadapplies runtime changes. Without it, the persistent config and runtime config diverge.
When to use this vs alternatives
Use Ctrl+Alt+F3 when the system is running but the display manager is unresponsive. Use sudo dnf reinstall gdm when packages are corrupted or files are missing. Use sudo grubby --args="nvidia-drm.modeset=1" when you have NVIDIA hardware and the screen stays black after a driver install. Use sudo touch /.autorelabel when SELinux denials are blocking GDM and targeted fixes fail. Use Rescue Mode when you cannot access a TTY or have forgotten your password. Stay on the default Wayland session if your hardware supports it and you want better input handling and security.