Bug 1933520 - gdm login stuck in fingerprint authentication loop
Summary: gdm login stuck in fingerprint authentication loop
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: authselect
Version: 34
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Pavel Březina
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 1933595 1941033 (view as bug list)
Depends On:
Blocks: F34FinalBlocker F34FinalFreezeException
TreeView+ depends on / blocked
 
Reported: 2021-02-28 21:55 UTC by Ganapathi Kamath
Modified: 2021-04-28 09:35 UTC (History)
22 users (show)

Fixed In Version: authselect-1.2.2-5.fc34 authselect-1.2.2-2.fc33 authselect-1.2.2-6.fc34
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2021-03-05 19:16:55 UTC
Type: Bug


Attachments (Terms of Use)
GDM login failure log (47.11 KB, text/plain)
2021-03-27 18:17 UTC, cyshei
no flags Details
Another GDM log for debug purposes (49.38 KB, text/plain)
2021-03-27 21:43 UTC, Grzegorz
no flags Details
GDM log (64.23 KB, text/plain)
2021-04-20 07:24 UTC, Grey Nicholson
no flags Details


Links
System ID Private Priority Status Summary Last Updated
GNOME Gitlab GNOME/gnome-shell - merge_requests 1683 0 None None None 2021-03-02 14:13:45 UTC
freedesktop.org Gitlab libfprint/fprintd - merge_requests 126 0 None None None 2021-03-02 14:13:45 UTC

Internal Links: 1941033

Description Ganapathi Kamath 2021-02-28 21:55:30 UTC
Description of problem:
The gdm login is stuck in fingerprint authentication loop. cannot login. 
One is stuck at a login prompt. A message below the input-box says "Sorry, fingerprint authentication did not work. Please try again.

Firstly, since fresh install I never bothered with fingerprints.
In settings/users, the fingerprint login is disabled for the user (username=user), and no fingerprints have been enrolled.

This bug, happens spuriously, I suspect the issue is more likely after a few minutes after boot, or upon lockout after a login.
More often than not, the GDM GUI login prompt has jumped to finger print authentication, typing password does not help.

Inside the GDM GUI, there is no easy/direct way to escape the misery and get the usual/regular gui password login. But one may try waiting it out in the linux-console.

Under the icon/username, either the input-box for username or password is shown,
Below which, a message says "Sorry, fingerprint authentication did not work. Please try again.
Doesn't matter if one types anything or not. in about 10 seconds an attempts timed out.
It does this about three times.
After which, the prompt goes back to user select screen.

Instead of clicking user-name-icon, taking the "user not listed" route does not help, as after typing username and entering, one is back in the fingerprint authentication loop. 

Version-Release number of selected component (if applicable):
* Fedora-Workstation-Live-x86_64-34-20210225.n.1.iso
* Fresh installation on machine sony vaio vgn-sr13

How reproducible:
NA

Steps to Reproduce:
1. on boot machine up/ on lockout
2. it is possible on first boot password login works normal, on lockout of subsequent boot, this may happen

Actual results:
as described

Expected results:
want plain login/password

Additional info:

Q) How to configure to make gdm/pam/fprintd not even bother bother with fingerprints? 

*) username is "user", I hope this unusual username isn't tripping any regexps.
*) seems related to Bug 1933282 
*) Ctrl-Alt-F3 to Ctrl-Alt-F6  linux-console login works
*) one way to break the stuck in fingerprint authentication cycle, is to goto linux-console for a while. type "systemctl stop fprintd" or "killall fprintd". But the fprintd may restart. Then quickly switch back to GDM-login by using  Alt-F1. Select user 'user'. gdm brings up the regular GUI username-password login, which works, and then one gets to the desktop, with all open apps intact. 
* lsusb: Bus 001: Device 002: ID 17e:1000 Upek Biometric Touchchip/TouchStrip Fingerprint Sensor
* rpm -qa :  fprintd(1.90.9-2), fprintd-pam(1.90.9-2), pam(1.5.1-3), gdm (gdm-40~beta)

one workaround I came up with is
mv /usr/libexec/fprintd /usr/libexec/fprintd.orig
But perhaps there is a prefferrable configuration approach to this.

very annoying.
Please give me a workaround, while bug is being fixed, to surely disable the fingerprint authentication

Comment 1 Benjamin Berg 2021-03-02 14:13:45 UTC
We have had a few upstream discussions at https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1683

This is fallout triggered by a bugfix that should fix #1933282. The decision upstream was that we should fix this in pam_fprintd, by always returning PAM_AUTHINFO_UNAVAIL rather than returning PAM_USER_UNKNOWN in some situations.

Reassigning.

Comment 2 Fedora Blocker Bugs Application 2021-03-02 14:52:24 UTC
Proposed as a Blocker and Freeze Exception for 34-final by Fedora user benzea using the blocker tracking app because:

 This can make login problematic when a fingerprint reader is present but not prints are enrolled.

There is a proposed fix for pam_fprintd which is quite simple.

Comment 3 Benjamin Berg 2021-03-02 16:20:09 UTC
Turns out, the analysis was wrong.

Seems like the problem is authselect not disabling fingerprint authentication in GDM even when the fingerprint stack is disabled. This then causes the issues.

The already linked fix is still sensible (and safe), but it will not fix the problem.

Comment 4 Fabiano Fidêncio 2021-03-03 14:09:05 UTC
*** Bug 1933595 has been marked as a duplicate of this bug. ***

Comment 5 Benjamin Berg 2021-03-04 10:27:08 UTC
So, the analysis is that fingerprint authentication is disabled using authselect. This means that /etc/pam.d/fingerprint-auth is empty, returning an authentication error. However, at the same time fingerprint auth is still enabled in GDM, so it attempts to use it.

This means, that the issue will only happen if the user uses authselect to select the "minimal" profile (if that is not the case for any user here, then we likely have another issue).

There are two things we can do, the first being the most important one:
 1. Authselect needs to disable the option for GDM
 2. Authselect could ensure the fingerprint-auth stack returns a more useful error message.


I think for the first the only problem is that the "minimal" profile does not write out the appropriate dconf settings. And then you end up with the default which is to have fingerprint enabled in GDM.


The second is to change fingerprint-auth stack to return a more useful error message. This could be done by inserting
"""
auth required  pam_debug.so auth=authinfo_unavail
"""

Comment 6 Pavel Březina 2021-03-04 10:58:04 UTC
(In reply to Benjamin Berg from comment #5)
> So, the analysis is that fingerprint authentication is disabled using
> authselect. This means that /etc/pam.d/fingerprint-auth is empty, returning
> an authentication error. However, at the same time fingerprint auth is still
> enabled in GDM, so it attempts to use it.
> 
> This means, that the issue will only happen if the user uses authselect to
> select the "minimal" profile (if that is not the case for any user here,
> then we likely have another issue).
> 
> There are two things we can do, the first being the most important one:
>  1. Authselect needs to disable the option for GDM
>  2. Authselect could ensure the fingerprint-auth stack returns a more useful
> error message.
> 
> 
> I think for the first the only problem is that the "minimal" profile does
> not write out the appropriate dconf settings. And then you end up with the
> default which is to have fingerprint enabled in GDM.

https://github.com/authselect/authselect/issues/237

I'm going to fix #237 soon as a fix for this BZ.


> The second is to change fingerprint-auth stack to return a more useful error
> message. This could be done by inserting
> """
> auth required  pam_debug.so auth=authinfo_unavail
> """

https://github.com/authselect/authselect/issues/238

This one will be implemented later.

Comment 7 Pavel Březina 2021-03-04 11:07:28 UTC
* `master`
  * 41197d567e0ef15cdd50b9e7658e9a0b205e6683 - minimal: add dconf settings to explicitly disable fprint and smartcard authentication

Comment 8 Fedora Update System 2021-03-04 11:35:44 UTC
FEDORA-2021-d2afa6dc55 has been submitted as an update to Fedora 34. https://bodhi.fedoraproject.org/updates/FEDORA-2021-d2afa6dc55

Comment 9 Fedora Update System 2021-03-04 13:40:44 UTC
FEDORA-2021-a37a0f66da has been submitted as an update to Fedora 33. https://bodhi.fedoraproject.org/updates/FEDORA-2021-a37a0f66da

Comment 10 Fedora Update System 2021-03-04 16:59:23 UTC
FEDORA-2021-d2afa6dc55 has been pushed to the Fedora 34 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-d2afa6dc55`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-d2afa6dc55

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Comment 11 Fedora Update System 2021-03-04 20:42:56 UTC
FEDORA-2021-a37a0f66da has been pushed to the Fedora 33 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-a37a0f66da`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-a37a0f66da

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Comment 12 Ganapathi Kamath 2021-03-05 00:05:10 UTC
dnf-update even before fetching this package. Bug still present.

I upgraded from  
authselect-1.2.2-2.fc34 (downloaded from bodhi links given above)
to
authselect-1.2.2-5.fc34
also authselect-compat and authselect-libs 

Bug still present

Comment 13 Ganapathi Kamath 2021-03-05 01:15:20 UTC
I created a file /etc/dconf/db/gdm.d/00-loginscreen
```
[org/gnome/login-screen]
enable-smartcard-authentication=false
enable-fingerprint-authentication=false
enable-password-authentication=true
```
and executed 
# dconf update

rebooted

I don't think it had any effect. bug still exists.

Comment 14 Fedora Update System 2021-03-05 19:16:55 UTC
FEDORA-2021-a37a0f66da has been pushed to the Fedora 33 stable repository.
If problem still persists, please make note of it in this bug report.

Comment 15 Ganapathi Kamath 2021-03-05 19:33:44 UTC
This bug was not filed against fedora-33 but fedora-34, fedora33 was/is fine

The bug doesn't happen on first boot, but happens on subsequent user logout/lock-screens

Comment 16 Fedora Update System 2021-03-09 19:56:48 UTC
FEDORA-2021-d2afa6dc55 has been submitted as an update to Fedora 34. https://bodhi.fedoraproject.org/updates/FEDORA-2021-d2afa6dc55

Comment 17 Fedora Update System 2021-03-09 22:45:37 UTC
FEDORA-2021-d2afa6dc55 has been pushed to the Fedora 34 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-d2afa6dc55`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-d2afa6dc55

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Comment 18 Ganapathi Kamath 2021-03-10 16:48:20 UTC
Confirming that fix works. 
Tested, first login, subsequent logins after lockscreen, switch between linux console

removed the /etc/dconf/db/gdm and /etc/dconf/db/gdm.d created before
Ran dconf update

I issued a "dnf update -y"

authselect was upgraded
    from
  authselect-1.2.2-5.fc34
    to
  authselect-1.2.2-6.fc34 (came in via the dnf update -y )

# rpm -qa | grep -iE "^pam|^fpri|^auth|^gdm" | sort
authselect-1.2.2-6.fc34.x86_64
authselect-compat-1.2.2-6.fc34.x86_64
authselect-libs-1.2.2-6.fc34.x86_64
fprintd.fc34.x86_64
fprintd-pam.fc34.x86_64
gdm-40~beta.fc34.x86_64
pam-1.5.1-3.fc34.x86_64
pam_afs_session-2.6-14.fc34.x86_64
pam_passwdqz-1.4.0-3.fc34.x86_64


Since I don't configure/don't want to configure fingerprints, I can't tell and so wonder if the dconf disabling works. One needs a sure way to tell gdm not to bother with the fingerprints/fprintd in some cases that the admin/user may require.

Comment 19 Ganapathi Kamath 2021-03-10 16:50:31 UTC
Omitted to mention, including here for calarity, I also restored the /use/libexec/fprintd
mv /use/libexec/fprintd /use/libexec/fprintd.orig

Comment 20 Ganapathi Kamath 2021-03-10 16:51:09 UTC
(typo: other way around)
mv /use/libexec/fprintd.orig /use/libexec/fprintd

Comment 21 Ganapathi Kamath 2021-03-10 17:04:29 UTC
As noted in Bug Bug 1937308, and also as noted that it may not related be this bug and so maybe a different bug. 
I have some spurious times when GDM login spins on password typing.

The gdm-spin is not the same as a misstyped password event, which brings back the password prompt in 2 seconds.

One way to get it out form the spin in the switch to and back from linux console.

Comment 22 Fedora Update System 2021-03-12 01:35:51 UTC
FEDORA-2021-d2afa6dc55 has been pushed to the Fedora 34 stable repository.
If problem still persists, please make note of it in this bug report.

Comment 23 Grey Nicholson 2021-03-18 21:24:08 UTC
I'm still seeing symptoms that appear to be this bug, when running Silverblue 34.20210317.n.0 with authselect-1.2.2-6.fc34.x86_64.

My laptop is a Thinkpad X230. (My workaround is to rollback to 33 for now.) Is there any other information I could gather to help with this?

Comment 24 bhavin192 2021-03-19 19:14:23 UTC
I still seem to have this issue, if I remove the fingerprint from my machine, the login starts failing.

Comment 25 bhavin192 2021-03-19 19:20:28 UTC
*** Bug 1941033 has been marked as a duplicate of this bug. ***

Comment 26 Grzegorz 2021-03-24 19:42:31 UTC
Hi,

problem still persist, package authselect-1.2.2-6.fc34.x86_64 do not solve described problem.

Some basic information about my system: Dell Vostro 5568

[grzegorz@vostro15 ~]$ lsusb |grep -i finger
Bus 001 Device 005: ID 138a:0011 Validity Sensors, Inc. VFS5011 Fingerprint Reader

[grzegorz@vostro15 ~]$ sudo rpm -qa |grep -E "authselect|gdm"
authselect-libs-1.2.2-6.fc34.x86_64
authselect-1.2.2-6.fc34.x86_64
authselect-compat-1.2.2-6.fc34.x86_64
gdm-40~rc-1.fc34.x86_64

Nothing special i gdm journal:

Mar 24 20:22:41 vostro15 systemd[1]: Starting GNOME Display Manager...
Mar 24 20:22:41 vostro15 systemd[1]: Started GNOME Display Manager.
Mar 24 20:23:29 vostro15 gdm-password][3461]: pam_unix(gdm-password:auth): conversation failed
Mar 24 20:23:29 vostro15 gdm-password][3461]: pam_unix(gdm-password:auth): auth could not identify password for [grzegorz]
Mar 24 20:23:29 vostro15 gdm-password][3461]: gkr-pam: no password is available for user
Mar 24 20:24:08 vostro15 gdm-password][3762]: gkr-pam: unable to locate daemon control file
Mar 24 20:24:08 vostro15 gdm-password][3762]: gkr-pam: stashed password to try later in open session

Comment 27 cyshei 2021-03-25 06:30:00 UTC
I'm also seeing this with a completely updated F34 system, and have the same versions of authselect and gdm as Grzegorz.

Comment 28 Benjamin Berg 2021-03-25 09:39:10 UTC
To anyone still seeing this. Please turn on debugging in /etc/gdm/custom.conf, reboot and grab a log of that.

From all I can say, the GDM and authselect updates should be completely fine. I'll do a quick test trying to reproduce it locally later.

Comment 29 Benjamin Berg 2021-03-25 16:01:30 UTC
OK, so … that is a quite different bug. A fix in authselect to correct error reporting (when no fingerprint is enrolled), caused fingerprint authentication itself to not work anymore.

This means, you get "stuck" after trying to use the non-functional fingerprint authentication. There are two bugs:
 * gnome-shell getting stuck after fingerprint auth failure (upstream: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3853)
 * authselect PAM configuration simply not working for GDM (upstream: https://github.com/authselect/authselect/pull/242)

So, my bugfix was causing a regression.

Comment 30 Grey Nicholson 2021-03-27 08:33:01 UTC
Should this be reopened as a blocker for Fedora 34 final?

For affected laptops, this bug makes it impossible to log in without first logging into a terminal to run `sudo systemctl stop fprintd.service`.

> you get "stuck" after trying to use the non-functional fingerprint authentication

To be clear, I'm not trying to use fingerprint authentication. I'm trying to log in using a password.

Comment 31 Thorsten Leemhuis 2021-03-27 08:56:35 UTC
(In reply to Grey Nicholson from comment #30)
> Should this be reopened as a blocker for Fedora 34 final?

Should this be handled in a new ticket, as bberg said "that is a quite different bug"? Just wondering as someone that was hit by the initial bug (that is fixed for me now), but not by the other/new one.

Comment 32 Thorsten Leemhuis 2021-03-27 08:57:21 UTC
(In reply to Thorsten Leemhuis from comment #31)
> (In reply to Grey Nicholson from comment #30)
>> Should this be reopened as a blocker for Fedora 34 final?

Argh, sorry, wanted to quote this line: 

>> Should this be reopened as a blocker for Fedora 34 final?

Comment 33 Thorsten Leemhuis 2021-03-27 08:58:20 UTC
Sorry, was confused, guess I'll better leave the keyboard now...

Comment 34 Grey Nicholson 2021-03-27 09:17:46 UTC
I could raise a new bug report, but it would be virtually identical to this one, so I think it would just get closed as a duplicate. The description of this bug report describes the bug I'm seeing.

> To anyone still seeing this. Please turn on debugging in /etc/gdm/custom.conf, reboot and grab a log of that.

I've turned on debugging and rebooted. How do I grab a log of that?

Comment 35 Benjamin Berg 2021-03-27 10:21:28 UTC
I don't think this particular bug should be reopened. If anything, a new bug against authselect and/or gnome-shell makes sense. But, I'll push the authselect update start of next week either way, and the gnome-shell issue is well known and will also get pushed out in a timely fashion once it is fixed.

As for your case, please double check that you really have no fingerprint enrolled for your user. At this point, you should only run into issues when you 1. have a fingerprint reader, 2. have a print enrolled and 3. authentication using that print has failed or was successful.

Now, failure could happen immediately in certain error conditions, which is the most likely explanation of what you are seeing.

Comment 36 Benjamin Berg 2021-03-27 10:23:37 UTC
The GDM log can be fetched using "journalctl -u gdm.service".

Comment 37 cyshei 2021-03-27 18:16:31 UTC
I'm also happy to create a new bug and/or wait to see if your authselect update fixes things, but I think this bug impacts more than the cases listed in comment 35: I have a fingerprint reader and had enrolled a print previously, but since I sometimes use my laptop with the lid closed (and cannot press the fp reader), I went into GNOME accounts and disabled fingerprint login.  I also used fprintd-delete to remove all enrolled fingerprints for my user, and "fprintd-list <username>" shows no fingers enrolled. (I still do have some enrolled in Windows, if that makes any difference).

What I'm seeing is that as soon as I get to the login screen (without touching the fingerprint sensor at all), I get the "fingerprint authentication didn't work" error immediately and cannot login with a password either.  So in the current state, it is possible to upgrade from a fully working F33 install to an F34 one that does not allow login at all unless you switch VTs and kill fprintd.service first, even if you have fingerprint authentication disabled and no prints enrolled for your user.

Comment 38 cyshei 2021-03-27 18:17:10 UTC
Created attachment 1766926 [details]
GDM login failure log

Comment 39 Grzegorz 2021-03-27 21:41:13 UTC
I totally agree with cyshei@gmail.com, below you can find my GDM log.

Comment 40 Grzegorz 2021-03-27 21:43:14 UTC
Created attachment 1766989 [details]
Another GDM log for debug purposes

Comment 41 Benjamin Berg 2021-03-29 15:24:43 UTC
OK, those logs would be explained by an old authselect version. Please check the authselect-libs version or the "pam_fprintd.so" line in /etc/pam.d/fingerprint-auth.

The broken version was:
auth        sufficient                                   pam_fprintd.so

The broken fix was:
auth        required                                     pam_fprintd.so

The correct version is/will be:
auth        [success=done default=bad]                   pam_fprintd.so

Comment 42 Benjamin Berg 2021-03-29 15:27:28 UTC
Or try https://koji.fedoraproject.org/koji/taskinfo?taskID=64793867

Comment 43 Grzegorz 2021-03-29 15:38:04 UTC
[success=done default=bad] - this setting solved problem on my system, thank you very much!

Comment 44 cyshei 2021-03-29 17:10:18 UTC
I installed authselect, authselect-compat, and authselect-libs 1.2.2-7.fc34 from the koji link in comment 42, but my /etc/pam.d/fingerprint-auth still contains:

auth        sufficient                                   pam_fprintd.so

Comment 45 Benjamin Berg 2021-03-29 17:13:34 UTC
Could you run "sudo authselect apply-changes" and see what happens?

I am wondering why the fix is not being applied. Maybe you have some local PAM modifications and the fix is not applied because of that?

Comment 46 cyshei 2021-03-29 17:30:40 UTC
Sure, it seems to error out... perhaps this is why the fix is not being applied?

[error] [/etc/authselect/nsswitch.conf] has unexpected content!
[error] Unexpected changes to the configuration were detected.
[error] Refusing to activate profile unless those changes are removed or overwrite is requested.
Some unexpected changes to the configuration were detected. Use 'select' command instead.

Comment 47 cyshei 2021-03-29 17:32:33 UTC
(and I don't have any local PAM modifications, as far as I remember)

Comment 48 Benny Amorsen 2021-03-30 07:43:36 UTC
The problem goes away after:

authselect select minimal --force

I have not intentionally changed the auth configuration before.

The laptop was installed with Fedora 32, upgraded to Fedora 33 with dnf system-upgrade, and now to Fedora 34 the same way.

Is there a way to make authselect tell which content it finds objectionable?

Comment 49 Grey Nicholson 2021-04-20 07:24:26 UTC
Created attachment 1773661 [details]
GDM log

I'm still seeing this bug every time my computer restarts. I have to wait a few minutes before trying to log in.

I also still see this bug when I lock the screen. As far as I'm aware, waiting doesn't make the problem go away there — you have to use Ctrl+Alt+F1 to switch back to the login screen, and wait for the bug to stop again. I don't think most ordinary users would know how to do this workaround.

I have never used the fingerprint reader, and I've never changed any settings to do with the fingerprint reader, either to trigger this bug or to work around it.

I don't understand why this bug is closed when it isn't fixed, and I don't understand what “errata” means in this context. Is it really the expected behaviour for laptops with fingerprint readers that after upgrading to Fedora 34 you can no longer log in?

Version numbers:
Fedora Silverblue 34.20210415.n.0 24172968655aa4322456f9c7012abb275e95b271fe9da931a6c6c7be8d217cde
authselect-1.2.3-1.fc34.x86_64
authselect-libs-1.2.3-1.fc34.x86_64
fprintd-1.90.9-2.fc34.x86_64
fprintd-pam-1.90.9-2.fc34.x86_64
gdm-40.0-1.fc34.x86_64
pam-1.5.1-3.fc34.x86_64
pam_afs_session-2.6-14.fc34.x86_64
pam_passwdqc-1.4.0-3.fc34.x86_64

Comment 50 Benjamin Berg 2021-04-20 08:28:10 UTC
Could you test whether https://bodhi.fedoraproject.org/updates/FEDORA-2021-48ca6e6b86 fixes the issue for you?

See https://bugzilla.redhat.com/show_bug.cgi?id=1942443. Note that it only happens when upgrading Fedora for multiple versions.

Comment 51 Grey Nicholson 2021-04-21 12:09:23 UTC
(In reply to Benjamin Berg from comment #50)
> Could you test whether
> https://bodhi.fedoraproject.org/updates/FEDORA-2021-48ca6e6b86 fixes the
> issue for you?
> 
> See https://bugzilla.redhat.com/show_bug.cgi?id=1942443. Note that it only
> happens when upgrading Fedora for multiple versions.

Yes, this does fix the issue for me.

I installed this using `rpm-ostree override replace ~/Downloads/pam-1.5.1-5.fc34.x86_64.rpm` and after rebooting I no longer see this issue, either on the login screen or the lock screen.

Thanks!

Comment 52 Robert Smol 2021-04-22 10:22:50 UTC
Hello,

today, I've upraded from F33 to F34Beta, I could login, then OS dialog with system updates + finger print update (separate entry) poped up. I've installed both. Since that:

- when on lock screen I cannot login. I get every few seconds text "Sorry, fingerprint authentication didn't work. Please try again". Even when I try to type my password quick, it fails.
- I can login on console OK
- after boot, I also get the Sorry message, but if I leave this for some time on the screen where I select person (2-3 minutes), I can proceed and login with my password.

I did try to fix it by following instructions in 1942443 by issuing:

`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-48ca6e6b86`

But I do not get any difference.

Removing fprintd-pam helped (I do not have fingerprint, but I can login).

Comment 53 Wayne Boxall 2021-04-28 09:35:42 UTC
Just upgraded to GA Fedora 34. Same authentication issue as above. Eventually I can login after letting the system sit.


Note You need to log in before you can comment on or make changes to this bug.