I’ve just updated a 15.2 system, included in the update was SDDM version 0.18.0-lp152.5.3.1, following that update the system fails to display the SDDM login screen, the last line shown is “Starting Locale Service”, consistent on every boot.
If I revert to SDDM 0.18.0-lp152.4.11 all works again.
Anyone else seeing this issue?
(There is a similar problem here https://forums.opensuse.org/showthread.php/547012-Login-panel-doesn-t-appear but that’s a 15.1 system, may just be a coincidence).
Just updated a second Leap 15.2 system to SDDM 0.18.0-lp152.5.3.1 and no problem.
Looks like it’s probably graphics driver related, the non-working system is Nividia proprietary driver, the working system AMD Radeon.
I feel a bug report coming on, but that will have to wait until later today…
Change of today’s (not so well laid) plans enabled a bug report somewhat sooner.
https://bugzilla.opensuse.org/show_bug.cgi?id=1178543
Looking through the journal of a failed start of SDDM revealed this:
Nov 08 12:20:44 Orion-17 display-manager[1141]: Starting service sddm..done
Nov 08 12:20:47 Orion-17.openSUSE systemd-logind[1088]: New session 1 of user sddm.
Nov 08 12:20:47 Orion-17.openSUSE systemd[1358]: pam_unix(systemd-user:session): session opened for user sddm by (uid=0)
Nov 08 12:20:47 Orion-17.openSUSE systemd[1]: Started Session 1 of user sddm.
Nov 08 12:20:47 Orion-17.openSUSE sddm-helper[1356]: pam_unix(sddm-greeter:session): session opened for user sddm by (uid=0)
Nov 08 12:20:47 Orion-17.openSUSE sddm-greeter[1364]: could not connect to display :0
Nov 08 12:20:47 Orion-17.openSUSE sddm-greeter[1364]: Could not load the Qt platform plugin "xcb" in "" even though it was found.
Nov 08 12:20:47 Orion-17.openSUSE sddm-greeter[1364]: Could not find the Qt platform plugin "wayland" in ""
Nov 08 12:20:47 Orion-17.openSUSE sddm-greeter[1364]: This application failed to start because no Qt platform plugin could be initialized. Reinstalling the application may fix this problem.
Nov 08 12:20:47 Orion-17.openSUSE sddm-helper[1356]: pam_unix(sddm-greeter:session): session closed for user sddm
Nov 08 12:20:47 Orion-17.openSUSE sddm[1193]: Auth: sddm-helper exited with 6
Nov 08 12:20:58 Orion-17.openSUSE systemd[1359]: pam_unix(systemd-user:session): session closed for user sddm
This line rather stood out: “This application failed to start because no Qt platform plugin could be initialized. Reinstalling the application may fix this problem.” - However, reinstalling the application didn’t fix the problem.
Grep for “sddm” in /etc/passwd – the home directory of the user “sddm” should be /var/lib/sddm/ – on this system it currently looks like this:
# l /var/lib/sddm/
insgesamt 28
drwxr-x--- 6 sddm sddm 4096 18. Aug 16:33 ./
drwxr-xr-x 71 root root 4096 9. Sep 09:36 ../
drwxr-xr-x 6 sddm sddm 4096 27. Okt 16:34 .cache/
drwxr-xr-x 2 sddm sddm 4096 6. Jul 14:41 .config/
drwxr-xr-x 2 sddm sddm 4096 18. Aug 16:33 .fontconfig/
drwxr-xr-x 3 sddm sddm 4096 6. Jul 14:41 .local/
-rw-r--r-- 1 sddm sddm 279 9. Nov 11:22 state.conf
#
User “root” on a VT – “systemctl isolate multi-user.target” – clean out the home directory of the user “sddm” – “systemctl default” …
Thanks. Already gone through the usual clear cache routine and deleting the contents of /var/lib/sddm/ This isn’t the first time I’ve had problems with SDDM. Quite likely I’ll make the permanent change now to LightDM.
No… this is rather a weird one, take a look at the earlier thread: https://forums.opensuse.org/showthread.php/547012-Login-panel-doesn-t-appear from around post #17 onwards, together with the openSUSE bugzilla entry: https://bugzilla.opensuse.org/show_bug.cgi?id=1178543
I’m beginning to think it’s a phase of the moon thing… :\
Are you absolutely certain that, nothing has been removed/overwritten/missed?
Yes with a very high degree of certainty, more so as an increasing number of users are now also reporting seeing this after the update of SDDM to (on Leap 15.2) 0.18.0-lp152.5.3.1
It is also looking more probably that nvidia graphics are somehow implicated in this issue.
Just coincidence it would seem… see https://forums.opensuse.org/showthread.php/547012-Login-panel-doesn-t-appear?p=2982253#post2982253
Hmm – yes for me executing “XAUTHORITY="/run/sddm/{13fbc083-daa2-4935-9fbe-cc86cf44576a}" xauth list” also times out –
No problems with 3400G:
3400G:~ # journalctl --directory /mnt/@/var/log/journal/ -b 0 _PID=1271
-- Logs begin at Sat 2020-06-20 23:50:03 CEST, end at Tue 2020-11-10 16:59:16 CET. --
Nov 10 16:50:14 Leap sddm[1271]: Initializing...
Nov 10 16:50:14 Leap sddm[1271]: Starting...
Nov 10 16:50:14 Leap sddm[1271]: Logind interface found
Nov 10 16:50:14 Leap sddm[1271]: Adding new display on vt 7 ...
Nov 10 16:50:14 Leap sddm[1271]: Loading theme configuration from ""
Nov 10 16:50:14 Leap sddm[1271]: Display server starting...
Nov 10 16:50:14 Leap sddm[1271]: Adding cookie to "/run/sddm/{88b67fa3-025b-4adb-aa40-36fe9e3076b0}"
Nov 10 16:50:14 Leap sddm[1271]: Running: /usr/bin/X -nolisten tcp -auth /run/sddm/{88b67fa3-025b-4adb-aa40-36fe9e3076b0} -background none -noreset -displayfd 17 -seat seat0 vt7
Nov 10 16:50:15 Leap sddm[1271]: Setting default cursor
Nov 10 16:50:15 Leap sddm[1271]: Running display setup script "/etc/X11/xdm/Xsetup"
Nov 10 16:50:15 Leap sddm[1271]: Display server started.
Nov 10 16:50:15 Leap sddm[1271]: Socket server starting...
Nov 10 16:50:15 Leap sddm[1271]: Socket server started.
Nov 10 16:50:15 Leap sddm[1271]: Loading theme configuration from "/usr/share/sddm/themes/breeze-openSUSE/theme.conf"
Nov 10 16:50:15 Leap sddm[1271]: Greeter starting...
Nov 10 16:50:15 Leap sddm[1271]: Greeter session started successfully
Nov 10 16:50:15 Leap sddm[1271]: Message received from greeter: Connect
Nov 10 16:50:22 Leap sddm[1271]: Message received from greeter: Login
Nov 10 16:50:22 Leap sddm[1271]: Reading from "/usr/share/wayland-sessions/plasmawayland.desktop"
Nov 10 16:50:22 Leap sddm[1271]: Reading from "/usr/share/wayland-sessions/plasmawayland.desktop"
Nov 10 16:50:22 Leap sddm[1271]: Session "/usr/share/wayland-sessions/plasmawayland.desktop" selected, command: "dbus-run-session /usr/bin/startplasma-wayland"
Nov 10 16:50:22 Leap sddm[1271]: Authenticated successfully
Nov 10 16:50:22 Leap sddm[1271]: Jumping to VT 2
Nov 10 16:50:22 Leap sddm[1271]: VT mode didn't need to be fixed
Nov 10 16:50:22 Leap sddm[1271]: Session started
Nov 10 16:59:10 Leap sddm[1271]: Error from greeter session: "Process crashed"
Nov 10 16:59:10 Leap sddm[1271]: Auth: sddm-helper crashed (exit code 15)
Nov 10 16:59:10 Leap sddm[1271]: Error from greeter session: "Process crashed"
Nov 10 16:59:10 Leap sddm[1271]: Auth: sddm-helper exited with 15
Nov 10 16:59:10 Leap sddm[1271]: Greeter stopped.
Nov 10 16:59:10 Leap sddm[1271]: Authentication error: "Process crashed"
Nov 10 16:59:10 Leap sddm[1271]: Auth: sddm-helper crashed (exit code 15)
Nov 10 16:59:10 Leap sddm[1271]: Authentication error: "Process crashed"
Nov 10 16:59:10 Leap sddm[1271]: Auth: sddm-helper exited with 15
Nov 10 16:59:10 Leap sddm[1271]: Socket server stopping...
Nov 10 16:59:10 Leap sddm[1271]: Socket server stopped.
Nov 10 16:59:10 Leap sddm[1271]: Display server stopping...
Nov 10 16:59:15 Leap sddm[1271]: Removing display ":0" ...
Nov 10 16:59:15 Leap sddm[1271]: Adding new display on vt 7 ...
Nov 10 16:59:15 Leap sddm[1271]: Loading theme configuration from ""
Nov 10 16:59:15 Leap sddm[1271]: Display server starting...
Nov 10 16:59:15 Leap sddm[1271]: Adding cookie to "/run/sddm/{534c434d-34c2-434b-bf98-37f896f14823}"
Nov 10 16:59:15 Leap sddm[1271]: Running: /usr/bin/X -nolisten tcp -auth /run/sddm/{534c434d-34c2-434b-bf98-37f896f14823} -background none -noreset -displayfd 17 -seat seat0 vt7
Nov 10 16:59:15 Leap sddm[1271]: Setting default cursor
Nov 10 16:59:15 Leap sddm[1271]: Running display setup script "/etc/X11/xdm/Xsetup"
Nov 10 16:59:15 Leap sddm[1271]: Display server started.
Nov 10 16:59:15 Leap sddm[1271]: Socket server starting...
Nov 10 16:59:15 Leap sddm[1271]: Socket server started.
Nov 10 16:59:15 Leap sddm[1271]: Loading theme configuration from "/usr/share/sddm/themes/breeze-openSUSE/theme.conf"
Nov 10 16:59:15 Leap sddm[1271]: Greeter starting...
Nov 10 16:59:15 Leap sddm[1271]: Display server stopping...
Nov 10 16:59:15 Leap sddm[1271]: Display server stopped.
Nov 10 16:59:15 Leap sddm[1271]: Running display stop script "/usr/share/sddm/scripts/Xstop"
Nov 10 16:59:15 Leap sddm[1271]: Signal received: SIGTERM
Nov 10 16:59:15 Leap sddm[1271]: Socket server stopping...
Nov 10 16:59:15 Leap sddm[1271]: Socket server stopped.
Nov 10 16:59:15 Leap sddm[1271]: Display server stopping...
Nov 10 16:59:16 Leap sddm[1271]: Display server stopped.
Nov 10 16:59:16 Leap sddm[1271]: Running display stop script "/usr/share/sddm/scripts/Xstop"
Nov 10 16:59:16 Leap sddm[1271]: QProcess: Destroyed while process ("/usr/lib/sddm/sddm-helper") is still running.
3400G:~ #
Nope. I’m on an intel gpu.
Yes… That was rather a red herring.
The issue was caused by a race condition involving the hostname, which resulted in hostname changing between sddm writing the xauth cookie and X having started.
See: https://bugzilla.opensuse.org/show_bug.cgi?id=1178543#c13 for details.
Thanks to all who contributed and offered additional insights.
To my experience life is easiest with a static hostname never changed by dhcp:
**erlangen:~ #** hostnamectl
Static hostname: erlangen
Icon name: computer-desktop
Chassis: desktop
Machine ID: 94f3af277bac4a8eb57da425c9677379
Boot ID: 32a2204476944b14840cc70e871a2d06
Operating System: openSUSE Tumbleweed
CPE OS Name: cpe:/o:opensuse:tumbleweed:20201108
Kernel: Linux 5.9.1-1-default
Architecture: x86-64
**erlangen:~ #**
No wonder I couldn’t reproduce. 
What reason(s) is/are there for not having a static hostname?
Don’t quite understand that myself… The hostname on the offending machine isn’t set by dhcp, it is to the best of my knowledge static:
paul@Orion-17:~> hostnamectl
Static hostname: Orion-17.openSUSE
Icon name: computer-desktop
Chassis: desktop
Machine ID: 0432be69e53bd48ce5d1cfa7592030eb
Boot ID: 4c3a7b517ebf44a18c7a6e587e688c9f
Operating System: openSUSE Leap 15.2
CPE OS Name: cpe:/o:opensuse:leap:15.2
Kernel: Linux 5.3.18-lp152.47-default
Architecture: x86-64
paul@Orion-17:~>
The fix to SDDM (to allow for a changing hostname) did however cure the problem of no login screen.
All very moot now anyway… In the course of trying various (SDDM) test packages I was switching between LightDM and SDDM quite frequently… I’ve rather taken a liking to LightDM and that’s the DM I’m now using permanently.
OK. Bugging me so I investigated a little further. I now see (I think) how the hostname was changing…
The Static Hostname is set in “YaST2 -> Network Settings -> Hostname/DNS” and with “Set Hostname via DHCP = No”
However, when Network Manager starts for the first time following a boot of the system the hostname is set to “none” before being set to the name defined as the Static Hostname.
2020-11-11T13:39:51.662237+00:00 HP255G7 NetworkManager[1203]: <info> [1605101991.6620] NetworkManager (version 1.22.10) is starting... (for the first time)
2020-11-11T13:39:51.662614+00:00 HP255G7 NetworkManager[1203]: <info> [1605101991.6621] Read config: /etc/NetworkManager/NetworkManager.conf (etc: 50-disable-connectivity-check.conf)
2020-11-11T13:39:51.665404+00:00 HP255G7 NetworkManager[1203]: <info> [1605101991.6650] bus-manager: acquired D-Bus service "org.freedesktop.NetworkManager"
2020-11-11T13:39:51.670004+00:00 HP255G7 NetworkManager[1203]: <info> [1605101991.6699] manager[0x557b40005070]: monitoring kernel firmware directory '/lib/firmware'.
2020-11-11T13:39:51.770795+00:00 HP255G7 NetworkManager[1203]: <info> [1605101991.7707] hostname: hostname: using hostnamed
2020-11-11T13:39:51.770995+00:00 HP255G7 NetworkManager[1203]: <info> [1605101991.7707] hostname: hostname changed from (none) to "HP255G7"
I’m not sure where SDDM was reading the Hostname from, but as it seems this only happens on systems using Network Manager I guess it’s getting the name from NM.
But… as I said, all somewhat moot now as I’m using LightDM.
In “/etc/sysconfig/network/dhcp” – the following parameters:DHCLIENT_FQDN_ENABLED
DHCLIENT_FQDN_UPDATE
DHCLIENT6_FQDN_ENABLED
DHCLIENT6_FQDN_UPDATE
DHCLIENT_SET_HOSTNAME
DHCLIENT_HOSTNAME_OPTION
DHCLIENT6_SET_HOSTNAME
DHCLIENT6_HOSTNAME_OPTION
Take particular note of the comments related to the “set hostname” parameters:
## Type: yesno
## Default: no
#
# Should the DHCPv4 client set the hostname? (yes|no)
#
# When it is likely that this would occur during a running X session,
# your DISPLAY variable could be screwed up and you won't be able to open
# new windows anymore, then this should be "no".
#
# If it happens during booting it won't be a problem and you can
# safely say "yes" here. For a roaming notebook with X kept running, "no"
# makes more sense.
#
DHCLIENT_SET_HOSTNAME="no"
## Type: string
## Default: AUTO
#
# Specifies the hostname option field when DHCPv4 client sends messages.
# Some DHCP servers will update nameserver entries (dynamic DNS) to it.
# Also, some DHCP servers, notably those used by @Home Networks, require
# the hostname option field containing a specific string in the DHCP
# messages from clients.
#
# When set to "AUTO", the current hostname from /etc/hostname is sent.
# Use this variable to override it with another hostname, or leave it
# empty to not send any hostname.
#
DHCLIENT_HOSTNAME_OPTION="AUTO"
More or less the same comments apply to the DHCPv6 parameters …
[HR][/HR]AFAICS, the default parameter values in “/etc/sysconfig/network/dhcp” make sense and are, AFAICS, the preferred values for most of the machines attached to @Home networks …
In “/etc/sysconfig/network/dhcp” at line 12
#
# Note: NetworkManager is not using any sysconfig settings.
#
Thanks. But I’m not going to pursue this as I have no networking issues, SDDM has a fix to allow for any hostname change, and, I’m now using LightDM anyway.
Digging further, the “host’s name being changed” issue seems to be buried in the default DHCP configuration –
# Request several well known/usefull dhcp options.
request subnet-mask, broadcast-address, routers, rfc3442-classless-static-routes, interface-mtu, **host-name**, **domain-name**, domain-search, domain-name-servers, nis-domain, nis-servers, nds-context, nds-servers, nds-tree-name, netbios-name-servers, netbios-dd-server, netbios-node-type, netbios-scope, ntp-servers;
# rfc4833-tz-posix-string, rfc4833-tz-name;
Meaning that, the DHCP server will always be asked to provide the client’s host name and domain name but, whether or not those strings will be applied, or not, is up to the network management being used by the client …
If a valid static hostname is set, NetworkManager will skip the update of the hostname despite the value of this option. An hostname empty or equal to ‘localhost’, ‘localhost6’, ‘localhost.localdomain’ or ‘localhost6.localdomain’ is considered invalid.
“hostname-mode=none” seems to be the method to use if NetworkManager shall never, ever, manage the transient hostname …
Thanks for your further investigations. I’ll make a note of that for possible future use, for the moment I’m leaving networking as is, as it works OK, and the SDDM issue is lo longer a problem.