Fedora 37 - Can't Start with Graphical Screen, but Works After Logging in

Hello! I’m running a Fedora 37 server system (been upgrading since ~F20) as a VMware guest. I’ve always been straight command-line, but have been wanting to play around with going the graphical route and also installed the Cinnamon desktop. I’m stuck trying to figure out - after enabling the system to boot as graphical.target (systemctl set-default graphical.target) I’m getting the dreaded and feared “Oh No! Something has gone wrong!” screen. I can still SSH into the machine, reset it back to multi-user.target screen and things will boot up normally. Also, weirdly enough, I can boot multi-user, log in normally from the console, and then “startx” will successfully start Xorg/gnome/cinnamon. I’ve played around with a few settings like disabling wayland, etc., but I’m frankly really confused with where to even look to find what might be failing while booting but works once I’m logged in.

If this is part of the the issue, the GDM is enabled/starts, and the config file is:

[Unit]
Description=GNOME Display Manager

# replaces the getty
Conflicts=getty@tty1.service
After=getty@tty1.service

# replaces plymouth-quit since it quits plymouth on its own
Conflicts=plymouth-quit.service
After=plymouth-quit.service

# Needs all the dependencies of the services it's replacing
# pulled from getty@.service and plymouth-quit.service
# (except for plymouth-quit-wait.service since it waits until
# plymouth is quit, which we do)
After=rc-local.service plymouth-start.service systemd-user-sessions.service

# GDM takes responsibility for stopping plymouth, so if it fails
# for any reason, make sure plymouth still stops
OnFailure=plymouth-quit.service

[Service]
ExecStart=/usr/sbin/gdm
KillMode=mixed
Restart=always
IgnoreSIGPIPE=no
BusName=org.gnome.DisplayManager
EnvironmentFile=-/etc/locale.conf
ExecReload=/bin/kill -SIGHUP $MAINPID
KeyringMode=shared

[Install]
Alias=display-manager.service

Any thoughts? TYIA

The server is not intended to have a graphical desktop and as such does not have all the underlying parts initially installed. For graphical I would suggest either the workstation release or one of the many spins with different desktops. The cinnamon spin is one of those.

That said you could try installing the entire cinnamon desktop group with
dnf group install 'Cinnamon Desktop'. Theoretically it should pull in everything needed, but possibly not.

I just tested on a VM with installing the F37 server edition from the server dvd iso. I then did a full update to latest, followed by a reboot. I then did the group install noted above and set the graphical target as you stated. The cinnamon desktop group installed about 920 additional packages.

A reboot brought up the cinnamon desktop graphical. I am not sure what you may have done differently but this procedure worked for me on a clean new server install.

Oh, I am not using vmware, but qemu/kvm on a fedora 37 host.

I’d check for the base-x package first.

$ sudo dnf install @base-x

And hardware drivers.

$ sudo dnf install mesa-dri-drivers mesa-vulkan-drivers

You could also switch to lightdm.

$ sudo dnf install lightdm-gtk lightdm-gtk-settings
$ sudo systemctl disable --now gdm.service
$ sudo systemctl enable --now lightdm.service

Are you on Intel hardware? If so, look at /etc/default/grub. You can enable or disable early boot modesetting.

$ man grubby
$ cat /etc/default/grub
$ sudo grubby --remove-args="nomodeset" --update-kernel=ALL
$ sudo grubby --args="i915.modeset=1" --update-kernel=ALL
$ cat /etc/default/grub
$ systemctl reboot

And as a last resort…

$ dnf grouplist
$ dnf groupinfo "Cinnamon Desktop"
$ sudo dnf groupinstall "Cinnamon Desktop"

Thank you for all the suggestions, but unfortunately still no luck. Here’s what I’ve done to troubleshoot the problem since then.

  • Did a dnf group remove for Cinnamon Desktop and Gnome, and even the base-x package (since I’ve been upgrading this system since early Fedora versions). Rebooted. Did a dnf group install of Cinnamon Desktop. No luck, so (if perhaps it needed some Gnome components) I did a dnf group install for Gnome Basic Desktop, and that didn’t work either (I now get the “Oh No” screen and can only log out), but I’m noW getting a ton of messages in /var/log/messages that maybe provides some indicators - maybe some clues here?
Feb 19 01:36:37 zulu gnome-session[4494]: gnome-session-binary[4494]: WARNING: Failed to upload environment to systemd: GDBus.Error:org.freedesktop.DBus.Error.NameHasNoOwner: Name "org.freedesktop.systemd1" does not exist
Feb 19 01:36:37 zulu gnome-session-binary[4494]: WARNING: Failed to upload environment to systemd: GDBus.Error:org.freedesktop.DBus.Error.NameHasNoOwner: Name "org.freedesktop.systemd1" does not exist
Feb 19 01:36:37 zulu gnome-session[4494]: gnome-session-binary[4494]: WARNING: Failed to reset failed state of units: GDBus.Error:org.freedesktop.DBus.Error.NameHasNoOwner: Name "org.freedesktop.systemd1" does not exist
Feb 19 01:36:37 zulu gnome-session-binary[4494]: WARNING: Failed to reset failed state of units: GDBus.Error:org.freedesktop.DBus.Error.NameHasNoOwner: Name "org.freedesktop.systemd1" does not exist
Feb 19 01:36:37 zulu gnome-session[4494]: gnome-session-binary[4494]: WARNING: Falling back to non-systemd startup procedure due to error: GDBus.Error:org.freedesktop.DBus.Error.NameHasNoOwner: Name "org.freedesktop.systemd1" does not exist
Feb 19 01:36:37 zulu gnome-session-binary[4494]: WARNING: Falling back to non-systemd startup procedure due to error: GDBus.Error:org.freedesktop.DBus.Error.NameHasNoOwner: Name "org.freedesktop.systemd1" does not exist
Feb 19 01:36:37 zulu gnome-session[4494]: gnome-session-binary[4494]: WARNING: Could not get session id for session. Check that logind is properly installed and pam_systemd is getting used at login.

Also perhaps something about failing around my sound setup (I don’t know if this a show-stopper thing) in there like:

Feb 19 01:36:42 zulu org.gnome.SettingsDaemon.Sound.desktop[4897]: /usr/libexec/gsd-sound: symbol lookup error: /lib64/libsndfile.so.1: undefined symbol: lame_encode_buffer_interleaved_int
Feb 19 01:36:42 zulu gnome-session-binary[4494]: Unrecoverable failure in required component org.gnome.SettingsDaemon.MediaKeys.desktop

This is a TON of messages, and I’m getting lost trying to find any kind of root cause. Any thoughts?

Full /var/log/messages activity while trying to startx: https://pastebin.com/mkMJ90y6

FPaste Output: https://pastebin.com/AK8xXtc9

Maybe try adding metacity. Or see if gnome-flashback can create a graphical session.

Finally figured it out! Turns out this was the culprit:

Feb 19 01:36:42 zulu org.gnome.SettingsDaemon.Sound.desktop[4897]: /usr/libexec/gsd-sound: symbol lookup error: /lib64/libsndfile.so.1: undefined symbol: lame_encode_buffer_interleaved_int
Feb 19 01:36:42 zulu gnome-session-binary[4494]: Unrecoverable failure in required component org.gnome.SettingsDaemon.MediaKeys.desktop

First, I noticed ffmpeg was broken, even if I removed all traces of it and reinstalled, I’d get this error:

[root@zulu ~]# ffmpeg --version
ffmpeg: symbol lookup error: /lib64/libsndfile.so.1: undefined symbol: lame_encode_buffer_interleaved_int

That “lame_encode_buffer_interleaved_int” error led me to seeing if lame itself was working, but no luck:

[root@zulu ~]# lame
lame: symbol lookup error: lame: undefined symbol: lame_get_maximum_number_of_samples

Even DNF removing lame and reinstalling it didn’t correct that error. So, as part of my troubleshooting, I’d spun up another VM of spanking-new Fedora Server and installed KDE on it (which worked perfectly). Comparing the working vs. non-working systems, I found a few files on my broken system in /usr/lib that weren’t on my sparkly new working system, going all the way back to 2014 (!!!) and moved those to a safe corner of my system:

[root@zulu lib]# ls -la libmp3*
-rwxr-xr-x. 1 root root    925 Jan 23  2014 libmp3lame.la
lrwxrwxrwx. 1 root root     19 Jan 23  2014 libmp3lame.so -> libmp3lame.so.0.0.0
lrwxrwxrwx. 1 root root     19 Jan 23  2014 libmp3lame.so.0 -> libmp3lame.so.0.0.0
-rwxr-xr-x  1 root root 423727 Jan 23  2014 libmp3lame.so.0.0.0

Once I moved those, all of a sudden both lame and ffmpeg worked, and my KDE instance fired up immediately. My lessons learned:

  1. You can get libsndfile library (libsndfile.so.1) and ffmpeg errors if lame isn’t working.
  2. Both Gnome and KDE require lame (and potentially ffmpeg) as a dependancy.
  3. I’ve been running this damn system since Fedora 19 back in 2013!!!
  4. You can’t just upgrade your server over time without cleaning up a lot of depreciated stuff; I had several hundred packages on this system and a ton of services that weren’t in use any longer. I’ve apparently been an unknowing candidate for the computer nerd version of the Hoarders TV show. :rofl: