Successful login using SDDM sometimes gives a blank screen

English Install/Boot/Login
1

I’ve just installed Leap 15.4 and found a variation of seemingly related problems involving the SDDM display manager which have been reported over the years, including these:

The latter post begins:

So… because of this long lasting bug (s): Bug 1207906 – Wayland crashes when automatic authentication via SDDM with Wayland is enabled. I can’t autologin into Plasma/Wayland with SDDM. I’ve been googling as to how to switch my display manager to LightDM, but information on that is lacking. (I have installed LightDM.)

My problem is that Leap 15.4 using SDDM occasionally displays a blank screen after a valid login, though other display managers work. I haven’t surveyed the numerous posts possibly relevant to SDDM but can add the following.

When SDDM gets into this state, it usually seems to apply to one user, who gets a blank screen while others work normally. However it’s not user-dependent, and sometimes more than one login user can be affected concurrently, including the root user.

If the user does nothing after logging in (for ~5 to 10 minutes in my case), they may eventually be rewarded with a normal Plasma session having their usual wallpaper, icon arrangements, task bar, etc. It’s as though some timeout occurs, or maybe the screen energy-saving process kicks in and moving the mouse then brings SDDM back to normal operation. Or something…

In another post at How to change Display Manager from SDDM to LightDM on Plasma Tumbleweed - #11 by arvidjaar deano_ferrari suggests installing LightDM:

There is no need to configure LightDM. In an effort to assist I just installed the LightDM display manager and selected it with ‘update-alternatives’. At the login screen it is possible to choose ‘Plasma (X11)’ or Plasma (Wayland)’ at top right of screen. The session type should remain as chosen following a reboot. The previous session state is stored in /var/lib/lightdm/.cache/lightdm-gtk-greeter/state.

I can confirm that works. Once “Plasma X11” on the LightDM login screen is chosen it sticks across logins. The subsequent Plasma session inherits its usual configuration, though some animated screen effects may not work (?).

I’m surprised this SDDM bug has lasted so long, especially since SDDM seems to be the default display manager in Leap 15.4. (I’m also surprised to see KDE’s KDM3 DM is available for Leap 15.4 from the KDE repository, although it may not be officially supported.)

2

SDDM is a KDE project, thus the reason it’s the default for Plasma users. I find it unworthy of use except on one single installation merely to be able to see how it works, or not. Everything else here uses KDM3, KDM4, LightDM or XDM.

No newer display manager provides the wealth of features and configurability of KDM. Fedora 38 beta still provides the latest version made available before upstream support was discontinued. Not only is KDM3 still available from openSUSE, but its fork TDM is available for several distributions, including openSUSE Leap and TW.

As to KDM3 support, it shouldn’t be needed. It hasn’t had any feature changes since before upstream discontinued support. All changes since are about conforming to newer build tools and supporting environment.

Now this forum won’t let me paste in any URI; either I must type the whole thing in, or do without. :frowning:

1 Like
3

I see… thanks for your reply, mrmazda! According to the SDDM description in Yast, “SDDM is a display manager for X11. It uses technologies like QtQuick, which in turn gives the designer the ability to create animated user interfaces.” Since I dislike animated user interfaces and deselect all those ticked by default in Plasma, that’s no loss.

LightDM seems to be fairly self-contained and doesn’t employ any external software-bus technology (such as QtQuick) as far as I can tell. I understand KDM3 uses the well-proven Qt bus.

So I installed KDM3. I see it offers all the desktop-environment options in one drop-down menu, including “Plasma X11” and “Plasma X11 (previous)” Does anyone know the difference in any detail? “Plasma X11 (previous” works fine so far, and I’ll see how it goes.

If another black-screen login occurs, I think the finger of suspicion will point to Plasma.

The bad news is that I had a black-screen login using LightDM. The usual symptoms occurred, and my normal Plasma-X11 screen appeared after about 7 minutes of darkness, but it may have been more because it’s unclear what timer is involved. I notice the splash screen seems to run for much longer when trouble occurs; if the delay were as long as 10 minutes (my display energy-saving timeout) it could be that’s what wakes LightDM & SDDM up.

4

Which points to a possible hardware issue –

  • You’ll have to check the systemd Journal for possible entries pointing to a hardware issue.
    Could be a Graphics Unit which is misbehaving …

Apart from that, check the cables and connectors between the graphics unit and the display –

  • Dirty pins and/or sockets and/or bent pins …
  • Flaky cable – some cables have extremely small conductors which can break …
5

Yes, I’ve wondered about that. However the problem occurred again when I logged on to this Plasma-X11 session using KDM3. But (and I think this has happened once before) I had logged out some hours ago leaving Firefox maximized, and this time the Firefox window & cursor was displayed on an otherwise black screen. Not only that, Firefox seemed to be functioning normally; it updated the window with your post and responded to the mouse. After about 6 minutes the full display “infrastructure” (wallpaper, task bar, icons, etc.) reappeared.

One other detail I forgot to mention: the black screen does include the cursor, and it responds to mouse movements.

Is this starting to sound like a timing bug, maybe a race condition?

The HP desktop is a recent WIndows-11 box, but Leap 15.4 was installed over the top, not as a Windows-10 / Linux O/S. The HP dsiplay is a few years old, with selectable HDMI, DisplayPort, and VGA input options. I’m using the DisplayPort input, and have the HDMI port connected to the old Leap 15.3 system on 8-year old hardware, which has never had this issue.

Unless the Brains Trust has any other suggestions, I’ll begin by checking the new Desktop’s display outputs: it has 2x DisplayPort outputs which I assume run in parallel so either one can be used. I’ll also upgrade the old 15.3 Desktop to 15.4 and see if the problem appears with the upgrade.

6

I’d noticed an update installed on 16th included ‘xorg-x11’ and ‘xorg-scripts’ and, since the problem had not recurred for 5 days, I put it on the back burner. But this morning - there it was again.

But dcurtisfra is right: apparently systemd is trying to start services related to bluetooth but no bluetooth adapter is present.

When I bought this HP box it had Windows-11 installed, and I understood the bluetooth & mobile adapter with its associated antennas was standard. In any case they were not installed in the box on delivery and not included separately, maybe because I had a discussion with the supplier about how difficult it would be to remove this support when ordering it.

Nevertheless, the Leap 15.4 services manager attempts to start bluetooth despite there being no adapter present. For what it’s worth, the O/S is loaded using UEFI and “HP Safe Start”, and Linux was installed over the top of Windows. A listing of journal errors at warning-level or above shows:
at 11:09:17 kded5 failed to activate service ‘org,bluez’
at 11:15:14 plasmashell was “trying to show an empty dialog” - (that’s presumably where the 6 minutes of blank screen originates)

I’d like to remove bluez and dependent packages (including Plasma bluetooth support), but first have to remove bluetooth and mobile support from the system-alternatives. Is there a single group name for these in the 'update-alternatives --config" CLI command, and where can I find what it is?

Do I have to remove bluetooth & mobile support from UEFI and/or HP Sure Start? This is outside my area of expertise, so I’ll be glad of any pointers.

7

Some displays do not play reliably when more than one input source is physically connected, whether or not powered up. My NEC EA243WM is really fussy about this. I must make sure only one of its 4 inputs is physically connected if I want it to produce anything but black on powering up whatever is connected to it.

8

Until yesterday, a second computer was connected to another display port, but only one was powered on at a time. However this morning’s failure occurred with the inactive computer in a cupboard; its’ end of the HDMI video cable was in fresh air. (The display’s menu allows users to select one input from VGA, HDMI, or DisplayPort, however it was connected using a screen (HDMI) to DisplayPort (computer) cable if that’s relevant.

Thanks for the hint though mrmazda, only one video cable is mow physically attached to the display. The WiFi issue has to be resolved though as it looks a bit suspicious.

9

Due to the dependencies within KDE Plasma and Pulse Audio, it usually doesn’t pay to attempt to remove the Bluetooth relevant packages installed on the system.

  • Here on this Leap 15.4 Desktop – a Leap 15.4 Laptop with Bluetooth hardware is different:
 > systemctl list-unit-files | grep -i 'blue'
bluetooth-mesh.service                                                    disabled        disabled
bluetooth.service                                                         enabled         disabled
dbus-org.bluez.service                                                    alias           -
bluetooth.target                                                          static          -
 > 
 > systemctl --user list-unit-files | grep -i 'blue'
bluetooth.target                                                      static    -
 >

 # journalctl -b 0 --output=short-monotonic --no-hostname | grep -iE 'tooth|bluez' -B 1 -A 1
[ 3552.503684] rtkit-daemon[4658]: Supervising 4 threads of 1 processes of 1 users.
[ 3552.509480] dbus-daemon[977]: [system] Activating via systemd: service name='org.bluez' unit='dbus-org.bluez.service' requested by ':1.66' (uid=1000 pid=4651 comm="/usr/bin/pulseaudio --daemonize=no --log-target=jo")
[ 3552.512118] systemd[1]: Condition check resulted in Bluetooth service being skipped.
[ 3552.513940] kded5[4553]: Found EDID profile for device "/org/freedesktop/ColorManager/profiles/icc_393cab7476a4e85d3bbd4cfa2ef13b1b_dcu_1000" "HDMI-A-0"
--
[ 3577.516869] pulseaudio[4651]: GetManagedObjects() failed: org.freedesktop.DBus.Error.NoReply: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.
[ 3577.522820] dbus-daemon[977]: [system] Failed to activate service 'org.bluez': timed out (service_start_timeout=25000ms)
[ 3580.913689] plasmashell[4610]: file:///usr/share/plasma/plasmoids/org.kde.plasma.notifications/contents/ui/NotificationItem.qml:219:21: QML SelectableLabel: Binding loop detected for property "implicitWidth"
 # 
 # systemctl status bluetooth.service 
○ bluetooth.service - Bluetooth service
     Loaded: loaded (/usr/lib/systemd/system/bluetooth.service; enabled; vendor preset: disabled)
     Active: inactive (dead)
       Docs: man:bluetoothd(8)

Mär 21 09:53:34 eck001 systemd[1]: Condition check resulted in Bluetooth service being skipped.
 #

Why is the Bluetooth service being skipped here?

  • Because, there ain’t no Bluetooth hardware …

Furthermore, this answer: <https://wiki.archlinux.org/title/Bluetooth#systemd:_Condition_check_resulted_in_Bluetooth_service_being_skipped>

In other words:

  • ‘/sys/class/bluetooth’ doesn’t exist because, udev didn’t find any Bluetooth hardware and therefore, there ain’t, in addition to and also, no Bluetooth Kernel Module loaded …

Therefore, no Bluetooth hardware present, no Bluetooth system services executing, everyone is happy … :sunglasses:

10

Thanks for your comprehensive response!

I wondered whether that was the case. I’ll see if the problem recurs now I’ve removed the floating HDMI cable from the display.

Just as a personal comment on this Distribution, loading up system resources with support for wireless devices when there’s no Bluetooth / WiFi support in the hardware can’t add to overall system reliability. And if a wireless-access device can be plugged into a USB port, the system presents another, rather vulnerable, attack surface.

Is there any book or downloadable reference manual which describes the design principles of the OpenSuSE distribution while still providing this level of detail?

11

Unfortunately, the Bluetooth packages are pulled in by the KDE Plasma dependencies – upstream dependencies …

  • Network management tools have dependencies which pull in WiFi/WLAN packages – for support which is in the Kernel anyway …
12

Only if, either a user or, the system administrator, sets up a WLAN Access Point (Network Manager Hot Spot) on that device.

  • If the system has been secured then, “normal” users will not be able to use all the Network Manager functionality.
13

It does.

I’m now back to SDDM. I’ve probably spent days trying to isolate this problem without success. It sounds similar to the one reported by Marvo22 at https://forums.opensuse.org/t/leap-15-4-upgrade-failure-login-hangs-up/151875/19 but that discussion doesn’t come to any definite conclusion as far as I can see.

However I’d appreciate an answer to this: The ‘Login’ section of System Settings allows services to be disabled, including Bluetooth, Wacom tablet, & Touchpad which are not relevant on this system, but without root privilege. So what does it actually do? Obviously, disabling Bluetooth disables it system-wide and requires root privilege, so does it just disable access by the particular user and, if so, how? Polkit?

If I remember correctly, the Trinity desktop is a code fork from KDE4 (or KDE3?) and I’m beginning to think I should check it out. It would be interesting to know what percentage of users find all the audio-visual bells & whistles functions of Plasma / SDDM really useful.

14

The forking was from 3.5.10. Current TDE is 14.0.13, with 14.1.0 release due this month.

KDE3 remains available for Leap and TW.

Most of my installations are using TDM or KDM3 rather than SDDM or LightDM whether or not I have Plasma installed.

15

The KDE Plasma System Settings → Workspace → Startup and Shutdown → Background Services section only allows an individual user to define which KDE Plasma services shall be automatically loaded at login – whether or not they’ll automatically begin executing or not depends on the available hardware and, the PolKit settings maintained by the System Administrator.

16

The information is spread through a couple of the Guides – <https://doc.opensuse.org/> – the following guides contain most of the information you’re seeking:

  • Reference Guide
  • Security Guide
  • System Analysis and Tuning Guide

Apart from that, there’s the openSUSE Mailing Lists: <https://lists.opensuse.org/archives/>

17

Many thanks for all your help, ‘dcurtisfra’ and ‘mrmazda’! I’ll give it a rest until I manage to clearly identify the cause of the problem.

When this problem occurs, the key thing is this: If I log out of a session and/or shut down the system leaving (say) a Firefox and email window raised, then log in again, these windows will be displayed and respond to the mouse & keyboard normally BUT with the rest of the screen black. (Note, the previous sessions is saved and restarted on login.)

It’s as though something fails to restore the session “infrastructure” (wallpaper, task bar, icons, etc.). I think this behavious is entirely consistent with that described by Marvo22.

It is convenient to have all the usual icons on the task bar on login, but I think I’ll set my login to always start a new session rather than pick up the previous one. If the problem consistently (if randomly) occurs running SDDM but not KMD3, then that probably indicates an SDDM bug.

18

I now have a working hypothesis which might explain the problem defined in the previous post, and I’d appreciate any comments Forum members might have.

In short, this computer runs something known as “HP Sure Start” when it’s powered up. I know very little about the product, but I understand it’s implemented in BIOS firmware. According to the HP Infosheet at https://h20195.www2.hp.com/v2/GetDocument.aspx?docname=4AA7-2562ENW

HP Sure Start [1} is an advanced hardware-enforced solution providing comprehensive firmware and firmware setting security. Starting as the world’s first self-healing BIOS, HP Sure Start now extends beyond the BIOS to protect critical firmware that antivirus solutions can’t protect. Providing hardware enforced self-healing protection of boot-critical firmware from malware, rootkits, or corruption to help you maintain business continuity in the face of destructive attacks to the firmware.

I suspect what happens is that any change to certain software components, including the display manager, flags a warning to the SureStart firmware which then fails to hand control over to the O/S. This even extends to any user who ends their session by shutting down the system rather than logging out and then powering it down.

It may also explain some other mystifying symptoms. For example, the Linux O/S will probably trundle on regardless, and any applications raised when a user’s session ends will reappear and respond normally to mouse & keyboard input, but no desktop furniture (wallpaper, task bar, icons, etc) will be present because SureStart has dropped its X11 session.

Why the full desktop is recreated after perhaps 5-10 minutes possibly has something to do with O/S power-management and screen-inactivity timeout. But it’s comparable with X11 retry-timeout attempts used by KDM3. (This is getting way past my knowledge of O/S & X11 implementation details!)

Two other points, if I may.

I suggest anyone who would like to investigate this should set
System Settings > Startup and Shutdown > Desktop Session > “When logging in”
to begin a new session, otherwise things can become really confusing.

Finally, I’m impressed with LightDM as a display manager, particularly when the ‘lightdm-gtk-greeter-settings’ GUI is installed.

Any comments anyone?

19

My newest HP is 12-13 years old, so no Sure Start here to play with.

I too prefer LightDM to SDDM. I like KDM3/TDM better because the original non-themed default theme was perfectable when introduced, perfected with a few little edits to kdmrc, and remains so, so that’s what I use on most installations, leaving the few others as mere samples of what the rest of the world is saddled with, most using a whole display screen to present what fits perfectly fine into a 3x5 or 4x6 card space in the middle of a KDM screen.

20

AFAICS, this is a HP BIOS/UEFI feature on top of “Secure Boot” and “Trusted Platform Computing”.

  • It seems to detect BIOS firmware changes during the system boot (possibly, simply, by means of a checksum) – if a change is detected then, a previous (presumably “known good”) BIOS version is activated and used.

From what you’re describing, by means of the libraries provided by the “libsmbios_c2” package, the Linux system programs are accessing the HP BIOS by means of the SMBIOS (System Management BIOS) interface and causing the HP Sure Start feature to behave in an undesirable manner.

  • The problem now is, how to test and confirm this issue?