Ubuntu 26 too long login with fingerprint reader - solution

ubuntu-26-login-too-long-solution.md

The Ten-Second Login

Ubuntu 26.04 · GNOME/GDM · fprintd

Typing your password at the Ubuntu login screen takes ten seconds before the field even reacts, and fingerprint unlock keeps failing — while the same fingerprint works fine for sudo. It isn't your hardware. It's three separate config bugs, and a coding agent with shell access can find and fix all three in about ten minutes.

• Symptoms
• TL;DR: the fix
• The prompt
• Why it happens
• Red herrings
• Two things worth knowing afterwards
• How widely this applies

---

Symptoms

• You type your password at the login or lock screen and nothing happens for ~10 seconds.
• Fingerprint unlock at the login screen works maybe one time in three.
• But the fingerprint reader is rock solid for sudo in a terminal.
• Occasionally a password gets rejected that you know you typed correctly.
• sudo also pauses before asking for a password, even when you never touch the reader.

That third point is the tell. Same sensor, same finger, different reliability depending on whether you're at the greeter or in a terminal — so it isn't the hardware. Something is different about the two code paths.

---

TL;DR: the fix

You don't lose fingerprint anywhere you actually use it. The point is to stop it being registered twice.

1. Keep the reader awake — a one-line udev rule setting power/control to on for your reader's VID:PID.
2. Add pam_fprintd explicitly where you want it — one line with success=done at the top of /etc/pam.d/sudo and sudo-i, before their @include common-auth. Optionally create /etc/pam.d/polkit-1 too, since polkit ships none.
3. Then remove it from the shared stack — sudo pam-auth-update --disable fprintd. This is the step that kills both the 10 s stall and the sensor contention.
4. Reboot and verify by counting:

journalctl -b | grep -c "Device was already claimed"   # should be 0

That number is the whole proof.

The login screen and lock screen keep fingerprint throughout, because GDM has its own /etc/pam.d/gdm-fingerprint stack that never depended on common-auth. What you lose is fingerprint for su and TTY login, which nobody misses.

Why an agent and not a copy-pasted script. PAM is the single gate for every way into the machine. Get common-auth or /etc/pam.d/sudo wrong and sudo, the login screen, TTY login and su all die at the same instant — and fixing it needs a write to a root-owned file. Recovery means GRUB or a live USB. The specifics also vary per machine: your reader's VID:PID, whether it's USB at all rather than SPI, which VT your session occupies, which files include common-auth. An agent reads your actual config and can check that each edit landed — including catching a sed that wrote a literal \t instead of a tab and would have taken out the sudo stack.

---

The prompt

Paste this into Claude Code, or any coding agent that can run shell commands on the machine. It asks for evidence first and changes nothing until you've seen the tradeoff.

I'm on Ubuntu 26.04 with GNOME and GDM. Password auth at the login screen and
lock screen stalls for about ten seconds before it accepts anything, and
fingerprint unlock there is unreliable — but fingerprint works fine for sudo.

Investigate on this machine before changing anything:

1. Show me /etc/pam.d/common-auth. Does pam_fprintd run before pam_unix, and
   what timeout does it have? Check the profile priority in
   /usr/share/pam-configs/fprintd, and list which files in /etc/pam.d actually
   @include common-auth. Check whether polkit has its own PAM file or falls
   back to /etc/pam.d/other.

2. Count "Device was already claimed" in the full journal, and show me which
   processes requested net.reactivated.Fprint around those timestamps.

3. Identify my fingerprint reader (lsusb, fprintd-list). If it's USB, check
   power/control, power/runtime_status and power/autosuspend_delay_ms for it.
   Then check whether libfprint's udev rules mention its VID:PID at all, and
   how many power/control lines those rules contain.

4. Pull one real login out of the journal with precise timestamps so I can see
   where the seconds actually go.

Then explain what you found and what the tradeoffs are, and wait for me before
editing anything. I'd like to keep fingerprint for sudo if that's possible.

Rules: don't hand-edit /etc/pam.d/common-auth (pam-auth-update overwrites it).
Back up every file you touch, outside /etc/pam.d. Before touching the PAM
stack, tell me to open a root shell on a TTY — not a GUI terminal window — and
tell me why. Verify each change actually landed instead of assuming it did.

Works as-is in Claude Code. With browser-only Claude you'd run the commands yourself and paste the output back.

---

Why it happens

1. pam_fprintd sits in front of every password prompt with a 10 s timeout

Enrolling a finger in GNOME Settings pulls in libpam-fprintd, which drops itself into /etc/pam.d/common-auth at a higher priority than pam_unix:

# /usr/share/pam-configs/fprintd
Priority: 260
Auth:
	[success=end default=ignore]	pam_fprintd.so max-tries=1 timeout=10

A PAM auth stack runs top to bottom, one module at a time. There is no "whichever finishes first wins" primitive. So your password cannot be checked until the fingerprint read gives up. From man pam_fprintd, LIMITATIONS:

The PAM stack is by design a serialised authentication.

On a stock desktop install that hits 13 files in /etc/pam.d plus polkit, which ships no PAM file of its own and falls through to other. Login screen, lock screen, sudo, su, TTY login, and every "Authentication is required" dialog.

Journal signature — 14 seconds between the reader waking and any verdict:

11:15:54.407  gdm-session-worker [pam/gdm-password] → net.reactivated.Fprint
11:16:08.576  pam_unix(gdm-password:auth): authentication failure

2. GDM runs two PAM conversations, and they fight over the reader

This is the interesting one. GDM deliberately runs two independent PAM stacks in parallel, so the greeter can offer "swipe or type" with no penalty. Both service names are in the binary:

$ strings /usr/libexec/gdm-session-worker | grep '^gdm-'
gdm-password
gdm-fingerprint

Fine by itself. It breaks when pam_fprintd is also in common-auth, because then the gdm-password worker claims the sensor too. Two clients, one device that serves one at a time, and fprintd rejects the loser:

fprintd: Authorization denied to :1.NNNN to call method 'Claim'
         for device 'Elan MOC Sensors': Device was already claimed
gdm-fingerprint][NNNNN]: gkr-pam: no password is available

My journal held 142 of those. Every single one came from the login screen or the lock screen. Not one came from sudo — because sudo is a single client with nobody to fight.

Who requested fprintd	Result
gnome-shell --mode=gdm (login screen)	already claimed
gnome-shell --mode=ubuntu (lock screen)	already claimed
sudo …	went through

That table is the entire explanation for "works for sudo, not for login".

3. USB autosuspend puts the reader to sleep after 2 seconds

libfprint ships udev rules that keep supported readers awake. On this machine that file was eight lines long, covered only two SPI variants, and contained zero power-management rules:

$ grep -c 'power/control' /usr/lib/udev/rules.d/70-libfprint-2.rules
0
$ cat /sys/bus/usb/devices/<reader>/power/runtime_status
suspended

The driver supported the device perfectly well and the enrolled prints were there. The reader just kept falling asleep after two seconds of idle, so the first touch spent its time waking it up instead of reading. It reads exactly like flaky hardware.

---

Red herrings

Ruled these out with actual numbers so you don't chase them:

Suspect	Measured	Verdict
yescrypt password hash cost	—	not the delay
sss in nsswitch.conf, sssd never starts	50 × getent passwd = 33 ms total	not the delay
Boot time	graphical.target @ 9.6 s	not the delay

All of the time was in the PAM stack. Ask the agent to measure rather than assume — and note that sssd on Ubuntu is a dependency of ubuntu-desktop, so don't apt remove it.

---

Two things worth knowing afterwards

Ctrl+C skips the fingerprint prompt

When sudo asks for a finger and you'd rather type, Ctrl+C cancels just the fingerprint read and drops straight to the password prompt in the same invocation. It does not kill sudo.

Key	Result
Ctrl+C	Password prompt, within milliseconds
Enter	Nothing. It's echoed and the full timeout still elapses
(nothing)	Verification timed out, then the password prompt

No equivalent in GUI polkit dialogs — there you wait, or hit Cancel.

Your greeter's keyboard layout lives in exactly one file

If you use a non-US layout: the greeter runs as a dynamic user whose home sits on tmpfs, and Ubuntu ships no dconf profile for it, so nothing you set per-user survives. The greeter takes the first layout from /etc/default/keyboard via localed. Reorder that — layouts and variants together — and set your session's input-sources to match.

One caution learned the hard way: check stat -c '%y' on that file afterwards. A command nobody ran looks identical to a command that failed.

---

How widely this applies

Cause	Applies to
Fingerprint before password in common-auth	Any Debian/Ubuntu with libpam-fprintd installed. Any reader, any desktop
Two PAM workers fighting over the sensor	Any GDM/GNOME setup where the above is also true
USB autosuspend on the reader	USB readers not covered by libfprint's udev rules. SPI and I²C readers unaffected
Greeter keyboard layout	Any GDM on Ubuntu with more than one layout configured

Found on a Lenovo ThinkPad with an Elan 04f3:0c8c reader running Ubuntu 26.04. Only the third cause is hardware-specific, and even that is a category of problem rather than one device — Goodix, Synaptics and Validity readers land in the same gap.

---

Investigated with Claude Code on a stock Ubuntu 26.04 desktop install, August 2026. Every command output above is real, taken from that machine's journal. Free to reuse.