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)
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:
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?
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…