Login panel doesn't appear

English Install/Boot/Login
1

After successful and uneventful logins through yesterday (Friday, Nov. 6th), this morning the machine (with all updates installed) hangs when the login dialogue would normally appear. It appeared once when I selected recovery mode for the current kernel version, but I was unable to boot in again after turning the machine off.

The only thing I saw in boot log (journatctl -b) was a failure to find a USB external drive, but that line has a nowait option in fstab. I swapped in another drive with the
same label, but it still doesn’t present the login panel.

Edit: Now after initially posting the message, I rebooted normally, but avoided pressing F2 to watch the boot sequence. And, inexpicably, it booted up! I’ve got an intermittent fault (I think), but I have no idea how to proceed.

Any thoughts?

2

try adding nomodeset (after the quiet option in GRUB_CMDLINE_LINUX_DEFAULT) in the grub menu

3

Cama -

Thank you for your reply. Briefly, how will the nomodeset grub option help? Is it a display issue? And why all of a sudden after months of uneventful logins?

I’m now working from the workstation in question and am looking at logs, but nothing stands out.

4

maybe you updated some drivers and they stopped working. this is what to me happened once
nomodeset
The newest kernels have moved the video mode setting into the kernel. So all the programming of the hardware specific clock rates and registers on the video card happen in the kernel rather than in the X driver when the X server starts… This makes it possible to have high resolution nice looking splash (boot) screens and flicker free transitions from boot splash to login screen. Unfortunately, on some cards this doesnt work properly and you end up with a black screen. Adding the nomodeset parameter instructs the kernel to not load video drivers and use BIOS modes instead until X is loaded.

5

The question is, did the OP update the system in between or not? That is not clear from his first post (at least not to me).

Only guessing and then giving advice based on that guess will not help much.

6

Henk -

Your response popped up while I was writing the following response to Cama. Perhaps it answers your question about updates (only via YaSt - nothing else).

As noted in my original post, it worked fine until yesterday. Here are the items installed via YaST yesterday:

# rpm -qa --last | less

xscreensaver-lang-5.44-lp151.5.3.1.noarch     Fri Nov  6 06:46:05 2020
chromium-86.0.4240.183-lp151.2.150.1.x86_64   Fri Nov  6 06:46:04 2020
xorg-x11-Xvnc-module-1.9.0-lp151.4.9.1.x86_64 Fri Nov  6 06:45:52 2020
xscreensaver-5.44-lp151.5.3.1.x86_64          Fri Nov  6 06:45:51 2020
libtiff5-4.0.9-lp151.10.3.1.x86_64            Fri Nov  6 06:45:51 2020
libminizip1-1.2.11-lp151.5.12.1.x86_64        Fri Nov  6 06:45:51 2020
tigervnc-1.9.0-lp151.4.9.1.x86_64             Fri Nov  6 06:45:50 2020
zlib-devel-1.2.11-lp151.5.12.1.x86_64         Fri Nov  6 06:45:48 2020
xorg-x11-Xvnc-1.9.0-lp151.4.9.1.x86_64        Fri Nov  6 06:45:48 2020
xscreensaver-data-5.44-lp151.5.3.1.x86_64     Fri Nov  6 06:45:47 2020
libz1-1.2.11-lp151.5.12.1.x86_64              Fri Nov  6 06:45:47 2020
libXvnc1-1.9.0-lp151.4.9.1.x86_64             Fri Nov  6 06:45:47 2020

I note that several packages related to xorg-x11-Xvnc were installed, but it is not clear that this could be the culprit. An opensuse forum search and a Google search for the package didn’t yield any relevant items.

Please again note that the only apparent symptom is the non-appearance of the login dialog.

7

That’s wrong. All high competence FOSS X drivers (amdgpu, intel, modesetting, nouveau, radeon) are prevented from loading by disabling KMS (e.g. via nomodeset), explained here. Nomodeset results in slow, unresponsive, lowfi X from use of fallback drivers FBDEV or VESA, if any X at all. Some DEs will not start at all if KMS is disabled.

Nomodeset can facilitate some configuration adjustments, if any manual ones are indicated, but it definitely won’t be part of OP’s ultimate solution, unless OP is using a non-FOSS driver (e.g. some versions of NVidia’s proprietary drivers) that explicitly requires KMS be disabled.

What OP should do is hit ESC as soon as a Grub selection has been made in hopes of noticing an error message pointing to a problem.

Sometimes the problem is only in the GUI bling that precedes the login manager. Striking the E key at the Grub menu will enable the string plymouth=0 to be appended to the line that begins linu before proceeding with boot. This for one boot only will turn off the bling, which may work around the problem. If it does, for a longer term solution either Plymouth may be uninstalled using zypper or YaST, or plymouth=0 can be included in the GRUB_CMDLINE_LINUX_DEFAULT= line in /etc/default/grub followed by regenerating grub.cfg using grub2-mkconfig -o /boot/grub2/grub.cfg.

OP should upload /var/log/Xorg.0.log.old or ~/.local/share/xorg/Xorg.0.log.old, whichever is newer if both exist, on a nomodeset or failsafe boot immediately following a normal boot attempt, using the susepaste command or by visiting https://susepaste.org or https://pastebin.com. Output from:

sudo journalctl -b -1 | susepaste

or

sudo journalctl -b -1 > *sometextfile*.txt

and uploading to susepaste.org or pastebin.com. The URLs from the uploads should be pasted here for our examination.

It may be helpful to also include output pasted here using code tags surrounding the paste from the following run from an X terminal:

inxi -SMGIay

If this produces an error message, try omitting the y. It can be run from a vtty shell prompt, but less information will result.

8

In the grub boot option
If you go to advanced options
Do you have older kernels?
Have you tried those

9

Here is the response:

linux-5:~ # inxi -SMGIa
System:    Host: linux-5.fios-router.home Kernel: 4.12.14-lp151.28.75-default x86_64 bits: 64 compiler: gcc v: 7.5.0 
           parameters: BOOT_IMAGE=/boot/vmlinuz-4.12.14-lp151.28.75-default root=UUID=82c65205-7768-4135-8ef0-eb131bfbfcaf 
           splash=silent resume=/dev/disk/by-uuid/9db42ad9-6172-42c9-b322-c01ce43e8048 mitigations=auto quiet 
           Console: tty 1 wm: kwin_x11 dm: SDDM Distro: openSUSE Leap 15.1 
Machine:   Type: Desktop Mobo: ASUSTeK model: P6X58-E-WS v: Rev 1.xx serial: 109358920000181 BIOS: American Megatrends v: 0301 
           date: 02/22/2011 
Graphics:  Device-1: NVIDIA GF106 [GeForce GTS 450] vendor: eVga.com. driver: nouveau v: kernel bus ID: 07:00.0 
           chip ID: 10de:0dc4 
           Display: server: X.Org 1.20.3 compositor: kwin_x11 driver: nouveau unloaded: fbdev,modesetting,vesa 
           alternate: nv,nvidia display ID: :0 screens: 1 
           Screen-1: 0 s-res: 3840x1200 s-dpi: 96 s-size: 1016x317mm (40.0x12.5") s-diag: 1064mm (41.9") 
           Monitor-1: DVI-I-1 res: 1920x1200 hz: 60 dpi: 94 size: 518x324mm (20.4x12.8") diag: 611mm (24.1") 
           Monitor-2: DVI-I-2 res: 1920x1200 hz: 60 dpi: 94 size: 518x324mm (20.4x12.8") diag: 611mm (24.1") 
           OpenGL: renderer: NVC3 v: 4.3 Mesa 18.3.2 direct render: Yes 
Info:      Processes: 263 Uptime: 2h 15m Memory: 11.71 GiB used: 5.89 GiB (50.3%) Init: systemd v: 234 runlevel: 5 
           target: graphical.target Compilers: gcc: 7.5.0 alt: 7 Shell: bash (su) v: 4.4.23 running in: konsole inxi: 3.1.00 
linux-5:~ #

This may not be of interest until I get the next failure, but the current Xorg and old Xorg logs may be seen here: current log https://susepaste.org/54295229 and old log https://susepaste.org/17692425

In response to caf4926, yes I have the previous version, gnulinux-4.12.14-lp151.28.71 (grub.cfg). Both the default and the recovery options failed (no login screen visible).

10

In looking over my notes and files, I see that I have the following logs from this morning when the problem occurred. The files were compiled before the second successful boot in the afternoon.

I recognize that some of this may be duplicative, but include links to all of the files I created this morning.

boot.log https://susepaste.org/1435409

dump of journalctl: https://susepaste.org/66753647

warn log: https://susepaste.org/17146095

messages: https://susepaste.org/39413208

journtalctl-boot 110720: https://susepaste.org/93748811

11

I suppose by “login panel” or “login dialog” you mean the SDDM login greeter screen that may be the first screen to show up in wait for you to make something happen after having made a Grub menu selection. It’s not clear to me what is happening. Are you able to open any DE session in any manner? If so, how? Do you have autologin enabled?

I’m not recognizing any problems of significance in anything you uploaded to susepaste.

Maybe going ahead and upgrading to 15.2 would solve this. It’s less than a month before support for 15.1 is scheduled to end.

12

As mentioned in the original post, the system functioned for months (since rebuilding in January 2020) without incident.

Looking at the boot log from yesterday morning, the system booted up as usual - pressing F2 revealed the booting process - and twice reached “Starting Locale Service” when the screen went blank. See lines 154 and 308 in the boot log (https://susepaste.org/1435409). That’s when the SDDM login greeter screen (what I called the login screen), similar to this image https://susepaste.org/92076407 - should have almost immediately appeared.

I then turned the power off and on (for a cold start), selected recovery mode (in grub, advanced) for the current kernel. Lines 310-365 show the initial loading and then lines 367-510 show the remainder, at which point the SDDM greeter screen appeared. Clearly, much more appears to have happened in this boot sequence.

Later in the morning, I rebooted and was unable to access the greeter screen using any of the four options in the grub advanced panel (default and recovery for the two most recent kernels - gnulinux-4.12.14-lp151.28.75 and gnulinux-4.12.14-lp151.28.71), even from a cold start. Yesterday afternoon, I attempted a cold start with the default settings - I let the machine boot up with the default option in the grub panel and I didn’t press F2 to observe the boot process. The machine rebooted properly and I didn’t power down last evening as I usually would so that I could access it (as now) this morning.

The only updates to the system since Friday (Nov. 6th) morning’s successful login are set out in post #6 https://forums.opensuse.org/showthread.php/547012-Login-panel-doesn-t-appear?p=2981494#post2981494. Could the Xvnc updates have affected the display system?

13

Regarding the tigervnc and Xvnc updates, I could drop back to the prior lp151.4.6.1 version of the relevant packages in YaST Software Management if the updates are the cause of the intermittent greeter screen appearance.

14

This may be some weird coincidence, but…

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”. On this system it’s consistent and happens on every boot.

As a temporary “fix” I’m using LightDM as the DM.

I wonder if that will help in your situation also, (as a temporary fix).

from the command line:

sudo zypper in lightdm

sudo update-alternatives --config default-displaymanager
15

Given that I have four other systems running the essentially the same configuration (opensuse 15.1) and having the same lp151-4.9.1 versions of xvnc and tigervnc packages installed, it seems less likely that this update is the cause.

16

Shell command

sddm-greeter --test-mode

yields the following:https://susepaste.org/images/80108746.png

17

Have you had an update to SDDM recently?

When you startup fails, ie, stops at “Starting Locale Service” switch to a virtual terminal (ctrl-alt-F2) login and issue:

sudo journalctl -b | grep -i SDDM

and see if there’s anything relevant there.

18

Paul -

Thanks for your reply - I missed it while preparing the previous two posts.

Your experience mirrors mine. My version of SDDM is 0.18.0-lp152.3.6.1. It shows up in my rpm list as being installed yesterday but AFTER my mishaps on the initial cold starts (see the 4th and 8th entries in SUSE Paste). The change log notes patches:

Add patches to fix X not having access control on startup
(boo#1177201, CVE-2020-28049):

Alternatively, I could opt for the LightDM package, but I recall during the last build researching the differences between LightDM and the SDDM and concluded that the latter was preferable. Nevertheless, I might opt for LightDM as you suggest as a temporary solution.

Thanks again.

19

Paul -

I did find entries in the warn log:

2020-11-07T07:21:45.583888-05:00 linux-5 sddm-greeter[1724]: QObject: Cannot create children for a parent that is in a different thread.#012(Parent is QGuiApplication(0x7ffefd445690), parent's thread is QThread(0x55c8c0f04f30), current thread is QThread(0x55c8c1011560)
2020-11-07T07:21:45.589929-05:00 linux-5 sddm-greeter[1724]: message repeated 3 times:  QObject: Cannot create children for a parent that is in a different thread.#012(Parent is QGuiApplication(0x7ffefd445690), parent's thread is QThread(0x55c8c0f04f30), current thread is QThread(0x55c8c1011560)]
2020-11-07T07:21:45.590333-05:00 linux-5 sddm-greeter[1724]: QObject::installEventFilter(): Cannot filter events for objects in a different thread.
. . .
2020-11-07T07:22:36.374945-05:00 linux-5 sddm-greeter[1724]: QObject::connect: No such signal QDBusAbstractInterface::DeviceAdded(QString)
2020-11-07T07:22:36.375285-05:00 linux-5 sddm-greeter[1724]: QObject::connect: No such signal QDBusAbstractInterface::DeviceRemoved(QString)
. . .
2020-11-07T07:28:37.535969-05:00 linux-5 sddm-greeter[1756]: QObject: Cannot create children for a parent that is in a different thread.#012(Parent is QGuiApplication(0x7fff23a781f0), parent's thread is QThread(0x55e691481f30), current thread is QThread(0x55e69158e930)
2020-11-07T07:28:37.541983-05:00 linux-5 sddm-greeter[1756]: message repeated 3 times:  QObject: Cannot create children for a parent that is in a different thread.#012(Parent is QGuiApplication(0x7fff23a781f0), parent's thread is QThread(0x55e691481f30), current thread is QThread(0x55e69158e930)]
2020-11-07T07:28:37.542321-05:00 linux-5 sddm-greeter[1756]: QObject::installEventFilter(): Cannot filter events for objects in a different thread.
. . .
2020-11-07T07:28:53.202684-05:00 linux-5 sddm-greeter[1756]: file:///usr/share/sddm/themes/breeze-openSUSE/components/UserDelegate.qml:55:9: QML Image: Cannot open: file:///usr/share/sddm/themes/breeze-openSUSE/faces/.face.icon
2020-11-07T07:28:53.464401-05:00 linux-5 sddm-greeter[1756]: file:///usr/share/sddm/themes/breeze-openSUSE/components/UserDelegate.qml:55:9: QML Image: Cannot open: file:///usr/share/sddm/themes/breeze-openSUSE/faces/.face.icon
2020-11-07T07:28:53.493276-05:00 linux-5 sddm-greeter[1756]: QDBusConnection: name 'org.freedesktop.UDisks2' had owner '' but we thought it was ':1.17'
2020-11-07T07:28:59.983546-05:00 linux-5 sddm-greeter[1756]: qrc:///QtQuick/VirtualKeyboard/content/components/SelectionControl.qml:80: TypeError: Cannot read property 'cursorRectIntersectsClipRect' of null
2020-11-07T07:28:59.986249-05:00 linux-5 sddm-greeter[1756]: qrc:///QtQuick/VirtualKeyboard/content/components/SelectionControl.qml:48: TypeError: Cannot read property 'anchorRectIntersectsClipRect' of null
2020-11-07T07:28:59.986546-05:00 linux-5 sddm-greeter[1756]: qrc:///QtQuick/VirtualKeyboard/content/components/SelectionControl.qml:80: TypeError: Cannot read property 'cursorRectIntersectsClipRect' of null
2020-11-07T07:28:59.986788-05:00 linux-5 sddm-greeter[1756]: qrc:///QtQuick/VirtualKeyboard/content/components/SelectionControl.qml:48:
. . .
2020-11-07T13:27:05.627248-05:00 linux-5 sddm-greeter[1732]: QXcbConnection: Could not connect to display :0
2020-11-07T13:27:05.627556-05:00 linux-5 sddm-greeter[1732]: Could not connect to any X display.
2020-11-07T13:27:05.664177-05:00 linux-5 sddm[1407]: Auth: sddm-helper exited with 1
. . .
2020-11-07T13:30:00.876047-05:00 linux-5 sddm-greeter[1735]: QXcbConnection: Could not connect to display :0
2020-11-07T13:30:00.876407-05:00 linux-5 sddm-greeter[1735]: Could not connect to any X display.
2020-11-07T13:30:00.911358-05:00 linux-5 sddm[1407]: Auth: sddm-helper exited with 1
. . .
2020-11-07T13:49:19.017951-05:00 linux-5 sddm-greeter[1872]: QXcbConnection: Could not connect to display :0
2020-11-07T13:49:19.018186-05:00 linux-5 sddm-greeter[1872]: Could not connect to any X display.
2020-11-07T13:49:19.055409-05:00 linux-5 sddm[1558]: Auth: sddm-helper exited with 1
. . .
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
. . 
2020-11-07T14:11:58.459148-05:00 linux-5 sddm-greeter[1856]: QObject: Cannot create children for a parent that is in a different thread.#012(Parent is QGuiApplication(0x7ffdc56eea00), parent's thread is QThread(0x5592361acf30), current thread is QThread(0x5592362b65e0)
2020-11-07T14:11:58.465166-05:00 linux-5 sddm-greeter[1856]: message repeated 3 times:  QObject: Cannot create children for a parent that is in a different thread.#012(Parent is QGuiApplication(0x7ffdc56eea00), parent's thread is QThread(0x5592361acf30), current thread is QThread(0x5592362b65e0)]
2020-11-07T14:11:58.465439-05:00 linux-5 sddm-greeter[1856]: QObject::installEventFilter(): Cannot filter events for objects in a different thread.
2020-11-07T14:11:59.046607-05:00 linux-5 udisksd[1863]: Can't load configuration file /etc/udisks2/udisks2.conf
2020-11-07T14:11:59.782498-05:00 linux-5 sddm-greeter[1856]: file:///usr/share/sddm/themes/breeze-openSUSE/components/UserDelegate.qml:55:9: QML Image: Cannot open: file:///usr/share/sddm/themes/breeze-openSUSE/faces/.face.icon
2020-11-07T14:12:00.048416-05:00 linux-5 sddm-greeter[1856]: file:///usr/share/sddm/themes/breeze-openSUSE/components/UserDelegate.qml:55:9: QML Image: Cannot open: file:///usr/share/sddm/themes/breeze-openSUSE/faces/.face.icon
2020-11-07T14:12:00.076996-05:00 linux-5 sddm-greeter[1856]: QDBusConnection: name 'org.freedesktop.UDisks2' had owner '' but we thought it was ':1.18'
2020-11-07T14:13:20.599129-05:00 linux-5 systemd[1]: dev-disk-by\x2dlabel-WD750.device: Job dev-disk-by\x2dlabel-WD750.device/start timed out.
2020-11-07T14:13:20.599589-05:00 linux-5 systemd[1]: Timed out waiting for device dev-disk-by\x2dlabel-WD750.device.
2020-11-07T14:13:20.599895-05:00 linux-5 systemd[1]: Dependency failed for /z/WD750.
2020-11-07T14:14:44.936013-05:00 linux-5 sddm-greeter[1856]: qrc:///QtQuick/VirtualKeyboard/content/components/SelectionControl.qml:80: TypeError: Cannot read property 'cursorRectIntersectsClipRect' of null
2020-11-07T14:14:44.936294-05:00 linux-5 sddm-greeter[1856]: qrc:///QtQuick/VirtualKeyboard/content/components/SelectionControl.qml:48: TypeError: Cannot read property 'anchorRectIntersectsClipRect' of null
2020-11-07T14:14:44.936516-05:00 linux-5 sddm-greeter[1856]: qrc:///QtQuick/VirtualKeyboard/content/components/SelectionControl.qml:80: TypeError: Cannot read property 'cursorRectIntersectsClipRect' of null
2020-11-07T14:14:44.936744-05:00 linux-5 sddm-greeter[1856]: qrc:///QtQuick/VirtualKeyboard/content/components/SelectionControl.qml:48: TypeError: Cannot read property 'anchorRectIntersectsClipRect' of null

I believe that some of these errors have appeared in prior warn logs, before the failure of the sddm greeter screen to appear after the booting sequence.

20

In my case the problem occurred after the version including that patch was installed - but only on one of my Leap 15.2 machines (with Nvidia proprietary driver), the other machine, with AMD graphics is fine. I’ve raised a bug report 1178543 – SDDM 0.18.0-lp152.5.3.1 Fails to display login screen with Nvidia Graphics. and will await the outcome.

I won’t know until I reboot or do another cold start (which I’m not anxious to do).

I appreciate your reluctance to reboot. Assuming you are seeing the same problem as I, then when the startup halts at “Starting Locale Service” you should be able to switch to a virtual terminal, change the DM to LightDM and then reboot.

Alternatively, I also found that downgrading SDDM to 0.18.0-lp152.4.11 (in the Main Repository rather than the Main Update Repository) also “cured” the problem.

Alternatively, I could opt for the LightDM package, but I recall during the last build researching the differences between LightDM and the SDDM and concluded that the latter was preferable. Nevertheless, I might opt for LightDM as you suggest as a temporary solution.

Yes, I prefer SDDM, but at the end of the day I want a DM that works, I’ve had odd problems with SDDM in the past and LightDM is a reliable fallback on such occasions.