Usually CTRL+ALT+F1 or F2 will get you back depending on where it is running. In any case you can always restart it with sudo systemctl restart display-manager. No need to reboot
Yes.
bob:x:1000:100:(my full name):/home/bob:/bin/bash
note: I don’t like giving out my full name on the internet. Years ago I wasn’t so careful, angered a bible-pounder, and was internet stalked with doxxing, death threats, and so on. Finally the monster put his full name and city on another blog where a friend spotted it, and the NC state police shut him down.
It wasn’t fun.
All good - it confirms the login shell is valid.
From a VT as root (immediately after a failed login), please show
loginctl list-users
and then
loginctl user-status bob
Does logind see the user at all? Any obvious errors reported?
OK. Got errors.
for list-users
vid user Linger Status
0 root no active
472 gdm no active
2 users listed
for user-status (for my login after failure):
User ID 1000 is not logged in or lingering.
Examine the jouranal journalctl -b -u gdm -e from a VT as root immediately after the failed login.
Done. When I entered the command, I got a whole long (vertical) line of tildes and then this:
localhost system [1]: starting GNOME display manager
localhost system [1]: starting GNOME display manager
localhost gdm-password [2322]: unable to locate daemon control file
localhost gdm-password [2322]: gkr-pam:stashed password to try again in open session
localhost gdm[1675]: GDM: gdmDisplay: session never registered, failing
It acts like something is missing in the login structure. Once I tried my login and it failed, I could get into a Terminal but while I could return to the GUI, it was back to the login page but the only way to get out was to either go to a terminal screen or reboot.
I also just had problems with accessing the internet. I used the Yast network page and after updating, I could get into the internet and send this message.
Is there a .desktop file present?
ls -l /usr/share/wayland-sessions/
There is.
ls -l /usr/share/wayland-sessions/
total 48
lrwxrwxrwx 1 root root 48 Apr 12 2025 default.desktop -> /etc/alternatives/default-waylandsession.desktop
-rw-r--r-- 1 root root 8364 Jun 29 2025 gnome-classic-wayland.desktop
-rw-r--r-- 1 root root 8232 Jun 29 2025 gnome-classic.desktop
-rw-r--r-- 1 root root 8402 Apr 12 2025 gnome-wayland.desktop
-rw-r--r-- 1 root root 7960 Apr 12 2025 gnome.desktop
That checks out ok.
Can you start a Wayland session directly (VT as user) with
XDG_SESSION_TYPE=wayland dbus-run-session gnome-session?
It wouldn’t start. I tried that command multiple ways - started a terminal and tried it, tried it after a reboot (and before logging in), and even in a terminal after trying to log in.
The last try was in a terminal window after logging in as root. This was the result (common for all of the tries):
XDG_SESSION_TYPE=wayland dbus-run-session gnome-session
dbus-daemon[3625]: [session uid=0 pid=3625] Activating service name='org.a11y.Bus' requested by ':1.1' (uid=0 pid=3651 comm="/usr/libexec/gnome-session-check-accelerated")
dbus-daemon[3625]: [session uid=0 pid=3625] Successfully activated service 'org.a11y.Bus'
dbus-daemon[3625]: [session uid=0 pid=3625] Activating service name='org.freedesktop.systemd1' requested by ':1.3' (uid=0 pid=3664 comm="/usr/bin/dbus-broker-launch --config-file=/usr/sha")
dbus-daemon[3625]: [session uid=0 pid=3625] Activated service 'org.freedesktop.systemd1' failed: Process org.freedesktop.systemd1 exited with status 1
dbus-daemon[3625]: [session uid=0 pid=3625] Activating service name='org.gtk.vfs.Daemon' requested by ':1.0' (uid=0 pid=3651 comm="/usr/libexec/gnome-session-check-accelerated")
dbus-daemon[3625]: [session uid=0 pid=3625] Successfully activated service 'org.gtk.vfs.Daemon'
dbus-daemon[3625]: [session uid=0 pid=3625] Activating service name='org.freedesktop.systemd1' requested by ':1.8' (uid=0 pid=3626 comm="/usr/libexec/gnome-session-binary")
dbus-daemon[3625]: [session uid=0 pid=3625] Activated service 'org.freedesktop.systemd1' failed: Process org.freedesktop.systemd1 exited with status 1
dbus-daemon[3625]: [session uid=0 pid=3625] Activating service name='ca.desrt.dconf' requested by ':1.8' (uid=0 pid=3626 comm="/usr/libexec/gnome-session-binary")
dbus-daemon[3625]: [session uid=0 pid=3625] Successfully activated service 'ca.desrt.dconf'
A connection to the bus can't be made
This is proving challenging. From a VT (logged in as user), check
systemctl --user status
Done. Results:
localhost
STATE: running
UNITS: 248 loaded (incl. loaded aliases)
FAILED: 0 units
SINCE: Tues 2026-2-3 17:55:21 EST 9 sec ago
SYSTEMD: 257.7+suse.19.ga0dfd5de4c
cgroup /user.slice /user-1000.slice/user@1000.service
L init.scope
L 5911 /usr/lib/systemd/systemd --user
L5913 "sd-pam"
The L reflects a symbol indicating descent in the original text.
Now, I was forced to start the upgrade (using the CLI) using root. It was the only way I could get anything to start working due to the problems with 15.6. I wouldn’t think that could cause this much trouble - but often it’s the small things that create the biggest problems. What do you think?
Also check
systemctl status systemd-logind
systemctl status polkit
No errors?
No errors - checked both root and in VT with my login there.
Only interested in user output here, as root bypasses polkit checks etc.
I’m not a GDM user, but this wiki page should be relevant with respect to putting into debug mode…
https://wiki.gentoo.org/wiki/GNOME/GDM#Debugging
Let’s see if we can generate more verbose output.
After making the changes do sudo systemctl restart gdm.
Then attempt login and capture the GDM logging:
sudo journalctl -b -u gdm -o cat
I didn’t capture the whole output, but in all the lines there was only one error - one we’ve seen before.
gkr-pam: unable to locate daemon control file.
I found that sometimes the home/user directory would have files not set to the proper owner. Fixing that didn’t eliminate the problem. I’m going to do a little digging on that error.
Yeah, that is related to what we saw before…
Feb 02 23:19:48 localhost gdm-password][2326]: gkr-pam: unable to locate daemon control file
Feb 02 23:19:48 localhost gdm-password][2326]: gkr-pam: stashed password to try later in open session
…it just means that the file gkr-pam referenced wasn’t readable at that time (reason unknown) and so gets stashed to try later when the GNOME keyring has started.
Let’s cast the net wider (watch everything)…
sudo journalctl -b --since "5 minutes ago"
Run that after another login attempt. There may be a lot of output to trawl through, but maybe we’ll see the gnome-shell fail, some graphics related issue at play, or something else unforeseen.
From the reading I’ve been able to do, this could cause exactly what I’m experiencing. I’ve tried to find the file on YAST, but nothing shows up. Maybe it was dropped in the move to 16?
It is starting to look more and more like the upgrade from 15.6 to 16 got messed up (maybe didn’t finish properly). I don’t want to have to sit here and babysit the computer for another full upgrade/install - especially as it was posting every file that it installed.
It could also be that there is a repository that is needed, but didn’t get included.