I’m experiencing a strange authentication issue after upgrading to Fedora 44 KDE, and I’m trying to determine whether it’s a KDE/Qt regression or something specific to my system.
System
Fedora 44 KDE
Wayland
Issue started after upgrading to Fedora 44
Problem
After the laptop has been locked for some time (especially after suspend), the first password attempt on the KDE lock screen always fails, even though I’m certain the password is correct.
The second attempt succeeds with the exact same password.
Things I’ve noticed
The problem only happens on the KDE lock screen.
It does not happen on the SDDM login screen after a reboot.
If I lock and immediately unlock the screen, authentication works on the first try.
The issue appears only after the screen has been locked for a while or after waking from suspend.
The most interesting observation is that if I type my password, click the “show password” (eye) button, verify it is correct, and then press Enter, it authenticates successfully on the first attempt every time.
Logs
The journal shows the first authentication being rejected by PAM:
kscreenlocker_greet: pam_unix(kde:auth): authentication failure
unix_chkpwd: password check failed for user
A few seconds later, entering the same password succeeds.
The suspend/resume sequence itself appears clean, with no kernel, GPU, or SDDM errors.
What I’ve tried
Verified the password is correct.
Reproduced the issue multiple times.
Confirmed it only affects the lock screen.
Collected journalctl logs around the failed authentication.
Has anyone else seen this on Fedora 44 KDE? Does this sound like a known kscreenlocker/Qt input field regression, or is there anything else I should investigate?
Any suggestions for additional debugging or a possible fix would be appreciated.
I have this issue as well. In my case, using the eye to reveal the password has no effect; it will still fail the first attempt.
My journal looks slightly different:
user@localhost:~$ journalctl -b 0 | grep kscreenlocker
Aug 10 11:54:34 localhost kscreenlocker_greet[3852]: Icon theme "Breeze" not found.
Aug 10 11:54:43 localhost kscreenlocker_greet[3852]: pam_unix(kde:auth): unexpected response from failed conversation function
Aug 10 11:54:43 localhost kscreenlocker_greet[3852]: pam_unix(kde:auth): conversation failed
Aug 10 11:54:43 localhost kscreenlocker_greet[3852]: pam_unix(kde:auth): auth could not identify password for [user]
I have three systems running Fedora 44 with KDE and Wayland. This issue only affects one, the AMD-based custom desktop. My laptop and prebuilt desktop are unaffected. All three have been upgraded from 39 or so via command line.
This issue is very annoying (the kind of curse I would put on my enemies) and I am eager to find a fix.
I would not limit this to KDE. In my case I had it on Gnome.
Revealing the password while clicking on the eye showed that the password was correct. However I could not use the backspace key to remove the password. And also strange was, that I can reproduce the issue with 3 different keyboards. A wireless Logitech Keyboard, a external USB Keyboard connected to the laptop and the Laptop Keyboard it selves.
I tried to log in into the terminal while pressing Ctrl & Alt & F3. The Keyboard input not showed the correct characters as input. Not even with my username. It looked like this:
login: ^[l^[u^[c^[i^[a^[n^[o (on the Username it added ^[ before every character)
I can confirm that it happens after the computer was the first time in suspend. I could not login anymore and had to reboot while pressing the power button a longer time. Point three I can not confirm, as mentioned Ctrl & Alt & F3 also not worked.
Definitely not just KDE !
In the KDE Bug it says:
I am always able to log in on the second attempt.
While in my case I just can not login back at all. I have to reboot. And I can work till I let the Laptop going back into suspend.
@ilikelinux, I think you are dealing with a different root issue, especially because my and @mihir’s logs point directly to kscreenlocker. You have something going on with your keyboard input and power management that is unique to your case.
Oh, so it’s a known kde issue, hope they fix it soon. In the mean time, if you find a workaround please do tell.
Inspired by a similar thread at the Ubuntu forums, I used passwd (as root) to “reset” my user password to my current password. I haven’t had the issue since, although there is also some factor of how many times the device sleeps per boot… maybe it helped, maybe it didn’t. I haven’t rigorously tested.
You mean I have going something on with the different keyboards I use on the same computer to the same t time!
I get this errors when I check the boot-log before getting into suspend the first time and I still can work on the machine:
journalctl --no-tail --no-hostname -S "today" -p err
-- Boot ec300d1aced34da98a93e9f599afb359 --
ago 10 20:49:26 kernel: x86/cpu: SGX disabled or unsupported by BIOS.
ago 10 20:49:26 kernel: virt/tdx: TDX not supported by the host platform
ago 10 20:49:36 bluetoothd[772]: Failed to set mode: Failed (0x03)
ago 10 20:49:45 bluetoothd[772]: Failed to add device 97:15:7F:18:92:B4 (1): Failed (0x03)
ago 10 20:50:07 gdm-password][2228]: gkr-pam: unable to locate daemon control file
ago 10 20:50:15 polkitd[787]: Error converting subject to JS object: GDBus.Error:org.freedesktop.DBus.Error.NameHasNoOwner: The connection does not exi>
ago 10 20:51:19 polkitd[787]: Error converting subject to JS object: Process 2972 terminated
ago 10 20:51:19 dbus-broker-launch[754]: Activation request for 'org.freedesktop.Avahi' failed.
ago 10 20:51:20 dbus-broker-launch[754]: Activation request for 'org.freedesktop.ColorManager' failed.
ago 10 20:51:20 dbus-broker-launch[754]: Activation request for 'org.freedesktop.nm_dispatcher' failed.
ago 10 20:51:22 kernel: watchdog: watchdog0: watchdog did not stop!
Could you guys please run the journalctl command as I did above? I want to see if you also get this gkr-pam error and dbus-broker-launch? So we can see if we are on the same page or not.
Sorry I corrected, you probably not get the GDM error if you not use GDM
I’m experiencing this intermittent issue too, where my correct password is rejected by the KDE lock screen after waking from suspend. In my case, the only solution is to reboot the system.
System: Fedora 44 / KDE Plasma 6.6.5 / Wayland. Manual locking with Meta+L works normally. The issue only occurs after suspend/resume and is intermittent. The problem persists after multiple system and kernel updates.
Journal shows:
pam_unix(kde:auth): unexpected response from failed conversation function
pam_unix(kde:auth): conversation failed
pam_unix(kde:auth): auth could not identify password for [my_laptop]
