[BUG] Lock screen doesn't allow entering password while it is asking for fingerprint

[Venemo]

Version: cosmic-greeter-1.0.0~alpha.4^git20250107.d15251e-1.fc41.x86_64

Pre-requisite: Working fingerprint reader set up

When trying to unlock the COSMIC desktop, it asks me to place my finger on the fingerprint reader. And it doesn't allow me to unlock the desktop by typing a password. (It only lets me enter my password after failing to read the fingerprint a few times.)

I would like it to allow unlocking the desktop with a password, regardless of whether fingerprint login is set up or not. This would be very useful in situations when I know the fingerprint reader is not reliable (eg. after washing my hands).

[andersk]

Some context and related work and issues:

• Parallel or "any" PAM modules  linux-pam/linux-pam#301
• Multiple concurrent authentication conversations (GDM)
• [Feature] Support parallel unlocking with fingerprint and password hyprwm/hyprlock#258
• Support fingerprint reader login sddm/sddm#284
• [Feature] Support parallel unlocking with fingerprint and password jovanlanik/gtklock#116
• https://github.com/ChocolateLoverRaj/pam-any
• https://gitlab.com/mishakmak/pam-fprint-grosshack

[lukeaboss]

Getting a similar problem. But in my case, it doesn't even ask for fingerprint. It seems to enter a loop of trying to read a fingerprint without asking for it, or even reading it while it's rolling

[thecoshman]

Funny, in my case I'm getting annoyed that greeter is mostly looking for password by default. When I first boot, or actively lock, it'll let me unlock via finger print; but if the screen locks due to inactivity, it'll be looking for password, and I have to enter something for it to then let me use finger print.

I don't want to end up digging into PAM 😓

[corvy]

Adding a data point for the wake-from-suspend variant of this (the mirror image of the OP, same root cause as #470 which was closed as a duplicate of this issue):

With pam_fprintd.so placed first in /etc/pam.d/cosmic-greeter, fingerprint correctly leads everywhere — login, sudo, and manual lock (Super+Esc). But after resuming from suspend (lid close/open), the lock screen starts password-first, and fingerprint is only attempted after a failed password submission.

journalctl confirms the greeter never engages fprintd on the resume path: on manual lock, fprintd.service activates the moment the lock screen appears; after lid-open, fprintd stays completely silent (no activation, no errors) until I submit an empty password — only then does the fingerprint round start. So this isn't a sensor/USB re-init issue on my hardware — the PAM conversation on resume simply begins at the password module.

Workaround for anyone else landing here: press Enter on the empty password field at wake, and the fingerprint prompt appears immediately.

Setup: Pop!_OS 24.04 (COSMIC), Dell XPS 15 9520, Goodix 53xc via goodix-tod.

Some logs, the first logs are when I close the lid - last one is a SUPER+ESC lock, and then it all works just as it should:

stian@pop-os:~$ journalctl -b --since "10 minutes ago" | grep -iE "fprint|suspend|lid"
Jul 19 19:33:46 pop-os kernel: printk: Suspending console(s) (use no_console_suspend to debug)
Jul 19 19:33:46 pop-os systemd-logind[1029]: Lid opened.
Jul 19 19:33:46 pop-os systemd-sleep[8711]: System returned from sleep operation 'suspend'.
Jul 19 19:33:46 pop-os kernel: PM: suspend exit
Jul 19 19:33:48 pop-os systemd[1]: systemd-suspend.service: Deactivated successfully.
Jul 19 19:33:48 pop-os systemd[1]: Finished systemd-suspend.service - System Suspend.
Jul 19 19:33:48 pop-os systemd[1]: systemd-suspend.service: Consumed 1.483s CPU time.
Jul 19 19:33:48 pop-os systemd[1]: Reached target suspend.target - Suspend.
Jul 19 19:33:48 pop-os systemd-logind[1029]: Operation 'suspend' finished.
Jul 19 19:33:48 pop-os systemd[1]: Stopped target suspend.target - Suspend.
Jul 19 19:34:24 pop-os systemd[1]: fprintd.service: Deactivated successfully.
Jul 19 19:37:17 pop-os systemd[1]: Starting fprintd.service - Fingerprint Authentication Daemon...
Jul 19 19:37:17 pop-os fprintd[9353]: Creating TOD wrapper for goodix-tod (Goodix Fingerprint Sensor 53xc) driver
Jul 19 19:37:17 pop-os systemd[1]: Started fprintd.service - Fingerprint Authentication Daemon.

[erik-balfe]

Additional data point: resume USB re-enum + serial pam_fprintd hang (ThinkPad X1 / Synaptics)

Hardware / software

• Lenovo ThinkPad X1 Carbon Gen 9
• Fingerprint reader: Synaptics Prometheus 06cb:00fc (libfprint press)
• Fedora 44, cosmic-greeter 1.3.x, fprintd 1.94.x
• authselect with-fingerprint → serial stack: auth sufficient pam_fprintd.so then pam_unix (no timeout= args → default 30s)

What we see
After lid-open resume, unlock sometimes shows a fingerprint/timeout-style message and accepts neither a successful scan nor password input for a long stretch (tens of seconds to minutes). Manual lock (while awake) is usually fine.

Journal slice (one bad resume) — USB re-enumerates the reader, fprintd is mid-verify / busy, greeter PAM then times out on ReleaseDevice:

lid opened / PM: suspend exit
usb 3-3: USB disconnect … new full-speed device 06cb:00fc
fprintd: Async command sending failed: USB error on device 06cb:00fc : No such device [-4]
fprintd: Verification was in progress, stopping it
fprintd: Unexpected error while suspending device: The device is still busy with another operation
cosmic-greeter: pam_fprintd(cosmic-greeter:auth): ReleaseDevice failed: Connection timed out

Same boot also shows recurring:

• fprintd: Failed to install a sleep delay inhibitor: … OperationInProgress
• two net.reactivated.Fprint.Device/* objects for one physical reader after re-enum (stale dual Device nodes)

Overlap with existing reports

• Matches the resume race described in closed Fingerprint authentication fails/hangs on resume from suspend due to fprintd restart race condition #470 (fprintd/USB vs greeter not re-starting PAM).
• UI cannot fall back to password while pam_fprintd owns the single conversation (this issue).
• locker: restart PAM conversation on user activity after authenticator windows expire #493 (restart conversation after authenticator window expires) would help the “stale window” case; it would still need a resume / device-change trigger for the USB-death case above.
• Draft RFC: Unlock using fingerprint scanner #480 (parallel password ∥ fingerprint workers, GDM-style) is the architectural fix for “always type password OR use sensor”.

Local workaround we are testing (not a greeter patch): system-sleep post hook that systemctl restart fprintd ~1.5s after resume, plus optional shorter pam_fprintd timeout= so serial PAM falls through sooner. Happy to re-test greeter patches (#493 / #480) on this hardware.

[erik-balfe]

Warning: pam_fprintd_grosshack crashes cosmic-greeter (locker)

We tried pam-fprint-grosshack for “password ∥ fingerprint” on the lock screen. It is not safe with current greeter architecture.

Environment: Fedora 44, cosmic-greeter 1.3.0, locker path, auth sufficient pam_fprintd_grosshack.so then pam_unix try_first_pass.

What happens: grosshack spawns a pthread that calls pam_prompt (password) while the main PAM thread runs fprintd verify. On fingerprint success it pthread_cancels the password thread.

Result (journal 2026-07-27):

cosmic-greeter: gkr-pam: no password is available for user   # fingerprint unlock path
kernel: tokio-rt-worker: segfault … in cosmic-greeter
ANOM_ABEND … pid=… comm="tokio-rt-worker" exe="/usr/bin/cosmic-greeter" sig=11
coredump stack:
  #0 tokio::sync::mpsc::list::Rx::pop
  #1 cosmic_greeter::locker::Conversation::prompt_value
  #2 ConversationHandler::prompt_echo_off
  #3 pam_client::ffi::pam_converse
  #4 pam_vprompt / pam_prompt

So the “hang after failed sensor / weird unlock” is often a greeter crash mid-conversation, not only fprintd busy.

Implication: dual auth needs two separate PAM conversations (GDM-style / draft #480), not a multi-threaded single conversation. Greeter’s Conversation + single mpsc password channel is not re-entrant.

We’ve rolled back to short-window serial pam_fprintd (max-tries=2 timeout=8) + pam_unix locally so password is never more than ~8s away and the greeter stays alive.