Hide Forgot
Description of problem: After updating to Fedora 25, fingerprint authentication stopped working. The X login screen prompts for a password and the fingerprint reader does not get activated. Ditto for virt-manager. Version-Release number of selected component (if applicable): pam-1.3.0-1.fc25.x86_64 How reproducible: Always Steps to Reproduce: 1. Start with working fingerprint authentication in Fedora 24 2. Update to Fedora 25 Actual results: Fingerprint authentication no longer works. Expected results: Fingerprint authentication working as before. Additional info: fprintd-enroll activates the fingerprint scanner, and I can reenroll without any issues. After poking around I see that something gets written to /var/lib/fprint/mrsam/0011/00000000/7, yet pam still does not prompt for authentication when it should be. The hardware is: Bus 001 Device 003: ID 147e:2016 Upek Biometric Touchchip/Touchstrip Fingerprint Sensor
Do you use gdm for the X login screen? Is pam_fprintd present on the system?
(In reply to Tomas Mraz from comment #1) > Do you use gdm for the X login screen? Is pam_fprintd present on the system? Which is in the fprintd-pam package.
[mrsam@thinkpad ~]$ rpm -q fprintd-pam fprintd-pam-0.7.0-1.fc25.x86_64 [mrsam@thinkpad ~]$ rpm -q lightdm lightdm-1.18.2-1.fc25.x86_64 lightdm with the xfce desktop. As I mentioned, authenticating to virt-manager also no longer activates the fingerprint reader any more, either.
And do you see pam_fprintd in /etc/pam.d/system-auth? Can you paste it here?
Created attachment 1225276 [details] /var/log/messages As far as I can tell, these are the relevant lines that get logged to syslog.
No, pam_fprintd is not in /etc/system-auth # This file is auto-generated. # User changes will be destroyed the next time authconfig is run. auth required pam_env.so auth sufficient pam_unix.so nullok try_first_pass auth requisite pam_succeed_if.so uid >= 1000 quiet_success auth required pam_deny.so account required pam_unix.so account sufficient pam_localuser.so account sufficient pam_succeed_if.so uid < 1000 quiet account required pam_permit.so password requisite pam_pwquality.so try_first_pass retry=3 type= password sufficient pam_unix.so sha512 shadow nullok try_first_pass use_authtok password required pam_deny.so session optional pam_keyinit.so revoke session required pam_limits.so -session optional pam_systemd.so session [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid session required pam_unix.so
Chasing the /etc/pam.d/system-auth clue, I ran system-config-authentication, and found the "Enable fingerprint" checkbox, which was off. After enabling it, fingerprint authentication started working both in lightdm, and in virt-manager. This system was updated from Fedora 24 to 25 via fedup. The fprintd package has: %postun pam /sbin/authconfig --disablefingerprint --update That looks to me like when pam gets updated, during the system upgrade, this disabled the fingerprint module, since a package upgrade is an install followed by an uninstall. I don't know how long this %postun has been there; but this system had its fingerprint module active, by default, for many Fedora releases.
Yes, the %postun script should be: if [ "$1" = 0 ] ; then /sbin/authconfig --disablefingerprint --update ; fi exit 0 And maybe it should be in %preun rather than in %postun.
*** Bug 1398959 has been marked as a duplicate of this bug. ***
fprintd-0.7.0-2.fc25 has been submitted as an update to Fedora 25. https://bodhi.fedoraproject.org/updates/FEDORA-2017-4b67ae702a
fprintd-0.7.0-2.fc25 has been pushed to the Fedora 25 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-4b67ae702a
fprintd-0.7.0-2.fc25 has been pushed to the Fedora 25 stable repository. If problems still persist, please make note of it in this bug report.
*** Bug 1423480 has been marked as a duplicate of this bug. ***