https://bugs.kde.org/show_bug.cgi?id=481808
[email protected] changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected] --- Comment #42 from [email protected] --- I'm hitting this on a patched build, and specifically via the lid switch rather than the Sleep/Hibernate buttons — so MR 340 doesn't seem to cover this path. Setup: Arch Linux, kscreenlocker 6.7.4-1 (installed 2026-08-07, booted well after that, so the patched greeter is definitely running) KDE Plasma 6.7.x, Wayland Lenovo Yoga 9i 8th gen No fingerprint reader configured; grep -r fprint /etc/pam.d/ is empty Reproduction, 100% consistent: Close the lid → machine suspends Wait for it to fully enter sleep Open the lid to wake "Unlocking failed" shake appears before I've touched the keyboard Journal on each lid-open: kscreenlocker_greet[NNNN]: pam_unix(kde:auth): unexpected response from failed conversation function kscreenlocker_greet[NNNN]: pam_unix(kde:auth): conversation failed kscreenlocker_greet[NNNN]: pam_unix(kde:auth): auth could not identify password for [glitch] one second after systemd-logind: Lid opened. With default Arch faillock (deny=3) this locks the account after a few lid cycles. I confirmed it's the same early-conversation-cancelled mechanism described in comment 36: the authtok_err=die PAM tweak from comment 37 stops faillock counting it (no more lockout), but the spurious failure and shake on wake persist because the conversation is still started and cancelled on resume. So on the lid path the fix would need the same "don't start pam_authenticate() until a password is actually submitted" change, not just the button handling. Happy to provide full debug output from kscreenlocker_greet --testing if useful. -- You are receiving this mail because: You are watching all bug changes.
