(URGENT) Fedora 36 dnf update - no GUI after login


I’ve been using fedora 36 workstation for a while, with now issue.

I just ran dnf update -y and now when I reboot, I get no GUI after I login (login screen GUI is working still)

Any ideas why or how to fix?

Things I’ve tried so far that didn’t work:

  • Booting from a different kernel version
  • Disabling SELINUX
  • Trying to run timeshift --restore (got failed to mount errors)
  • Regenerating itramfs dracut --regenerate-all --force

System info:

Dell Inspiron 14 5000 laptop with intel iRIS xe graphics.


(Marked as ‘URGENT’ because this is my work laptop and need help to fix asap)

What do you mean you get no gui?
Is the screen blank or black?
Does it fail over to a tty?
What actually happens?

You could boot to a terminal, and log in then use startx to launch the gui.
You could possibly, after logging in and not getting the gui, use ctrl-alt-F[3456] to get the tty login screen and log in then try startx to see if the gui will launch.

It’s just a blank black screen (with a mouse cursor that’s frozen) and it stays like that forever.

As a temporary work around - Yes this works. Thank you!

However, the follow up quesiton is: How do I permanently fix this? I’d hate to have to open the tty each time and type startx. plus this is just a workaround a some of my GNOME settings are not present as the echo $XDG_SESSION_TYPE shows tty and not wayland

I’m guessing some configuration to start this program on login has been overwritten in the update.

From time to time, for no apparent reason, this very same thing happens with SDDM, the login manager used by the KDE spin, and Kinote, the Silverblue KDE spin.

What fixes its weird behavior is to disable → restart → enable the service (i haven’t dug yet to understand why this happens).

Since you’re running Fedora, I believe the login manager for GNOME is GDM, so in your case you might want to try:

(Switch to a text TTY and log in as you do to gain a shell)

$ sudo systemctl disable gdm.service
$ sudo systemctl restart gdm.service

With any luck after a few seconds you should be greeted by the login manager. Be warned that if you were running any GUI session already, it will probably end abruptly, so save any ongoing work and end the session before trying to restart the login manager.

To re-enable GDM to automatically run at boot as you would expect:

$ sudo systemctl enable gdm.service

Let us know how it goes.

1 Like

Can you try simply stopping the service then starting it? I can’t see the point of disabling then enabling the service.

According to the man page, a restart is different than a stop+start.

Yes, this temporarily works, however, after rebooting the machine, the issue still occurs.

For e.g. (steps),

  • Turn on machine, enter LUKS password for decryption
  • In login screen, press ctrl + alt + f2 to open the tty
  • login with normal user credentials to tty
  • run $ sudo systemctl disable --now gdm.service
  • run $ sudo systemctl enable --now gdm.service
  • system transitions over to the GUI which has all my settings back to normal
  • restart the machine, and login (no TTY) and the screen goes back to black.

So this solution doesn’t persist unfortunately :cry:

Update Debug Logs:

Here are some of the journalctl -u gdm.service messages after rebooting the machine

Assuming you didn’t make any changes to your system that could brake GDM, this must be a bug and it would be great if you can fill a report; you can try journalctl -xeu gdm.service to check for any other clues, and grab meaningful information for your bug report .

Have you searched for that error message to see what brings up?

I found two posts that might be of help:



If the issue is a race condition as mentioned in the first post, it would make sense then that after you manually restart the login manager it work as expected…