With a Dell inspiron 7370 loaded with f34 as of 3/3/21 I am unable to login with password. gdm seems to be in a loop looking for a fingerprint login which is not setup yet as this is a fresh install. Loading f34 in a virt machine gdm login works fine.
Same as Bug 1933520 , which was closed abruptly/prematurely without explanation. This bug exists
I can confirm that Toshiba Portege R930-163 Also in a live session. If you set the liveuser password and you lock the screen there is no way to log in.
In the logs there is this line at each iteration Mar 08 12:41:48 localhost-live audit[2707]: USER_AUTH pid=2707 uid=0 auid=1000 ses=1 subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 msg='op=PAM:authentication grantors=? acct="liveuser" exe="/usr/libexec/gdm-session-worker" hostname=localhost-live addr=? terminal=/dev/tty1 res=failed'
Looking Bug 1933520 it seems to be an issue with authselect not disabling fprint when it is not setup. I will wait until authselect-1.2.2-5 hits f34 to test again.
It turns out that the fingerprint-auth stack would also return a failure when the stack was enabled. I posted https://github.com/authselect/authselect/pull/239 upstream to fix this. We'll need to pull this into F34.
Proposed as a Blocker and Freeze Exception for 34-beta by Fedora user benzea using the blocker tracking app because: This breaks login/unlock in GDM/GNOME if the machine has a fingerprint reader and the user has no enrolled prints.
+4 in https://pagure.io/fedora-qa/blocker-review/issue/292 , marking accepted.
Um. Well, actually I'm not sure about that. Is it https://bodhi.fedoraproject.org/updates/FEDORA-2021-d2afa6dc55 that breaks this? If so, it can't be a blocker, as that is not stable (and so not included in composes), it's in -testing only. Unaccepting for now.
(adamw) benzea: do we know when https://bugzilla.redhat.com/show_bug.cgi?id=1935331 broke? (benzea) adamw: yeah, GDM update to 40.x (benzea) er, I mean gnome-shell So sounds like this is broken in current F34 stable, so accepting again.
No, https://bodhi.fedoraproject.org/updates/FEDORA-2021-d2afa6dc55 fixes the login problem.
Before there is more confusion, there are two separate bugs, that result in exactly the same issue for users. 1. If fingerprint-auth is disabled, the fingerprint-auth stack always fails with AUTH_ERR, resulting in the retry from GDM. In this case authselect needs to disable the GDM fingerprint auth, but this was not done in the "minimal" profile, causing issues. This is what https://bodhi.fedoraproject.org/updates/FEDORA-2021-d2afa6dc55 fixes. 2. If fingerprint-auth is enabled, the fingerprint-auth stack will always fail rather than returning the PAM_AUTHINFO_UNAVAIL from pam_fprintd.so, confusing GDM/gnome-shell. This is what the next update will fix. Note that there was some confusion, and the previous bug 1933520 was probably about issue 2 while in fact we addressed issue 1 there.
FEDORA-2021-d2afa6dc55 has been submitted as an update to Fedora 34. https://bodhi.fedoraproject.org/updates/FEDORA-2021-d2afa6dc55
I've now edited the update to include a build with *both* fixes. Please verify if that works, thanks!
With authselect-1.2.2-6 after entering password gdm just spins. Can not login.
Yes, but that is a different issue (which is likely in gnome-shell). Login will work if you simply try again. It seems to only occur right after booting, we are not yet clear why though. So, again, "gdm just spinning" is *not* this bug and actually a *good* sign that the authselect part is fixed!
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.
Fix is verified in RC1
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.