Root and user passwords suddenly stop being accepted

I did two fresh installs today, and experienced the same issue on both. Not 100% sure, but I believe the same issue happened on an install I did a few months ago.

Using the system normally, with any sudo command accepting the correct password, as it should. After about 5 minutes, it would suddenly not accept the same password, and a reboot fixes it.

Interesting thing is, if a GUI asks for the password (on opening gparted, for example), it would say something like “Only 5 minutes left to unlock!”. When that happens, I know it will stop accepting my password in both GUIs and Terminal, no matter what asks for the password.

A workaround I found is running sudo systemctl enable systemd-homed and sudo systemctl restart systemd-homed

After this, the password works again, and the issue doesn’t happen again. It isn’t that difficult to solve, but the same problem appears on every fresh install, on (at least) the latest two releases of EOS. I really like the distro, the best to dabble in arch, but I don’t think an issue like this should happen so often. Are there other people who encounter the same issue? is there a better way to fix this? I want to learn more, so please, share the wisdom!

I haven’t had something like this happen in about 8 years now. Usually I would run faillock --reset to fix it back then, but I think your issue is different than whatever I used to deal with. No problems with me currently. I’m not using systemd-home though, so maybe an issue specifically with that configuration.

Hmm, faillock --reset probably could have done the trick, didn’t see it mentioned anywhere while trying to solve the issue. systemd-homed was mentioned on a few forum posts though, so that’s why I tried that.

I am not sure what is used by default on Endeavouros, as I’m pretty new to Arch so I have no idea what package is used for what, it’s a long learning process.

However, it’s status printout was loaded (/usr/lib/systemd/system/systemd-homed.service; disabled; preset: enabled), and under Active it didn’t say it was active, but Disabled, and insinuating broken. Unsure of the exact printout thought, I really need to start taking screenshots lol.

I did a fresh install both times using the minimum of selected packages in the installer:

Desktop-base + common packages
Firefox and language packs
Intel microcode
KDE-desktop (on one install) OR Xfce4-Desktop.

Is there another package I probably have installed and should check to disable systemd-homed? I’m trying to keep the package/running services count as low as possible, previous install got to 1500 pacman packages installed in a few months and I have no idea how lol. Mostly just dependencies of things I tested out, and forgot to remove probably.

I don’t know of anything to check. If it is disabled, I’m assuming systemd-homed isn’t actually running. I know I have never used it and the output of systemctl status systemd-homed for me was the same as what you posted. I’m not even sure what systemd-homed is for.

As for the faillock --reset thing. I’m not suprised you never found it. I read it on an askubuntu or stackexhange forum post from like 16 years ago or something. I keep a bunch of personal linux documentation in the form of markdown files, images, pdfs, and even downloaded websites. I made sure to write the faillock thing down at some point. This way, anytime I have a problem I can consult my own docs instead of scouring the internet for it. I think it is just a good habit to have.

Hmm, interesting. Then there must be something else causing this issue on my laptop, if the status of systemd-homed is the same for you, with a working system. Weird that the same issue appeared after 5 minutes on a fresh install with KDE Plasma, and a fresh install with Xfce.

Yes, it is a very good practice to have. I have been scribbling on post-it notes my own guides, but need to move it to a notebook. Whenever if I find a solution for a problem, the next time I encounter it there is no way to find the same fix online, search engines are weird nowadays.

I’ll be sure to write faillock --reset down and give it a shot in case I encounter the same problem again. Thanks for the info!