SUMMARY After an upgrade from Neon Jammy to Neon noble, for some reason, PAM was still configured with pam_sss and pam_fprintd, though these libraries were removed as part of the upgrade. After that, putting the laptop to sleep, by closing the screen, and then trying to resume - would fail with a blank screen with a cursor, necessitating a hard reset or some sophisticated circumvention (logging in through a text VT and killing kwin_wayland has proven to be a not seriously terrible workaround, just terrible). STEPS TO REPRODUCE 1. Install libpam-fprintd and configure it, for example as per https://wiki.archlinux.org/title/SDDM#Using_a_fingerprint_reader 2. Uninstall libpam-fprintd 3. Suspend the system 4. Resume the system OBSERVED RESULT A blank screen with a mouse cursor appears EXPECTED RESULT The lock prompt should appear SOFTWARE/OS VERSIONS Linux/KDE Plasma: Neon release KDE Plasma Version: 6.2.2 KDE Frameworks Version: 6.8.0 Qt Version: 6.7.2 ADDITIONAL INFORMATION When the system resumes, the following log lines are shown in the `plasma-kwin_wayland.service` log: Oct 27 23:20:32 thunderbird kscreenlocker_greet[76003]: PAM unable to dlopen(pam_sss.so): /usr/lib/security/pam_sss.so: cannot open shared object file: No such file or directory Oct 27 23:20:32 thunderbird kscreenlocker_greet[76003]: PAM adding faulty module: pam_sss.so Oct 27 23:20:32 thunderbird kscreenlocker_greet[76003]: PAM unable to dlopen(pam_fprintd.so): /usr/lib/security/pam_fprintd.so: cannot open shared object file: No such file or directory Oct 27 23:20:32 thunderbird kscreenlocker_greet[76003]: PAM adding faulty module: pam_fprintd.so
I am struggling to think of reasons why this isn't something distros should be trusted to get right. And for users who configured it themselves, they're on the hook! We could maybe make it more robust in KScreenlocker code to make it easier for them.
The problem is that the system is broken, and it isn't clear that it's the user's/distro fault and what needs fixing, and how. The example, `loginctl unlock-session` doesn't work. It took me quite a while to figure out that the problem is the screen locker, and that it was the pam error messages that are related. I remember there used to be a behaviour, when the screen locker would have a problem - you'd get a black screen with a message "the lock screen is broken, switch to a virtual terminal and run loginctl unlock-session", or something like that - this seems like a premise example of a situation that can benefit that from such a behaviour. I think at the minimum, there shouldn't be a lock screen issue that prevents loginctl unlock-session from working.
Ideally the distro doesn't break the user' system with packaging mistakes, of course. If it does, maybe it's not a trustworthy distro. And if the user breaks their own system, maybe they should have chosen an immutable OS distro they can't break in that way. But still, yes, we can probably try to make something as critical as the lock screen more robust.
should be fixed with https://bugs.kde.org/show_bug.cgi?id=496641
(In reply to Carlos De Maine from comment #4) > should be fixed with https://bugs.kde.org/show_bug.cgi?id=496641 While this issue was originally caused by a broken Neon configuration - and according to bug #496641, that was fixed - the actual issue isn't the fact that a pam library went missing - its the fact that a pam failure causes the lock screen to blank and be completely unresponsive, with no obvious way forward. I would consider a handling of "PAM is broken" to invoke the "lockscreen is broken" message - or some other way of a broken setup without the UI being completely borked - to be a proper fix for this issue.