You are not logged in.
I made a fresh install last sunday, started up and logged in again today, updated packages. Now I could not log in anymore (had not made a normal user yet).
Booted the install USB and chrooted in, changed password. Still the same after rebooting to installed system.
Did a new install, set password for root in arch-chroot and rebooted - password not valid.
I am now thinking there is something strange in a package updated during the week that messes this up. I have done dozens of Arch and Arch32 installs.
Offline
Broken PAM modules hit stable:
Aug 22 18:05:03 arch32-stable-pentium4 lightdm[628]: PAM unable to dlopen(/usr/lib/security/pam_faillock.so): /usr/lib/security/pam_faillock.so: cannot open shared object file: No such file or directory
Aug 22 18:05:03 arch32-stable-pentium4 lightdm[628]: PAM adding faulty module: /usr/lib/security/pam_faillock.so
new pambase 20200721 references a pam_faillock.so, which doesn't exist.
This happens on 32-bit and ARM, not on 64-bit.
This breaks all kind of logins, also the text consoles. Logins via ssh are still possible.
You can edit /etc/pam.d/system-auth and comment out the lines wih pam_faillock.so
I'll have a look why pam doesn't currently build faillock..
Offline
That did the trick
Thank's for sharing!
Edit:
Just for info - I changed the password of my normal user while chroot'ed from the install ISO, and booted to my installed system. Then I logged in and changed my password again, this time as my normal user. The situation now is that my normal user has the new password, but sudo requires the password I set from chroot
Last edited by Ferdinand (2020-08-22 18:04:56)
Offline
I noticed a month or two ago that when I turned on my Arch64 box in the other room and returned to the living room, I still had to wait until I could ssh in. I can't quite remember what happens when you try to log in, perhaps the ssh connection just stalls. But if you tried after a few minutes it would work fine. I've not noticed this happening recently (although I've not updated my arch64 box for a few days now, so perhaps this new nastiness is still awaiting me). I did notice that on my Arch 32 laptop, yesterday my xscreensaver password dialogue would automatically dismiss itself a moment after appearing, making it hard for me to unlock my machine. I rebooted and disabled locking for now. Today with logging in on the terminal it take a suspiciously long time to confirm my login, which made me start to think I'd typed an error, but it eventually came good. I last updated at 08:24 UTC yesterday and did get some pam modules, but maybe not enough to make this horrible for me yet.
Edit: I got pam 1.4.0 and pambase 20200721.1 yesterday when I updated so perhaps this is the nastiness but I've just been lucky. I don't use an xgreeter, just log in to text mode then startx.
Edit2: Is your announcement strictly correct? You start:
If you use pam 1.3 and pambase 20200721
I got pam 1.4 yesterday. This looks suspicious, but may be fine.
You finish with:
I would suggest to downgrade to pam 1.3.1 and pambase 20190105.1
Downgrade pam 1.3 to 1.3.1? Shurely shome mishtake?
Last edited by levi (2020-08-22 18:34:58)
Architecture: pentium4, Testing repos: Yes, Hardware: EeePC 901+2GB RAM+OS half on the SD card.
Offline
Actually I meant pam 1.3 and new pambase. Because this was now a common situation somebody could have
hit since yesterday. Then I pushed pam 1.4, this made it compatible with the new pambase, but breaks other stuff.
Offline