This has basically never worked for me this year - entering the password and doing "Unlock" just results in "Unlocking failed". I just did a fresh install on top of Fedora 21 and it's still happening, so it's probably worth debugging finally. What data do you need? Reproducible: Always
There's a unit test in there, does that pass?
Yep: Test project /home/sho/devel/build/kde/workspace/plasma-workspace/ksmserver/screenlocker Start 1: ksmserver-authenticatorTest 1/4 Test #1: ksmserver-authenticatorTest ...... Passed 2.86 sec Start 2: ksmserver-logindTest 2/4 Test #2: ksmserver-logindTest ............. Passed 0.22 sec Start 3: ksmserver-ksldTest 3/4 Test #3: ksmserver-ksldTest ............... Passed 2.50 sec Start 4: ksmserver-lockWindowTest 4/4 Test #4: ksmserver-lockWindowTest ......... Passed 3.79 sec 100% tests passed, 0 tests failed out of 4 Total Test time (real) = 9.38 sec
If test work it must be in the pam setup (which the tests skip) and it failing to find the right session to launch. This is either the env var KDE_PAM_ACTION (env var, normally unset) KSCREENSAVER_PAM_SERVICE which comes from a cmake for distros to change. Mine defaults to "kde" which does not exist If that file does not exist, pam reads /etc/pam.conf for an try with that name if that does not exist, pam will pick the default; hopefully system-login you can test without accidentally locking yourself out by running "kcheckpass" (which is in libexec somewhere) with no args
ISO: neon-useredition-20170622-1018-amd64.iso Fresh install, left screen to lock. Now cannot unlock the screen when using correct password. Starting a new session as the locked user, can start a new session without issue (same password, obviously). Happy to provide logs if you let me know which ones.
I installed a fresh Neon on my Notebook and have the same issues since then. I cannot unlock the session no matter if I manually lock it or if it automatically locks. This is 100% reproducible auth.log has following entries: Jun 27 11:50:28 fred-Latitude-5580 unix_chkpwd[4062]: check pass; user unknown Jun 27 11:50:28 fred-Latitude-5580 unix_chkpwd[4063]: check pass; user unknown Jun 27 11:50:28 fred-Latitude-5580 unix_chkpwd[4063]: password check failed for user (fred) Jun 27 11:50:28 fred-Latitude-5580 kcheckpass[4039]: pam_unix(kde:auth): authentication failure; logname= uid=1000 euid=1000 tty=:0 ruser= rhost= user=fred Jun 27 11:50:28 fred-Latitude-5580 kcheckpass[4039]: Authentication failure for fred (invoked by uid 1000) My system is: Dell Latitude-5580, Core i7 internal graphics. There is a windows partition on the notebook and secure boot is enabled.
I saw the exact same thing in my auth.log, but didn't realise it would provide enough detail to the devs.
I tried the kcheckpass thing (/usr/lib/x86_64-gnu/libexec/kcheckpass) and all I got was the error "Only binary protocol supported". Does that provide any more information? What other logging can I provide?
I see the exact same thing as described in comment #4 and comment #5. And same as in comment #7, I cannot try to debug it by calling # /usr/lib64/libexec/kcheckpass Only binary protocol supported Furthermore, when the screen locks I cannot gracefully recover from it, as nvidia doesn't seem to recover from me killing X, so it necessitates a reboot. This is *extremely* annoying!! Please provide at least a way to get back into our systems while you have this sitting as "unconfirmed". Getting locked out of your open session is bad enough as it is. My system: Gentoo, no systemd, kde 17.08.0 And logs or test you need done, I can provide.
Update: Very likely a duplicate of bug #375536 I found the problem on/in my distro: wrong mode of /sbin/unix_chkpwd Status: worksforme
I don't suppose this is still happening?
Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please mark the bug as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone!
This bug has been in NEEDSINFO status with no change for at least 30 days. The bug is now closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging Thank you for helping us make KDE software even better for everyone!
*** Bug 375536 has been marked as a duplicate of this bug. ***