Yikes. I thought I could just send of builds using fedpkg --target f34 build, but it seems like I send builds with the rawhide versions to all distributions :-(

I did not expect I could create a proper distribution build from the wrong branch!

Someone please verify it works.

To test, you must break your configuration! Edit /etc/pam.d/fingerprint-auth and replace the [success=done default=bad] in the line with success. Then test without having any fingerprints enrolled.

Make sure to revert all pam modifications afterwards. If you have not done anything unusual, just run: authselect select --force sssd with-fingerprint with-silent-lastlog or make sure you have the original fingerprint-auth file back (byte for byte).


The easy way to test the update is to enable fingerprint auth and checking whether you can do a password authentication after presenting the wrong finger multiple times. Doing this results in the exact same error condition as the misconfiguration does.

BZ#1942443 Login using password failed after upgrade to Fedora 34
User Icon benzea commented & provided feedback on pam-1.5.1-5.fc34 3 years ago

Do we have rawhide users with the problem?

In principle we should only need to run the added script once during the F33 -> F34 upgrade process. So my take was to not add the scriptlet to F35.

User Icon benzea commented & provided feedback on pam-1.5.1-5.fc34 3 years ago

Thanks for verifying that! Not sure how a freeze might occur, but the PAM scriptlet really shouldn't be causing any issues.

Upstream reports say that the bugfix is needed on Dell Latitude 7400 machines (this information had not previously been provided by the reporter).

OK, restarted the process again for an fprintd update.

This is pretty minor in comparison to the other ones though. i.e. pam_fprintd would not allow fingerprint authentication when fprintd was just started. It would work if you tried again within 5 seconds (the timeout in which fprintd does an idle-shutdown).

Sounds like a plan.

As it happens, the crash we ran into here was one of the few corner cases that was not covered in the automated tests (i.e. no fingerprint device available). :-/

The upstream tests have been improved a lot recently and now also include the buggy corner case that we hit here. Those tests are run during package build. I don't have the PAM tests duplicated in the gating currently though (anything testing libfprint interactions is more interesting there).

OK, another update now. This should fix the problems.

Ah, a good trick to work around it is to log in via SSH. Because then you are remote and pam_fprintd will disable itself early and the crash should not happen.

The fix is already committed upstream.

The easiest workaround will probably be to just mask the systemd fprintd service. It only happens on machines without a fingerprint reader.

I'll post an update tomorrow.

This update has been unpushed.

This update has been unpushed.

On affected machines you'll messages like the following:

Sep 02 13:41:34 localhost.localdomain thermald[742]: 22 CPUID levels; family:model:stepping 0x6:8e:c (6:142:12)
Sep 02 13:41:34 localhost.localdomain thermald[742]: [/sys/devices/platform/thinkpad_acpi/dytc_lapmode] present: Thermald can't run on this platform
Sep 02 13:41:34 localhost.localdomain thermald[742]: Unsupported cpu model, use thermal-conf.xml file or run with --ignore-cpuid-check
Sep 02 13:41:34 localhost.localdomain thermald[742]: THD engine start failed
BZ#1874462 Kill switch for Lenovo laptops non-functional

Right … there was something; and unfortunately it is also needed on other machines to fix performance issues :-/

Would be nice if srinivas found a solution to your problem.

Note to testers, you may need to re-enroll prints with certain devices. On the plus side, the enrolled prints for those devices should be rendered useless, which is important as there was a high likelyhood of them causing false positives.

The primary test for this is to run "systemd --user" and check the gnome-launched-* units. Some of these will be from gnome-shell, but with this patch merged, you will see that all of them

There should always be some with this patch (for XDG autostart applications). Also, when running "systemd --user show UNIT" you will see that all of them have "" set.