DESCRIPTION Closing and opening the laptop lid triggers a "unlock fail" on sddm. Closing and opening the lid several times in a row would then "lock" the account for 10 minutes, even if no bad password had been typed, nor Enter or actually trying to unlock (with the only solution being either rebooting or goint a tty as root to run faillock) STEPS TO REPRODUCE 1. Close laptop lid 2. Open laptop lid 3. repeat several times OBSERVED RESULT "Unlocking failed" under username icon. Repeating it several times will lock the account EXPECTED RESULT Not getting an "unlock failed" message and therefore being able to go back to the desktop after typing password without waiting 10 minutes SOFTWARE/OS VERSIONS Operating System: Arch Linux KDE Plasma Version: 6.7.1 KDE Frameworks Version: 6.27.0 Qt Version: 6.11.1 Kernel Version: 7.0.12-arch1-1 (64-bit) Graphics Platform: Wayland Processors: 12 × 12th Gen Intel® Core™ i7-1255U Memory: 16 GiB of RAM (15.3 GiB usable) Graphics Processor: Intel® Graphics ADDITIONAL INFORMATION Sometimes (randomly?) it also happens when suspending and waking up Also, often the "bullets" hiding the password become white and are invisible
I've had similar issues since version 6.7.0. When the computer reawakens, it tries to log in without a password. This happens most of the time, but not every time. Opening the lid can do it; typing on the keyboard can do it; jiggling the mouse can do it. I have, seemingly successfully, set the computer up to hibernate rather than sleep. Maybe it's not quite right. A log from a recent wake up is here: https://pastebin.com/nxaHM4vf Operating System: Arch Linux KDE Plasma Version: 6.7.1 KDE Frameworks Version: 6.27.0 Qt Version: 6.11.1 Kernel Version: 7.0.13-arch1-1 (64-bit) Graphics Platform: Wayland Processors: 12 × Intel® Core™ 7 150U Memory: 16 GiB of RAM (15.3 GiB usable) Graphics Processor: Intel® Graphics Manufacturer: LENOVO Product Name: INVALID System Version: INVALID
(In reply to Pedro from comment #0) > DESCRIPTION > Closing and opening the laptop lid triggers a "unlock fail" on sddm. > Closing and opening the lid several times in a row would then "lock" the > account for 10 minutes, even if no bad password had been typed, nor Enter or > actually trying to unlock (with the only solution being either rebooting or > goint a tty as root to run faillock) > > STEPS TO REPRODUCE > 1. Close laptop lid > 2. Open laptop lid > 3. repeat several times > > OBSERVED RESULT > "Unlocking failed" under username icon. Repeating it several times will lock > the account > > EXPECTED RESULT > Not getting an "unlock failed" message and therefore being able to go back > to the desktop after typing password without waiting 10 minutes > > SOFTWARE/OS VERSIONS > Operating System: Arch Linux > KDE Plasma Version: 6.7.1 > KDE Frameworks Version: 6.27.0 > Qt Version: 6.11.1 > Kernel Version: 7.0.12-arch1-1 (64-bit) > Graphics Platform: Wayland > Processors: 12 × 12th Gen Intel® Core™ i7-1255U > Memory: 16 GiB of RAM (15.3 GiB usable) > Graphics Processor: Intel® Graphics > > ADDITIONAL INFORMATION > Sometimes (randomly?) it also happens when suspending and waking up > > Also, often the "bullets" hiding the password become white and are invisible EDIT: Earlier I assumed I was using sddm, but no, it was actually plasma-login-manager
> "Unlocking failed" under username icon. I can't reproduce this issue on KDE Linux. > Also, often the "bullets" hiding the password become white and are invisible This I can reproduce though. But only sometimes. I haven't found the pattern yet.
(In reply to Nate Graham from comment #3) > > "Unlocking failed" under username icon. > I can't reproduce this issue on KDE Linux. > Here's the bug on video, if it helps: https://youtu.be/qbNw1Tezi80
I can replicate. Here is some journalctl. (I haven't used bugzilla much, and I hope it's ok to paste this) Jun 26 14:58:27 MasterControlUnit kernel: PM: suspend exit Jun 26 14:58:27 MasterControlUnit kernel: usb 3-3: New USB device found, idVendor=06cb, idProduct=00fc, bcdDevice= 0.00 Jun 26 14:58:27 MasterControlUnit kernel: usb 3-3: New USB device strings: Mfr=0, Product=0, SerialNumber=1 Jun 26 14:58:27 MasterControlUnit kernel: usb 3-3: SerialNumber: 89c3564e7de3 Jun 26 14:58:27 MasterControlUnit mtp-probe[36234]: checking bus 3, device 10: "/sys/devices/pci0000:00/0000:00:14.0/usb3/3-3" Jun 26 14:58:27 MasterControlUnit mtp-probe[36234]: bus: 3, device: 10 was not an MTP device Jun 26 14:58:27 MasterControlUnit systemd[1]: user.slice: Unit now thawed. Jun 26 14:58:27 MasterControlUnit systemd[1]: user-1000.slice: Unit now thawed. Jun 26 14:58:27 MasterControlUnit systemd[1]: session-2.scope: Unit now thawed. Jun 26 14:58:27 MasterControlUnit systemd[1]: user@1000.service: Unit now thawed. Jun 26 14:58:27 MasterControlUnit systemd-sleep[36148]: Successfully thawed unit 'user.slice'. Jun 26 14:58:27 MasterControlUnit systemd[1]: systemd-suspend.service: Deactivated successfully. Jun 26 14:58:27 MasterControlUnit systemd[1]: Finished System Suspend. Jun 26 14:58:27 MasterControlUnit systemd[1]: Stopped target Sleep. Jun 26 14:58:27 MasterControlUnit org_kde_powerdevil[1648]: [ 1709][78616.619873] (ldbus_handle_message)Received dbus signal PrepareForSleep(false=resume) Jun 26 14:58:27 MasterControlUnit systemd[1]: Reached target Suspend. Jun 26 14:58:27 MasterControlUnit systemd-logind[837]: Operation 'suspend' finished. Jun 26 14:58:27 MasterControlUnit systemd[1]: Stopped target Suspend. Jun 26 14:58:27 MasterControlUnit NetworkManager[835]: <info> [1782511107.8486] manager: sleep: wake requested (sleeping: yes enabled: yes) Jun 26 14:58:27 MasterControlUnit NetworkManager[835]: <info> [1782511107.8487] device (wlan0): state change: unmanaged -> unavailable (reason 'managed', managed-type: 'external') Jun 26 14:58:27 MasterControlUnit NetworkManager[835]: <info> [1782511107.8502] device (p2p-dev-wlan0): state change: unmanaged -> unavailable (reason 'managed', managed-type: 'external') Jun 26 14:58:27 MasterControlUnit NetworkManager[835]: <warn> [1782511107.8503] device (p2p-dev-wlan0): error setting IPv4 forwarding to '0': Resource temporarily unavailable Jun 26 14:58:27 MasterControlUnit NetworkManager[835]: <info> [1782511107.8504] manager: NetworkManager state is now DISCONNECTED Jun 26 14:58:27 MasterControlUnit rtkit-daemon[1511]: Resuming known real-time threads. Jun 26 14:58:27 MasterControlUnit rtkit-daemon[1511]: Successfully made thread 25981 of process 25647 owned by '1000' RT at priority 10. Jun 26 14:58:27 MasterControlUnit rtkit-daemon[1511]: Successfully made thread 20191 of process 19603 owned by '1000' RT at priority 10. Jun 26 14:58:27 MasterControlUnit rtkit-daemon[1511]: Successfully made thread 2794 of process 2396 owned by '1000' RT at priority 10. Jun 26 14:58:27 MasterControlUnit rtkit-daemon[1511]: Successfully made thread 2557 of process 2396 owned by '1000' RT at priority 10. Jun 26 14:58:27 MasterControlUnit rtkit-daemon[1511]: Successfully made thread 1680 of process 1673 owned by '1000' RT at priority 20. Jun 26 14:58:27 MasterControlUnit rtkit-daemon[1511]: Successfully made thread 1673 of process 1673 owned by '1000' high priority at nice level -11. Jun 26 14:58:27 MasterControlUnit rtkit-daemon[1511]: Successfully made thread 1519 of process 1505 owned by '1000' RT at priority 20. Jun 26 14:58:27 MasterControlUnit rtkit-daemon[1511]: Successfully made thread 1505 of process 1505 owned by '1000' high priority at nice level -11. Jun 26 14:58:27 MasterControlUnit rtkit-daemon[1511]: Successfully made thread 1510 of process 1504 owned by '1000' RT at priority 20. Jun 26 14:58:27 MasterControlUnit rtkit-daemon[1511]: Successfully made thread 1504 of process 1504 owned by '1000' high priority at nice level -11. Jun 26 14:58:27 MasterControlUnit rtkit-daemon[1511]: Resumed scheduling 10 threads. Jun 26 14:58:27 MasterControlUnit kdeconnectd[1837]: Failed to open any MDNS client sockets Jun 26 14:58:27 MasterControlUnit kdeconnectd[1837]: Failed to open any MDNS server sockets Jun 26 14:58:27 MasterControlUnit kdeconnectd[1837]: No local bluetooth adapter found Jun 26 14:58:27 MasterControlUnit kdeconnectd[1837]: No local bluetooth adapter found Jun 26 14:58:27 MasterControlUnit kscreenlocker_greet[36114]: pam_unix(kde:auth): unexpected response from failed conversation function Jun 26 14:58:27 MasterControlUnit kscreenlocker_greet[36114]: pam_unix(kde:auth): conversation failed Jun 26 14:58:27 MasterControlUnit kscreenlocker_greet[36114]: pam_unix(kde:auth): auth could not identify password for [myuser]
Weird, I just encountered the issue this morning when I opened my laptop — once! It hasn't happened since then on subsequent wake-ups due to opening the lid.
(In reply to Nate Graham from comment #6) > Weird, I just encountered the issue this morning when I opened my laptop — > once! It hasn't happened since then on subsequent wake-ups due to opening > the lid. I've found the bug an happen even without closing the lid, just by waking it up after suspension (wake it up, but go away, come back later, wake up again...)
That sounds related to Bug 481808, which is 100% reproducible. There definitely seems to be something about going to sleep on the lock screen that triggers a failed login — and this interacts poorly with systems set up to lock the user out after a certain number of failed logins.
*** This bug has been marked as a duplicate of bug 521900 ***