Follow-up 2026-11-02: the trigger is confirmed (reproduced on demand),
and I have a workaround.
Reproduction, with the wireless mouse on and USB wakeup of its receiver enabled
(as it was on my system):
- 18:28:07 locked the session and closed the lid; the system suspended in the
same second.
- ~18:30 moved the wireless mouse. 18:30:05: "PM: suspend exit" without "Lid
opened" (an extra wake-up with the lid closed).
- 18:30:35 (30 s later): fprintd: "Device reported an error during verify:
Cannot run while suspended." followed by "Error closing device after
disconnect: The device is still busy with another operation, please try again
later."
- 18:30:36: suspended again. 18:32:07: lid opened; the lock screen showed no
fingerprint option (password worked).
Same procedure after disabling USB wakeup for the mouse receiver (a Logitech
Unifying Receiver, 046d:c52b, bus 1 port 3; echo disabled >
/sys/bus/usb/devices/1-3/power/wakeup):
- 18:45:05 closed the lid, ~18:47 moved the mouse, 18:49:10 opened the lid.
- No extra wake-up and no fprintd errors in the journal. The fingerprint option
was shown and worked.
Also, in 3 consecutive lid-closed cycles (2026-10-31 20:54 to 2026-11-01
06:47, 2026-11-01 23:11 to 2026-11-02 05:51, 2026-11-02 09:57 to 17:41)
I switched the mouse off before closing the lid; the journal shows no
extra wake-ups and no fprintd errors in them. Fingerprint worked in
these, but that is from my memory, not from the logs.
So the sequence appears to be: an unexpected wake-up while the lid is
closed -> the lock screen starts fingerprint verification via fprintd ->
the system suspends again after about 30 s (matching the systemd-logind
default HoldoffTimeoutSec of 30 s), in the middle of the verification ->
fprintd/libfprint does not recover cleanly and the fingerprint option is
missing at the next unlock. The mouse is only the trigger I found. I
think the underlying problem is that fprintd/libfprint (or the way the
lock screen uses it) does not handle a suspend that interrupts a
verification, so any other unexpected wake-up could cause the same
failure. I have not tested other wake sources.
Side check: with the receiver's wakeup disabled, the laptop's built-in
touchpad still wakes the system from a menu-initiated suspend (lid
open), and the fingerprint option was shown on the lock screen
afterwards.
Workaround in place: a udev rule (ATTRS{idVendor}=="046d",
ATTRS{idProduct}=="c52b", ATTR{power/wakeup}="disabled") disables wakeup
from the mouse receiver. After replugging the receiver (kernel log: "usb
1-3: USB disconnect" followed by "new full-speed USB device"),
/sys/bus/usb/devices/1-3/power/wakeup reads "disabled". This avoids the
trigger on my setup but not the underlying fprintd/libfprint behaviour.
Question: should fprintd/libfprint recover the reader after a suspend
during verification, or is this something the lock screen (gnome-shell)
should handle, for example by cancelling the verification before
suspend? I'm happy to collect any additional debug output.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2167445
Title:
Fingerprint reader stuck after wake-up with lid closed and immediate
re-suspend (fprintd: Cannot run while suspended)
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/fprintd/+bug/2167445/+subscriptions
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
