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
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.
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.
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.
*** Bug 1933595 has been marked as a duplicate of this bug. ***
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 """
(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.
* `master` * 41197d567e0ef15cdd50b9e7658e9a0b205e6683 - minimal: add dconf settings to explicitly disable fprint and smartcard authentication
FEDORA-2021-d2afa6dc55 has been submitted as an update to Fedora 34. https://bodhi.fedoraproject.org/updates/FEDORA-2021-d2afa6dc55
FEDORA-2021-a37a0f66da has been submitted as an update to Fedora 33. https://bodhi.fedoraproject.org/updates/FEDORA-2021-a37a0f66da
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.
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.
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
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.
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.
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
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.
Omitted to mention, including here for calarity, I also restored the /use/libexec/fprintd mv /use/libexec/fprintd /use/libexec/fprintd.orig
(typo: other way around) mv /use/libexec/fprintd.orig /use/libexec/fprintd
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.
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.
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?
I still seem to have this issue, if I remove the fingerprint from my machine, the login starts failing.
*** Bug 1941033 has been marked as a duplicate of this bug. ***
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
I'm also seeing this with a completely updated F34 system, and have the same versions of authselect and gdm as Grzegorz.
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.
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.
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.
(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.
(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?
Sorry, was confused, guess I'll better leave the keyboard now...
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?
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.
The GDM log can be fetched using "journalctl -u gdm.service".
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.
Created attachment 1766926 [details] GDM login failure log
I totally agree with cyshei, below you can find my GDM log.
Created attachment 1766989 [details] Another GDM log for debug purposes
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
Or try https://koji.fedoraproject.org/koji/taskinfo?taskID=64793867
[success=done default=bad] - this setting solved problem on my system, thank you very much!
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
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?
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.
(and I don't have any local PAM modifications, as far as I remember)
This comment was flagged as spam, view the edit history to see the original text if required.
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
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.
(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!
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).
Just upgraded to GA Fedora 34. Same authentication issue as above. Eventually I can login after letting the system sit.