Login typing anomaly

I start up my Rocky 9.3 work station laptop most days.
Usually, I select myself (the only non-root user on the system) on the login page and can immediately type in my password.
Occasionally, however, I have to wait for over a minute after selecting the user before it will accept any password typing.
After that, all is normal.

Is there a greeter log in /var/log/gdm ? It might be lightdm, just depends on the display manager that is used.

/var/log/gdm exists but is empty

You can install rsyslog which will then populate the logs in …/gdm or you can use journalctl and pipe to grep.
journalctl -b | grep greeter

Read man journalctl for numerical options to “-b” and other means to parse the journal.

Journalctl -b|grep greeting returns nothing and a scan of the full output shows nothing to explain the delay.

The last few lines in dmesg are:
[Sun Mar 3 16:48:24 2024] Bluetooth: RFCOMM ver 1.11
[Sun Mar 3 16:49:41 2024] input: AT Translated Set 2 keyboard as /devices/platform/i8042/serio0/input/input33
[Sun Mar 3 16:50:00 2024] rfkill: input handler enabled
[Sun Mar 3 16:50:01 2024] Lockdown: systemd-logind: hibernation is restricted; see man kernel_lockdown.7
[Sun Mar 3 16:50:01 2024] rfkill: input handler disabled

The sequence varies slightly between reboots but the Lockdown message is constant.
What does this mean?
Can I fix it?

This issue seems to have been fixed in the latest round of updates.
No idea which one.

Spoke too soon. The delay is now much less frequent but still occasionally happens.

Are you sure it’s “a minute”, have you tried timing it, and is the delay always exactly the same amount of time?

Have you ever installed any packages onto that machine that are not in the official repos?

Delay time varies randomly from zero to about two minutes.
This is a laptop workstation which gets started multiple times each day.
Zero times seem more common since recent Rocky updates.

Ok, it sounds strange. Are you able to ssh into it from another box?

If so, you could try watching journalctl (without grep) at the exact moment of the freeze.

Have you tried switching the cog wheel between x11 and wayland before entering the password?

Again, have you ever installed any packages that are not in the official repos?

Please can you type journalctl -b
and journalctl -xe

and dmesg (check hardware 101)

Further testing shows that the delays only happen for the first login after booting (which I usually do several times each day) and only for local logins. If I ssh in, there is no delay and if I logout/login repeatedly, there is no delay.
I can see nothing particular in either dmesg or journalctl. The only “different” software installed is wine for a failed attempt to get Adobe Acrobat to work under Rocky.

Can you try:
Start up the box, don’t login the GUI.
ssh into it (no delay) and start things like journalctl and top
now try to log in locally the GUI and watch the readings on the ssh session.

Here is what gets journaled during the GUI login.
Today’s examples all have small delays.
May 28 14:15:51 spitfire.sdc.com.au systemd[1]: Starting Fingerprint Authentication Daemon…
May 28 14:15:51 spitfire.sdc.com.au systemd[1]: Started Fingerprint Authentication Daemon.
May 28 14:16:22 spitfire.sdc.com.au systemd[1]: fprintd.service: Deactivated successfully.
May 28 14:16:54 spitfire.sdc.com.au kernel: input: AT Translated Set 2 keyboard as /devices/platform/i8042/serio0/input/input49
May 28 14:16:55 spitfire.sdc.com.au systemd-logind[931]: Watching system buttons on /dev/input/event14 (AT Translated Set 2 keyboard)
May 28 14:17:04 spitfire.sdc.com.au systemd-logind[931]: New session 6 of user scldad.

Is this using the laptop keyboard?
Can you force it to use an external keyboard, before it gets to the GUI login?

That seems to work.
I plugged in a USB keyboard and the two lines with “AT Translated” disappear from the journal and there is no delay.
The external keyboard is a bit difficult to use with the touchpad and an external mouse adds more clutter to the desk and does nothing for my other Gnome menu right-click issue.
Any chance of being able to fix the keyboard?

Good news that you found the problem.

So it seems something wrong with the laptop or it’s keyboard (or interface).

Maybe check the vendor and other people with same make and model. Check if there are any BIOS updates.

It says something about ‘i8042’, maybe PS/2, sounds really odd, but maybe that’s how laptops work.

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.