Password auth failing randomly on Lock Screen

[sepulworld]

Anyone else having this issue. My computer will go into the lock screen. I entered the password which I know is 100% correct but it says authentication failed. I'll try multiple times.

Eventually reboot the computer and things are fine after that.

Issue will happen again after some random amount of time (days or weeks for me).

I'm on a Beelink SER 8

[petarm]

I have just faced the same issue.

[aneksz]

This happens to me on login as well, not only the lock screen. After several attempts, it eventually works. I've disabled the idle lock completely for the same reason, as it was happening on the lock screen too.

[dotsilva]

I faced a similar issue, but it was in terminal, i knew it was the correct password, but it failed, so i typed it in plain text and ctrl+shif+c / ctrl+shift+v it and still failed. Then i restarted the laptop and it worked again.

[aneksz]

My issue is the encryption, it seems to get corrupt for some reason. Since I'm using a PC and not a laptop, I've installed a fresh minimal copy of Arch, without the encryption and then installed Omarchy. Which disables the need for a password login, and loads Omarchy automatically.

[sepulworld]

What service is in charge of idle lock? Maybe we need to check issue tracker there

[sepulworld]

Looks like hypridle. Maybe there are some clues in the logs

https://wiki.hypr.land/Hypr-Ecosystem/hypridle/

Hopefully the reboot doesn't clear the logs. Assuming systemCTL controls it. So logs should be there. I'll dig around and see if I find anything.

[aneksz]

I've changed this line in hypridle.conf inhibit_sleep = 3 to 0 which disables it. I've also stopped hypridle from starting in the hyprland.conf just in case.

[mlive1992]

I also have the same issue and it is happens on both lockscreen and terminal randomly for me!

[sepulworld]

Let's document how to turn up trace or debug mode on hypridle and hyprlock. Then if we all flip it on, maybe we'll catch some information in the logs after a reboot.

[paul-fornage]

I had this happen once too, but I use Omarchy on 3 machines all day, so it can't be common. I actually had someone else try the password and they failed too. Fixed after a nervous reboot.

Have not had it happen in terminal/sudo

[dotsilva]

The random failing happened to me today again and while typing the password very carefully something came to my mind "what if for some reason it is trying to read the Enter as part of the password and because this it fails?" i have not the technical knowledge to investigate, but i would like to contribute my 2 cents with this hypothesis. Anyway, it is not something that happen very often and the reboot fixed it each time.

[mrdrbrdr]

I Think i know why This happens. What language have you mapped to your keyboard?

I’ve mapped Danish to laptops keyboard, but when I’m either on lock screen or the Linux booting from a USB, it is consistently mapped to English.

this results in special characters not being consistent, and hence your pc won’t accept your password

[paul-fornage]

I thought of this too, but I am on US only, and it still doesn't explain the inconsistent nature of the problem.

If everyone else has international keyboards, I won't rule out me being slow in the head or some other problem in my case, but I don't think this is the case.

[dotsilva]

I Think i know why This happens. What language have you mapped to your keyboard?

I’ve mapped Danish to laptops keyboard, but when I’m either on lock screen or the Linux booting from a USB, it is consistently mapped to English.

this results in special characters not being consistent, and hence your pc won’t accept your password

It is possible too, but not because of the English part. The thing is my "kb_layout" is "br" and i am used to use caps:lock instead of shift while typing password, but in Omarchy defaults the caps key is compose for emojis, so it is possible, at least in my case.

[jcarlosbecker]

Having the same problem...waiting for solution....

[topazrn]

I experienced this problem immediately after restarting my system following the upgrade to v3.0.1. I was also unable to log in on the second TTY. To rule out a keyboard layout issue, I typed my password in the username prompt and confirmed it was not the cause. A subsequent restart resolved the problem, and I am now able to log in successfully.

[dotsilva]

In my case was the caps key, confirming the theory commented above! Yesterday i was failing the login password, so i typed carefully and it still failed, then i decided to test this and instead of caps look i choose shift for caps letters and it worked, but i would like to say i made a mistake in my other comment, the caps thing is not from my keyboard layout, its because i changed it from the emoji stuff to caps:lock and when the system decides to use the defaults, it comes to its default emoji thing and my password fails, so, at least for my case, this mystery seems to be solved.

[cellexec]

Also have this problem. Currently i've disabled it, til we know how to fix it... :/

[cellexec]

BTW! I might figure it out.... 🎉

My password has multiple symbols or uppercase letters, that need to press Shift. However if multiple symbols/letters in sequence use the Shift key, it sort of get "consumed".

What does that mean?

Imagine your password is:

Password!!

Pressing Shift(and hold it) for both !, this password becomes:

Password!1

So to make it work, I needed to hold & release the Shift key for each symbol/letter again.

Hope this helps :)

[AV3RG]

The caps lock or shift key is not the issue, my purely alphanumeric passwords are also failing

[cdevroe]

I also experienced this once on 3.0.1. I rebooted and I haven't experienced it again. It didn't have anything to do with keyboard language or shift key.

[BotConan]

Same problem! but in the cmd when asked the sudo password. I thought it was a language issue but it was not, as I tried it both es and us keyboards.

[kfnx]

I have same problem. fresh install via USB omarchy ISO just now. I restarted laptop and make sure the password is correct, it only happen on idle lock screen

*UPDATE:
I think its a UX misinterpretation.
I pressed enter first before the actual password, for me its a habit to intuitively press any key just to make the password textbox showing.. like in mac OS or windows.
but actually any key pressed is included as the password.. so dont do that and I can login back just fine!

[alexhraber]

great point -- it could be that people wake the laptop up by pressing a button -- but I've had my laptop lock while it's right next to me (inactive while eating, for example) and I immediately type my correct password in (1 character) and it fails. Then continues to fail until I reboot. Later, it locks again, I type my single-character password in, and it works.

[alexhraber]

I also just locked my laptop (after typing the above reply ⬆️), intentionally typed the wrong password, failure -- typed correct password, it unlocked and I'm back here typing this reply.

[abdo-spices]

it happens to me again when i fail to enter the password in the terminal correctly for the first time and the only fix is to restart the pc

[alexhraber]

It happens to me ~ 20% of the time, I'm definitely not typing the password in wrong. And it never lets me in, it fails 20 - 30 times, and I finally reboot, type my password in to decrypt, and keep using the computer.

[dhh]

Any ideas @vaxerski?

[PaideiaDilemma]

Some other comments in this thread here make me think it's more likely to be a pam related issue.

[alexhraber]

That's super inquisitive @PaideiaDilemma -- I was separately having an issue w/ key strokes being dropped by the kernel and had to modify /etc/default/limine for some KERNEL_CMDLINE tuning. Specifically, I added:

KERNEL_CMDLINE[default]+=" i8042.nomux=1 i8042.reset i8042.noloop i8042.nopnp=1  intel_idle.max_cstate=1"

Further, I did some battery<>cpu tuning which reduced bottlenecks. Since applying these changes, key stroke drops have decreased by an order of magnitude (but still happen occasionally) and I've happened to not experience this lockscreen issue since. When in the lockscreen if I observe a dropped keystroke, I meticulously type the correct password in, and it's succeeded since the change.

Originally before these changes, it didn't matter if I typed the password correctly innumerable times, it would fail until I rebooted.

Note to time travelers:

1. My limine fill will be different than yours due to my specific hardware
2. If you change your limine file, make sure to apply before rebooting:

sudo systemctl restart limine-snapper-sync.service
sudo shutdown -r now

Full limine contents for reference:

❯ sudo cat /etc/default/limine
[sudo] password for arx:
TARGET_OS_NAME="Omarchy"

ESP_PATH="/boot"

KERNEL_CMDLINE[default]="cryptdevice=PARTUUID=e0486321-02:root root=/dev/mapper/root zswap.enabled=0 rootflags=subvol=@ rw rootfstype=btrfs"
KERNEL_CMDLINE[default]+=" i8042.nomux=1 i8042.reset i8042.noloop i8042.nopnp=1  intel_idle.max_cstate=1"
KERNEL_CMDLINE[default]+=" quiet splash"

# Find and add other bootloaders
FIND_BOOTLOADERS=yes

BOOT_ORDER="*, *fallback, Snapshots"

MAX_SNAPSHOT_ENTRIES=5

SNAPSHOT_FORMAT_CHOICE=5

[alexhraber]

Some other comments in this thread here make me think it's more likely to be a pam related issue.

I see why PAM could look guilty here — but I think the root cause lives deeper in the input path. PAM would only fail if it’s receiving bad data.

If keystrokes are registering as null or incorrect characters, the failure isn’t authentication — it’s that the kernel’s input stack is occasionally misinterpreting scancodes when the CPU spikes. The i8042 handler itself is deterministic, but the timing window between interrupt, ISR handling, and userland read isn’t. When intel_pstate ramps frequency or migrates cores, you can get just enough latency or cache desync for a byte to drop or flip.

In that case, PAM ends up hashing a malformed string and rejecting it — totally unaware the corruption happened earlier.

So in practice, it’s deterministic hardware behavior expressed through non-deterministic load timing (like brief latency during CPU ramp-up).

To confirm: monitor /proc/interrupts for i8042 events during a stress test, check dmesg for “spurious ACK/NAK” logs, and compare scancodes in evtest while the CPU governor ramps. Even a single mismatch would support that theory.

[PaideiaDilemma]

it’s that the kernel’s input stack is occasionally misinterpreting scancodes when the CPU spikes.

That is kinda crazy if true. Its hard to believe that the kernel has problems with a PS/2 signal. More likely the signal is bad I think.
Maybe try to disable "USB Legacy Support" in case you have that in your bios? Cause if that is enabled, your main board might be converting the USB protocol of your keyboard to PS/2.
Or maybe the system has some latency min-maxing for gaming somewhere and that effects it?

[alexhraber]

It's a laptop keyboard, no external peripherals connected.

Happy to test disabling usb too, but this laptop model uses a ps2 connection for the keyboard.

[Muf454]

Also just had this issue happen to me.

[sepulworld]

if we update the autostart.conf we can put logs into systemd journal.

I suggest we add -v as well to see if there is an issue with hypridle or rule it out... maybe a lower level issue with PAM.

How to debug if you are seeing this issue

1, update autostart.conf to have hypridle send logs to journal (it presently doesn't) and bump up verbosity

sed -i 's|exec-once = uwsm app -- hypridle|exec-once = uwsm app -- sh -c '\''hypridle -v 2\>\&1 \| logger -t hypridle'\''|'
  ~/.local/share/omarchy/default/hypr/autostart.conf

2. reboot

3. If issue happens to user, they can reboot to get back in and then look at the logs to capture more details.

check hypridle logs in journalctl

journalctl --user | grep -i hypridle

check sudo logs in journalctl if user encountered a sudo escalation password issue.

journalctl -u sudo

[sepulworld]

It might be worth checking in a change to Omarchy autostart.conf to at least log non-verbose (should capture errors) to Journald for hypridle

exec-once = uwsm app -- sh -c 'hypridle 2>&1 | logger -t hypridle'

[sepulworld]

#2245 in case we want to consider turning on regular logging to journald for all users as a default. Would only take effect after and update and reboot. Seems like some of these core services should log to journald anyways.

[mskemalfasya]

same problem here :(

[moke-codes]

I was having the same issue and then I disabled the fingerprint in the hypridle.conf. The issue seems to have stopped.

[sepulworld]

Good discussion. I think the main key takeaway right now for me is how do we get better logging and perhaps simple script to capture all relevant logs in sort of a crash report format. So post reboot you can gather up all the details easily and share here. Maybe we'll find the root cause.

[TomsLielkalns]

obligatory - same here, just installed the os

[mcdent]

Same here. Day 2 with Omarchy. Laptop put to sleep. Wake up, won't accept my password.
Switch to F2 terminal and exact same password and boom, logged in fine?!
Restarted and can login to Wayland fine. Odd??

I actually thought I had lost my mind for a short period of time. The last thing I thought it would be was a bug in the os/distro, this being such a basic thing to get right. Felt sure I must have fumbled the initial password! Then thankfully I found this thread.

[rsd]

Anyone else having this issue. My computer will go into the lock screen. I entered the password which I know is 100% correct but it says authentication failed. I'll try multiple times.

Eventually reboot the computer and things are fine after that.

Issue will happen again after some random amount of time (days or weeks for me).

I'm on a Beelink SER 8

I had an issue like this and found out that it was a pam problem.

More specifically pam_faillock.so (in /etc/pam.d/system-auth).

After a few wrong passwords, it will lock you out for sometime (unlock_time) even with the correct password, even in the console.
The sensation is that some auth service crashed or the system got corrupted.

[followbl]

this makes Omarchy completely unusable for me - I can't have a completely unreliable OS randomly forgetting my password and interrupting all of my work randomly throughout the week. Leaving my work station completely unlocked is not an option either.

[d-cas]

I had this same issue. If someone finds a way to re-create it intentionally please post. Would love to troubleshoot this further. Post to #2094 please

[sepulworld]

Thanks for linking up discussion with an Issue.

[rsd]

I had this same issue. If someone finds a way to re-create it intentionally please post. Would love to troubleshoot this further. Post to #2094 please

Please, check if this is your case or not.
I changed my defaults a while ago, so your mileage may differ.

• Go to a console (e.g. CONTROL ALT F3)
• Type your username
• type a wrong password (like having CAPS LOCK on)
• repeat 3 times.
• Now enter the correct password. Pam will lock you out for some time.

If this happens it is because of pam_faillock.so in /etc/pam.d/.