Ah… It seems I was composing my reply whilst you were posting yours… (#19)
I think you have other problems there also, although at a cursory glance I’m not too sure what…
Paul -
Point of clarification -
I checked the time of the last boot - it was 14:11 (yesterday). So the errors of concern are those prior to 14:11 and at the time of the four unsuccessful starts, e.g.:
2020-11-07T13:52:27.840723-05:00 linux-5 sddm-greeter[1879]: QXcbConnection: Could not connect to display :0
2020-11-07T13:52:27.840967-05:00 linux-5 sddm-greeter[1879]: Could not connect to any X display.
2020-11-07T13:52:27.890623-05:00 linux-5 sddm[1545]: Auth: sddm-helper exited with 1
A search for the “sddm-greeter Could not connect to any X display” yields several discussions and bug reports.
As to the “QObject: Cannot create children” errors (those after 14:11), one post I found attributed them to a cache (/var/lib/sddm/.cache/sddm-greeter/qmlcache/). See https://github.com/NixOS/nixpkgs/issues/35013. Deleting the cache directory cleared up the problem for that person.
Regarding your bug report, would it be of assistance to your correspondents to see this thread? Out of curiosity, I ran a few of the commands requested in the report:
linux-5:~ # ps -ef | grep -E 'sddm|/X'
root 1652 1 0 Nov07 ? 00:00:00 /usr/bin/sddm
root 1710 1652 1 Nov07 tty7 00:20:07 /usr/bin/X -nolisten tcp -auth /run/sddm/{c98882bc-22e4-425a-909a-c768f6c29a36} -background none -noreset -displayfd 18 -seat seat0 vt7
root 1917 1652 0 Nov07 ? 00:00:00 /usr/lib/sddm/sddm-helper --socket /tmp/sddm-authef5ea4b1-83e2-4f0f-b0a9-d92cc82caf34 --id 1 --start /usr/bin/startkde --user root
root 1978 1928 0 Nov07 ? 00:00:01 /usr/bin/gpg-agent --sh --daemon --keep-display /etc/X11/xinit/xinitrc
root 21910 20785 0 11:51 pts/1 00:00:00 grep --color=auto -E sddm|/X
linux-5:~ # XAUTHORITY="/run/sddm/{c98882bc-22e4-425a-909a-c768f6c29a36}" xauth list
linux-5.fios-router.home/unix:0 MIT-MAGIC-COOKIE-1 efa87a72b33164512cff1a125631e5ef
linux-5:~ # XAUTHORITY="/run/sddm/{c98882bc-22e4-425a-909a-c768f6c29a36}" sddm-greeter --test-mode
linux-5:~ #
This last command yields the same result as in my post #16 above (https://forums.opensuse.org/showthread.php/547012-Login-panel-doesn-t-appear?p=2981758#post2981758). Interestingly, for me, without the ID (UUID?) for both commands (“xauth list” and “sddm-greeter --test-mode”).
As you suggest, I may downgrade the sddm version or use LightDM if the problem remains when I restart the machine. I wonder why this isn’t occurring on my other machines.
Hi
I had the same problem this morning after updating my Leap 15.2 last night. Ctrl-Alt-Backspace did nothing.
sddm-greeter --test-mode wouldn’t let me get past entering my password.
Opening another terminal and logging in as user, then, using startx, my desktop appears.
This computer uses Nvidia blob, while my second Leap 15.2 install, which uses Mesa, did not have this problem.
Results of sddm-greeter test
~> sddm-greeter --test-mode
[11:50:39.136] (II) GREETER: High-DPI autoscaling Enabled
[11:50:39.194] (II) GREETER: Reading from "/usr/share/xsessions/icewm.desktop"
[11:50:39.202] (II) GREETER: Reading from "/usr/share/xsessions/plasma5.desktop"
[11:50:39.202] (II) GREETER: Reading from "/usr/share/xsessions/twm.desktop"
[11:50:39.221] (II) GREETER: Reading from "/usr/share/wayland-sessions/plasmafullwayland.desktop"
[11:50:39.229] (II) GREETER: Reading from "/usr/share/wayland-sessions/plasmawayland.desktop"
[11:50:39.238] (II) GREETER: Loading theme configuration from "qrc:/theme/theme.conf"
[11:50:39.274] (EE) GREETER: Socket error: "QLocalSocket::connectToServer: Invalid name"
[11:50:39.330] (II) GREETER: Loading qrc:/theme/Main.qml...
[11:50:40.069] (II) GREETER: Adding view for "DVI-I-2" QRect(0,0 1920x1080)
[11:50:40.078] (II) GREETER: Loading qrc:/theme/Main.qml...
[11:50:40.085] (II) GREETER: Adding view for "DVI-I-3" QRect(1920,0 1920x1080)
[11:50:54.927] (II) GREETER: Reading from "/usr/share/xsessions/plasma5.desktop"
[11:50:54.928] (WW) GREETER: QIODevice::write (QLocalSocket): device not open
[11:51:12.994] (II) GREETER: Reading from "/usr/share/xsessions/plasma5.desktop"
[11:51:12.994] (WW) GREETER: QIODevice::write (QLocalSocket): device not open
Some bits from journalctl
Nov 08 10:32:21 localhost.localdomain sddm-helper[1910]: pam_unix(sddm-greeter:session): session opened for user sddm by (uid=0)
Nov 08 10:32:21 localhost.localdomain sddm[1669]: Greeter session started successfully
Nov 08 10:32:22 localhost.localdomain sddm-greeter[1923]: High-DPI autoscaling Enabled
Nov 08 10:32:22 localhost.localdomain sddm-greeter[1923]: could not connect to display :0
Nov 08 10:32:22 localhost.localdomain sddm-greeter[1923]: Could not load the Qt platform plugin "xcb" in "" even though it was found.
Nov 08 10:32:22 localhost.localdomain sddm-greeter[1923]: Failed to create wl_display (No such file or directory)
Nov 08 10:32:22 localhost.localdomain sddm-greeter[1923]: Could not load the Qt platform plugin "wayland" in "" even though it was found.
Nov 08 10:32:22 localhost.localdomain sddm-greeter[1923]: This application failed to start because no Qt platform plugin could be initialized. Reinstalling the application may fix this problem.
Available platform plugins are: wayland-org.kde.kwin.qpa, eglfs, linuxfb, minimal, minimalegl, offscreen, vnc, wayland-egl, wayland, wayland-xcomposite-egl, wayland-xcomposite-glx, xcb.
Nov 08 10:32:22 localhost.localdomain sddm-helper[1910]: [PAM] Closing session
Nov 08 10:32:22 localhost.localdomain sddm-helper[1910]: pam_unix(sddm-greeter:session): session closed for user sddm
Nov 08 10:32:22 localhost.localdomain sddm-helper[1910]: [PAM] Ended.
Nov 08 10:32:22 localhost.localdomain sddm[1669]: Auth: sddm-helper exited with 6
Nov 08 10:32:22 localhost.localdomain sddm[1669]: Greeter stopped.
I used Yast to downgrade sddm to the previous version:
sddm | 0.18.0-lp152.4.11 (0.18.0-lp152.5.3.1)
And sddm-greeter works again.
This bug @ https://bugzilla.opensuse.org/show_bug.cgi?id=1177201 explains the security update to sddm. Right now I’m trying to decide if I should add to this bug or start a new one.
Thanks
Tom
Both of these bug reports are referenced directly or indirectly earlier in this thread.
Sorry, next time I’ll have my coffee before I post.
I’ve read through all the posts before I decided to add my experience.
I, too, experienced what has been related so far in this article.
I almost freaked out after I rebooted from an update yesterday and was confronted with a black (not blank) screen (as if X was running, but only in black).
In the past, I’ve found myself working in the dark, so to speak, and being a person who is curious, I simply typed in my password at the “non” prompt and pressed my Enter key.
It worked! I was logged in and was going through to my user as it usually would - with the splash screen’s light bulb doing it’s thing.
It confirmed my suspicion that the problem was possibly with the rendering of the login page.
But, I haven’t rebooted since that time to find out, so I don’t know if this was a one off, but I’ll find out once I’ve taken the time to reboot, (which I sometimes do when I wake up in the morning).
kerijan2003 -
Thanks for the reply. I tried to do just that - enter my password following “Starting Locale Service…” when the display went completely black. It didn’t work.
My usual practice is to power down all machines every evening, but for the first time I’m leaving this one running until perhaps Tuesday.
If the current logs are complete - see my post #22 (https://forums.opensuse.org/showthread.php/547012-Login-panel-doesn-t-appear?p=2981824#post2981824), indicating that the display was reachable, perhaps the machine will boot up properly.
Nevertheless, based on my searches and Tanington’s response, this is potentially an issue for which there may not be a simple resolution.
@All
Could those affected by this issue please run:
inxi -xxG
and post the results.
(You may need to first install inxi, it’s in the standard repositories)
sudo zypper in inxi
No luck getting it to reproduce on TW:
# inxi -SGIay
System:
Host: p5bse Kernel: 5.8.14-1-default x86_64 bits: 64 compiler: gcc v: 10.2.1
parameters: noresume mitigations=auto consoleblank=0
Desktop: KDE Plasma 5.20.2 tk: Qt 5.15.1 wm: kwin_x11 dm: SDDM
Distro: openSUSE **Tumbleweed 20201107**
Graphics:
Device-1: NVIDIA GF119 [NVS 310] vendor: Hewlett-Packard driver: nouveau
v: kernel bus ID: 01:00.0 chip ID: 10de:107d
Display: x11 server: **X.Org 1.20.9** compositor: kwin_x11 **driver: modesetting**
unloaded: fbdev,vesa alternate: nouveau,nv,nvidia display ID: :0 screens: 1
Screen-1: 0 s-res: 2560x1440 s-dpi: 120 s-size: 541x304mm (21.3x12.0")
s-diag: 621mm (24.4")
Monitor-1: DP-2 res: 2560x1440 hz: 60 dpi: 109 size: 598x336mm (23.5x13.2")
diag: 686mm (27")
OpenGL: renderer: llvmpipe (LLVM 11.0.0 128 bits) v: 4.5 Mesa 20.2.1
compat-v: 3.1 direct render: Yes
Info:...**running in: konsole inxi: 3.1.08**
I think, but have yet to prove conclusively, it only manifests itself on systems using the Nvidia proprietary drivers. Of the 4 systems I have only one has this issue, and that uses the Nvidia 450.80.02 driver.
Ah… I’m less certain of that now, as over on the bug report https://bugzilla.opensuse.org/show_bug.cgi?id=1178543#c8 in comment #8 a user states the issue is “solved” after switching from “networkmanager” to “wicked”… don’t immediately see the connection (no pun intended) there :\ …
The only thing here using network mangler is a 12 year old laptop given to me with 15.1 already installed. 
Well indeed there was a connection. Quoting from: 1178543 – SDDM 0.18.0-lp152.5.3.1 Fails to display login screen with Nvidia Graphics. @Fabian Vogt wrote
That would indicate that it’s a race condition involving the hostname.
This test package: Welcome - openSUSE Build Service works for me.
So it looks as if the nvidia theory was a red herring…
I’ve found network mangler (like that!) to actually work quite well on my laptop… although I must admit to also using it on the static desktops as well.
Paul -
My first attempt to re-start the machine since Saturday just failed. But after several bumbling attempts with grub ([cntrl][alt][F1], init 3 perhaps), the greeter mysteriously re-appeared. I have no idea how to repeat this.
I just read your comment #14 on the bug report. Do you think it’s worth trying the test package that fixed the issue for you? Since the same 11/07/20 sddm update package was provided for opensuse 15.1 and 15.2 (https://lists.opensuse.org/opensuse-updates/2020-11/msg00078.html), I suspect that the test package should be compatible with 15.1.
Alternatively, do you still recommend switching to LightDM?
For completeness, I just posted a brief comment on the bug report (comment 16 at https://bugzilla.opensuse.org/show_bug.cgi?id=1178543#c16).
You could try the package (sddm-0.18.0-lp152.5.7.1.x86_64) https://build.opensuse.org/package/show/home:Vogtinator:boo1178543-4/sddm - but I don’t know if that will be the final fix or not, this bug still appears to be a work in progress.
It may be better to switch to LightDM as a temporary measure until there is an official fix released to the update repositories. (I assume it will be back ported to 15.1 also, although 15.1 is now very near end of support: https://lists.opensuse.org/opensuse-security-announce/2020-11/msg00040.html ).
Paul -
Thanks. I’m in the middle of configuring a new hardware platform, and since I’m running VirtualBox on top of opensuse 15.1, I’m reluctant to move to 15.2 now. I can live without the updates until I get the greeter issue resolved and finalize the new PC.
Paul - Given the errors you posted in the bug report, I wonder if my issue has a different cause. See my post #22 (https://forums.opensuse.org/showthread.php/547012-Login-panel-doesn-t-appear?p=2981824#post2981824) and my bug comment #17 (https://bugzilla.opensuse.org/show_bug.cgi?id=1178543#c17).
I’m not that familiar with the inner workings of SDDM… If you look at the various comments made by other users, both in this thread and in the openSUSE bug report, it becomes apparent that, in terms of error messages, logs etc, they are not all “exactly” the same. The only real commonality is the blank/black screen with SDDM not rendering the Greeter, or in some cases, not starting at all. My initial assertion this was Nvidia related was wrong, that it seemed, was just coincidental, as there have been users of AMD graphics reporting the same issue.
I fear you may be getting a little bogged down in this 
…
If you really want to retain the use of SDDM then I see you have only two options:
Downgrading SDDM to 0.18.0-lp152.4.11 (in the Main Repository rather than the Main Update Repository) - That worked for me, and has also been reported as working for others. If you still have problems after that downgrade then I guess it’s safe to say your system has other issues also, which can be addressed knowing the problem isn’t caused by SDDM itself.
Alternatively try the test package https://build.opensuse.org/package/show/home:Vogtinator:boo1178543-4/sddm - That also worked for me, but I’ve not seen reports from any other users, so it’s more of an unknown.
It’s your system you’ll have to make the call. Personally, if I was in your situation, I’d switch to LightDM and hold off SDDM until after I’d upgraded to 15.2, after which there will undoubtedly have been an official fix for the problem and a new package rolled out.
davidc@chygra:~> inxi -xxG
**Graphics: Device-1:** Intel Xeon E3-1200 v3/4th Gen Core Processor Integrated Graphics **vendor:** Acer Incorporated ALI
**driver:** i915 **v:** kernel **bus ID:** 00:02.0 **chip ID:** 8086:0412
**Display:** x11 **server:** X.Org 1.20.3 **compositor:** kwin_x11 **driver:** intel **unloaded:** modesetting **resolution:**
**1:** 1920x1080~60Hz **2:** 1920x1080~60Hz **s-dpi:** 96
**OpenGL:** **renderer:** Mesa DRI Intel Haswell Desktop **v:** 4.5 Mesa 18.3.2 **compat-v:** 3.0 **direct render:** Yes
davidc@chygra:~>