Public bug reported:

Release: Ubuntu 26.10
gnome-shell 51.0-2ubuntu3
gdm3 51.0-0ubuntu1
fprintd / libpam-fprintd 1.94.5-4maysync1
libfprint-2-2 1:1.95.2+tod1-1ubuntu2
authd: not installed
Hardware: MSI Prestige 16 Studio A13VE, Goodix fingerprint reader (27c6:6094)

Summary

After resuming from suspend with fingerprint authentication enabled, the
lock screen sometimes ends up in a state where it cannot be unlocked. It
shows the user avatar and the "Unlock with fingerprint" hint, but there is
no password entry, the fingerprint is not accepted, and no error or
feedback is shown. Clicking or typing does nothing. The only way out is to
switch to a VT and unlock from there, or to hard power off the machine.

Steps to reproduce (intermittent)

1. Enroll a fingerprint and enable fingerprint authentication.
2. Lock the screen and suspend (e.g. close the lid).
3. Resume, and press Enter (or start typing) as soon as the lock screen
   appears, before the password entry is shown.

Expected: the password entry is shown (and/or the fingerprint is accepted).
Actual: the prompt stays empty forever, with only the fingerprint hint.

Analysis

I traced the lock screen with a local debugging extension that logs the
AuthPrompt, ShellUserVerifier and AuthServices calls together with their
state. Relevant sequence after resume (timestamps from the journal):

09:06:57  Resume from suspend. The AuthServices instances were destroyed
          on suspend and are recreated, so there is no selected mechanism.
09:06:58  AuthPrompt.reset() -> AuthPrompt.begin() -> status VERIFYING
09:06:58  AuthPrompt._activateNext() with an empty entry and no querying
          service -> status VERIFICATION_IN_PROGRESS
09:06:58  AuthServicesLegacy.beginVerification(): selected mechanism is
          null, so _handleCanStartService() only allows gdm-fingerprint.
          gdm-password is NOT started.
09:06:58  gdm-authd start fails: "PAM service gdm-authd was not found"
          (expected, authd is not installed)
09:06:58  ShellUserVerifier emits mechanisms-changed with gdm-password as
          the selected mechanism, UnlockDialog calls
          AuthPrompt.selectMechanism(), which returns false because the
          status is VERIFICATION_IN_PROGRESS. So the selection never reaches
          the auth services.
09:06:58  gdm-fingerprint reports service-unavailable (empty message).
          fprintd had logged "Device reported an error during identify:
          Cannot run while suspended" when going to sleep, and the device
          is apparently not ready yet right after resume.
          AuthServicesLegacy._handleOnConversationStopped() returns early
          because the service is unavailable, without reporting a failure.
          Active services: none.
09:07:05+ Every key press or click calls UnlockDialog._showPrompt(), which
          does nothing: status stays VERIFICATION_IN_PROGRESS,
          querying=null, no active conversation.

Root cause

AuthPrompt.selectMechanism() refuses any selection while the status is
VERIFICATION_IN_PROGRESS. That state is also entered when the user
activates the entry before any service asked a question (a preemptive
answer). In that case nothing is actually being verified. If no mechanism
was selected yet, the initial automatic selection is lost, the password
service is never started, and once the fingerprint service drops out
nothing is left to drive the prompt.

The same thing can happen when typing the password quickly and pressing
Enter right after resuming, not only with an empty entry.

Proposed fix

Allow the initial mechanism selection in AuthPrompt.selectMechanism() when
the in-progress status comes only from a pending preemptive answer (no
querying service and no selected mechanism). The selection then triggers
the usual soft reset, gdm-password is started, and its first question
consumes the preemptive answer, if there is one. This is the same path the
lock screen follows on a normal unlock. Patch attached:
authPrompt-Allow-selecting-a-mechanism-while-a-preemptive-answer-is-pending.patch

Testing

I tested the change on the affected machine by applying it at runtime
(a local extension that wraps AuthPrompt.selectMechanism with the same
logic), and pressed Enter repeatedly while opening the lid:

09:33:36  Resume from suspend.
09:33:39  AuthPrompt._activateNext() with querying=null
          -> VERIFICATION_IN_PROGRESS (the same trigger as the hang)
09:33:39  Only gdm-fingerprint is started (no selected mechanism yet).
09:33:39  The fixed selectMechanism() selects gdm-password while the
          preemptive answer is pending, and gdm-password is started.
09:33:39  gdm-password asks its question and the password entry is shown.
09:33:43  Password typed and submitted before the next question
          (preemptive answer).
09:33:45  gdm-password restarts, its question consumes the preemptive
          answer, verification-complete, and the session is unlocked.

Without the change, the same trigger left the prompt stuck as described
above. In this run, gdm-fingerprint did not become unavailable. With the
fix that no longer matters: the password service is started either way.

The code involved (AuthPrompt._activateNext and selectMechanism,
AuthServicesLegacy._handleCanStartService and
_handleOnConversationStopped) is largely the same upstream, so this might
need forwarding to GNOME Shell as well. I have not confirmed that it
reproduces upstream yet.

Possible follow-ups (not part of the patch)

- There is no global safety net: when every conversation across all
  AuthServices has ended without a failure being reported, the prompt
  should reset instead of hanging. Doing this per AuthServices (e.g. in
  AuthServicesLegacy) does not look right, since another AuthServices
  (authd) could still have an active conversation.
- gdm-fingerprint is reported as unavailable right after resume. A retry
  once fprintd and the device are ready would avoid losing fingerprint
  unlock in that case.
- When authd is not installed, gnome-shell still tries to start gdm-authd
  on every verification and logs "PAM service gdm-authd was not found".
  This is harmless, but noisy.

Workaround

Switch to a VT (Ctrl+Alt+F3), log in, and run: loginctl unlock-sessions

ProblemType: Bug
DistroRelease: Ubuntu 26.10
Package: gnome-shell 51.0-2ubuntu3
ProcVersionSignature: Ubuntu 7.3.0-9.9-generic 7.3.0-rc6
Uname: Linux 7.3.0-9-generic x86_64
ApportVersion: 2.36.0-0ubuntu1
Architecture: amd64
CasperMD5CheckResult: pass
CurrentDesktop: ubuntu:GNOME
Date: Sun Oct 25 09:38:11 2026
DisplayManager: gdm3
InstallationDate: Installed on 2026-10-16 (9 days ago)
InstallationMedia: Ubuntu 26.10 "Stonking Stingray" - Official amd64 (20261013)
SourcePackage: gnome-shell
UpgradeStatus: No upgrade log present (probably fresh install)

** Affects: gnome-shell (Ubuntu)
     Importance: Undecided
         Status: New


** Tags: amd64 apport-bug stonking wayland-session

** Patch added: "Proposed fix"
   
https://bugs.launchpad.net/bugs/2172157/+attachment/6012347/+files/authPrompt-Allow-selecting-a-mechanism-while-a-preemptive-answer-is-pending.patch

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2172157

Title:
  Lock screen gets stuck after resume with fingerprint enabled: no
  password entry, fingerprint not accepted, no feedback

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/gnome-shell/+bug/2172157/+subscriptions


-- 
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

Reply via email to