Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 1937308 - First login attempt fails on laptop with fingerprint reader
Summary: First login attempt fails on laptop with fingerprint reader
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: gdm
Version: 34
Hardware: x86_64
OS: Linux
unspecified
urgent
Target Milestone: ---
Assignee: Ray Strode [halfline]
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: AcceptedFreezeException
Depends On: 1935331
Blocks: F34BetaFreezeException F34FinalBlocker
TreeView+ depends on / blocked
 
Reported: 2021-03-10 10:54 UTC by Benjamin Berg
Modified: 2021-03-23 15:53 UTC (History)
16 users (show)

Fixed In Version: gdm-40~beta-2.fc34
Doc Type: If docs needed, set a value
Doc Text:
Clone Of: 1935331
Environment:
Last Closed: 2021-03-16 00:28:36 UTC
Type: Bug
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
GNOME Gitlab GNOME/gdm - merge_requests 132 0 None None None 2021-03-10 10:54:07 UTC

Description Benjamin Berg 2021-03-10 10:54:08 UTC 
GDM will not correctly resolve the first error from a conversation. After the authselect part of bug #1935331 was solved, this meant that the first time the user tried to login to a system, the password prompt will just hang when a fingerprint reader was available but no prints are enrolled.

Please note, while annoying, it is trivial to work around the situation as the second attempt will work.

(The fact that we would hang in this case can be considered another bug in the gnome-shell code. However, the fix here is obviously desirable and also works around the gnome-shell issue.)


+++ This bug was initially created as a clone of Bug #1935331 +++

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.

--- Additional comment from Ganapathi Kamath on 2021-03-08 01:24:21 UTC ---

Same as Bug 1933520 , which was closed abruptly/prematurely without explanation. This bug exists

--- Additional comment from Alessio on 2021-03-08 12:35:44 UTC ---

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.

--- Additional comment from Alessio on 2021-03-08 12:43:06 UTC ---

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'

--- Additional comment from  on 2021-03-09 01:18:02 UTC ---

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.

--- Additional comment from Benjamin Berg on 2021-03-09 13:39:44 UTC ---

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.

--- Additional comment from Fedora Blocker Bugs Application on 2021-03-09 13:41:02 UTC ---

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.

--- Additional comment from Adam Williamson on 2021-03-09 18:28:41 UTC ---

+4 in https://pagure.io/fedora-qa/blocker-review/issue/292 , marking accepted.

--- Additional comment from Adam Williamson on 2021-03-09 18:30:10 UTC ---

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.

--- Additional comment from Adam Williamson on 2021-03-09 18:35:06 UTC ---

(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.

--- Additional comment from  on 2021-03-09 18:54:18 UTC ---

No, https://bodhi.fedoraproject.org/updates/FEDORA-2021-d2afa6dc55 fixes the login problem.

--- Additional comment from Benjamin Berg on 2021-03-09 18:58:51 UTC ---

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.

--- Additional comment from Fedora Update System on 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

--- Additional comment from Fedora Update System on 2021-03-09 19:56:52 UTC ---

FEDORA-2021-d2afa6dc55 has been submitted as an update to Fedora 34. https://bodhi.fedoraproject.org/updates/FEDORA-2021-d2afa6dc55

--- Additional comment from Adam Williamson on 2021-03-09 19:59:02 UTC ---

I've now edited the update to include a build with *both* fixes. Please verify if that works, thanks!

--- Additional comment from  on 2021-03-09 21:05:49 UTC ---

With authselect-1.2.2-6 after entering password gdm just spins. Can not login.

--- Additional comment from Benjamin Berg on 2021-03-09 21:26:04 UTC ---

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!

--- Additional comment from Fedora Update System on 2021-03-09 22:45:40 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 1 Adam Williamson 2021-03-10 16:22:02 UTC 
Proposing as both FE and blocker for consideration. While the workaround is simple, this sounds like it does *look* pretty bad, and there are a lot of laptops with fingerprint readers out there these days.
Comment 2 Ganapathi Kamath 2021-03-10 16:54:35 UTC 
Confirming, that authselect-1.2.2-6.fc34.x86_64 seems to fix the problem.

See comments 18 to 20 of Bug 1933520
Comment 3 Ganapathi Kamath 2021-03-10 17:05:16 UTC 
As noted in the above descr/comments, and also as noted that it may not related be this bug and so maybe a different bug. 
I have seen 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 4 Ganapathi Kamath 2021-03-10 18:01:07 UTC 
Confirming that Benjamin Berg's revised bug description to describe different effect ma be correct.

Perhaps new bug title should be "gdm login spuriously gets stuck and spins after password entry"

* It does happen on first password attempt. It does not need to be a mistyped password
* I think it may also happens on the login on first lock-screen
* Pressing escape will also take back from spin to reentry password prompt
* The very first login, has a back-arrow to the left of the prompt, which can also escape to re-entry password prompt
* I wonder if it happens on machines without fingerprint-reader
* sometimes a notification message "gnome-shell quit unexpectedly" exists
* sometimes gnome-shell logout takes too long to log out when okaying to bypass the timeout
Comment 5 Adam Williamson 2021-03-10 18:49:52 UTC 
This has been accepted as an FE at least in https://pagure.io/fedora-qa/blocker-review/issue/296 (blocker voting is still open). Can we please get a build/update with the fix? Thanks!
Comment 6 Fedora Update System 2021-03-10 19:40:28 UTC 
FEDORA-2021-ec64853158 has been submitted as an update to Fedora 34. https://bodhi.fedoraproject.org/updates/FEDORA-2021-ec64853158
Comment 7 louisgtwo 2021-03-10 19:55:05 UTC 
With gdm-40~beta-2.fc34 first attempt at login after boot works for me.
Comment 8 Benjamin Berg 2021-03-10 20:01:58 UTC 
Just for completeness sake, the gnome-shell side of the issue is tracked at https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3853.

This last remaining issue is really low impact though. It only happens after presenting the wrong finger and it is expected to be fixed in the final release.
Comment 9 Ben Cotton 2021-03-11 18:58:40 UTC 
From today's Go/No-Go meeting:

RejectedBlocker(Beta) - There is insufficient consensus that this is a blocker (and those who want to say it is also want to waive it), so we will leave it for FinalBlocker consideration
Comment 10 Fedora Update System 2021-03-11 19:51:08 UTC 
FEDORA-2021-ec64853158 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-ec64853158`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-ec64853158

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
Comment 11 Adam Williamson 2021-03-15 16:08:40 UTC 
Marking verified based on comment #7.

Can folks please +1 the update if it works for them? Thanks!
Comment 12 Geoffrey Marr 2021-03-15 20:59:53 UTC 
Discussed during the 2021-03-15 blocker review meeting: [0]

The decision to delay the classification of this as a blocker bug was made as this isn't a completely clear call for Final blocker, so since it's confirmed fixed in Beta anyway we're just going to duck it by waiting for that fix to be pushed stable.

[0] https://meetbot.fedoraproject.org/fedora-blocker-review/2021-03-15/f34-blocker-review.2021-03-15-16.00.txt
Comment 13 Fedora Update System 2021-03-16 00:28:36 UTC 
FEDORA-2021-ec64853158 has been pushed to the Fedora 34 stable repository.
If problem still persists, please make note of it in this bug report.
Note You need to log in before you can comment on or make changes to this bug.