Password is not working after short period of time

[sorrowcode]

Hello everyone,

I am using Garuda Linux already 3 months now and I am very happy with it.
It's also my first Linux Distribution.
Yesterday I wanted to install a software and was asked for my password.
I typed the password the first time and got the message:
"Authentication failure, please try again."
I thought that I maybe misspelled it so I tried it again and slowly.
I got the same message.
I restarted my computer and tried it again and it worked.
After a few minutes I wanted to install another software and ended up with the same issue.
It worked only after a restart.
What are the options I can do?

[SameExpert]

It's a KDE problem happens to me quite often. Waiting to see what others reply....

[jonathon]

This is a "security feature" - if you type your password incorrectly three times then login will be locked.

You can use the command faillock to see how many incorrect attempts have been made (and when) and you can clear these failed attempts with faillock --reset. Rebooting the PC has the same effect.

[Bro]

@SameExpert

It’s a KDE problem happens to me quite often.

It is not a very common problem. What’s wrong with your KDE?

[Naman]

Hi there, welcome to the community.

This might be also an issue if you are using two or more locales.
In this case, keep the password numerical only(just a workaround).

But it is very difficult to comment with the scarce information you have provided.

Post

inxi -Fza

[zoeruda]

Have you tried logging in as root and changing the password?

[SameExpert]

Don't know what exactly the reason. These two problems occur to me (I'm sure this is same as OP's problem) not regularly, but at some unknown time:

They happen ONLY sometimes if my PC is awake idle for long time (like ~2 hours), or after waking from sleep:

1. Only when GUI prompts for password, it says incorrect password. But in terminal sudo accepts the password.
2. Cannot unlock screen (after waking from sleep), SDDM says incorrect password. I need to switch to TTY and then reboot (here my password is accepted).

Since I don't know how to get logs for this to report, I haven't gone through bug reporting process.

[dr460nf1r3]

Hey, I'm not the only one experiencing this Especially 2. happens at times, haven't found any cause or correlation yet, it just happens. Actually I send my device to sleep rarely so I didnt mind it until now, unlocking via changing TTY, logging and and typing "loginctl unlock-session insert number" (or unlock-sessions for every session) is a nice workaround. No need to reboot every time

[SameExpert]

@dr460nf1r3

loginctl unlock-session insert number

Oh thanks for this . I was always rebooting

The feeling, when I see others, especially some experienced and knowledged person like Nico, having the same problem, makes me feel kinda somewhat relieved

[Bro]

@SameExpert

The feeling, when I see others, especially some experienced and knowledged person like Nico, having the same problem, makes me feel kinda somewhat relieved

I understand that, and you’re doing the right thing. That’s how Nico got the experience & knowledge he has obtained to-date. And I’ll betcha tomorrow and next week he’ll have gained even more. And so will you!

The only “problem” I recall happening to me since adopting Arch in 2013, was networkmanager several years back. By then I knew enough that rolling it back until the bugfix was upped was a no-brainer (it helps to read the Arch homepage & forums daily). And it was much easier to “fix” in Arch than when bug-prone networkmanager went bad in Debian Testing.

But nowadays I don’t have the heavy workload in Linux like prior years. I generally run a hand-installed vanilla Arch + Plasma and don’t need much in the way of bells-n-whistles-n-applications like heavier-tasked users, so my simpler systems tend to be pretty stable.

And I’ve learned not to sweat the small stuff, unlike my scurrilous pal @mandog. ()

[sorrowcode]

Yes, I have. But got the same problem with the new password.

[sorrowcode]

yes, still the same

[petsam]

If you need help finding the source of the problem (and not a workaround), you have to provide more info.

inxi -SMGIaz
locale
localectl
cat /etc/locale.conf
cat /etc/vconsole.conf
cat $HOME/.config/kxkbrc

[mandog]

@Bro

And I’ve learned not to sweat the small stuff, unlike my scurrilous pal @mandog. ()

Smart users like mandog use Gnome problems sorted

[Bro]

I'll GNOME you, you you you...GNOME!

[mandog]

You dare i'll eat your Budgie ha ha

[Bro]

It's not a goddamned Budgie, she's a full-sized Parrot, dammit, and you know so!

[sorrowcode]

System:    Kernel: 5.12.10-zen1-1-zen x86_64 bits: 64 compiler: gcc v: 11.1.0  
parameters: BOOT_IMAGE=/@/boot/vmlinuz-linux-zen root=UUID=edf82e87-4844-41a9-8630-0695406c6e57  
rw rootflags=subvol=@ quiet splash rd.udev.log_priority=3 vt.global_cursor_default=0
systemd.unified_cgroup_hierarchy=1 loglevel=3
Desktop: KDE Plasma 5.22.0 tk: Qt 5.15.2 info: latte-dock wm: kwin_x11 vt: 1 dm: SDDM  
Distro: Garuda Linux base: Arch Linux  
Machine:   Type: Laptop System: HP product: HP Laptop 15-db0xxx v: Type1ProductConfigId serial: <filter>  
Chassis: type: 10 serial: <filter>  
Mobo: HP model: 84AE v: 86.21 serial: <filter> UEFI: Insyde v: F.15 date: 12/04/2018  
Graphics:  Device-1: AMD Raven Ridge [Radeon Vega Series / Radeon Vega Mobile Series]  
vendor: Hewlett-Packard driver: amdgpu v: kernel bus-ID: 05:00.0 chip-ID: 1002:15dd  
class-ID: 0300  
Device-2: Cheng Uei Precision Industry (Foxlink) HP TrueVision HD Camera type: USB  
driver: uvcvideo bus-ID: 3-2.1:4 chip-ID: 05c8:03c7 class-ID: 0e02 serial: <filter>  
Display: x11 server: X.Org 1.20.11 compositor: kwin_x11 driver: loaded: amdgpu,ati  
unloaded: modesetting alternate: fbdev,vesa display-ID: :0 screens: 1  
Screen-1: 0 s-res: 1920x1080 s-dpi: 96 s-size: 508x285mm (20.0x11.2") s-diag: 582mm (22.9")  
Monitor-1: eDP res: 1920x1080 hz: 60 dpi: 142 size: 344x193mm (13.5x7.6") diag: 394mm (15.5")  
OpenGL: renderer: AMD Radeon Vega 8 Graphics (RAVEN DRM 3.40.0 5.12.10-zen1-1-zen LLVM 12.0.0)  
v: 4.6 Mesa 21.1.2 direct render: Yes  
Info:      Processes: 289 Uptime: 26m wakeups: 4 Memory: 7.49 GiB used: 3.34 GiB (44.6%) Init: systemd  
v: 248 tool: systemctl Compilers: gcc: 11.1.0 clang: 12.0.0 Packages: pacman: 2036 lib: 566  
Shell: fish v: 3.2.2 default: Bash v: 5.1.8 running-in: konsole inxi: 3.3.04  
LANG=en_US.UTF-8
LC_CTYPE="en_US.UTF-8"
LC_NUMERIC=de_DE.UTF-8
LC_TIME=de_DE.UTF-8
LC_COLLATE="en_US.UTF-8"
LC_MONETARY=de_DE.UTF-8
LC_MESSAGES="en_US.UTF-8"
LC_PAPER=de_DE.UTF-8
LC_NAME=de_DE.UTF-8
LC_ADDRESS=de_DE.UTF-8
LC_TELEPHONE=de_DE.UTF-8
LC_MEASUREMENT=de_DE.UTF-8
LC_IDENTIFICATION=de_DE.UTF-8
LC_ALL=
System Locale: LANG=en_US.UTF-8
LC_NUMERIC=de_DE.UTF-8
LC_TIME=de_DE.UTF-8
LC_MONETARY=de_DE.UTF-8
LC_PAPER=de_DE.UTF-8
LC_NAME=de_DE.UTF-8
LC_ADDRESS=de_DE.UTF-8
LC_TELEPHONE=de_DE.UTF-8
LC_MEASUREMENT=de_DE.UTF-8
LC_IDENTIFICATION=de_DE.UTF-8
VC Keymap: de
X11 Layout: de
File: /etc/locale.conf
LANG=en_US.UTF-8
LC_ADDRESS=de_DE.UTF-8
LC_IDENTIFICATION=de_DE.UTF-8
LC_MEASUREMENT=de_DE.UTF-8
LC_MONETARY=de_DE.UTF-8
LC_NAME=de_DE.UTF-8
LC_NUMERIC=de_DE.UTF-8
LC_PAPER=de_DE.UTF-8
LC_TELEPHONE=de_DE.UTF-8
LC_TIME=de_DE.UTF-8
File: /etc/vconsole.conf
FONT=ter-220n
KEYMAP=de
File: /home/sorrowcode/.config/kxkbrc
[$Version]
update_info=kxkb_variants.upd:split-variants

[Layout]
DisplayNames=
LayoutList=de
LayoutLoopCount=-1
Model=
ResetOldOptions=false
ShowFlag=false
ShowLabel=true
ShowLayoutIndicator=true
ShowSingle=false
SwitchMode=Global
Use=true
VariantList=

[petsam]

It seems you are using two keyboard layouts, but not configured properly.
Your system-wide layout on Xorg is English (confirm in cat /etc/X11/xorg.conf.d/00-keyboard.conf), on system is English (/etc/locale.conf), on TTY/console is German (/etc/vconsole.conf) and on KDE is German (LayoutList=de configured in System Settings Keyboard layout).

Since you are using both en and de, you should configure this on all places, together with a switch combination.
When Plasma desktop some times crash/restart, the active layout may not reset as expected. It maybe a bug or a feature, but you don't want this to happen, or you should have a way to reset or switch your current keyboard layout. You should know that computer AI is not Human Intelligent (yet).

Use localectl to set Xorg configuration.
Set your console font with vconsole.conf, adding KEYMAP_TOGGLE= for the 2nd layout.
Use KDE System Settings Keyboard for both layouts, adding a keyboard switch toggle.