I have my PC set up to dual Manjaro or Windows (installations are on separate disks).
I haven’t booted Manjaro for a while, so when I checked the updates there were a lot to run. I resyced the mirrors then went for a “full system update”. This ran to completion, so I rebooted to start the new kernel.
Issue- I can’t log in
The update seems to have damaged my password entry somehow. My username is still listed (I am the only user of this machine) but my password is now invalid so i can’t log in.
I tried to bring the system up single user so I could manually reset my password, but the Grub option to start single user fails with an error saying it can’t find the correct vmlinuz (5.8.x I believe) file.
I found another report of something that might be connected here. I don’t seem to be able to add a link, so search for:
new-install-password-resets-after-login
I assume I will have to boot from a USB stick, mount the root partition and rewrite the password file. Reporting this here to find out if other people are running into similar problems.
UPDATE
I booted to a live linux USB stick, mounted the Manjaro root partition, then following a guide I found on the on the web I used a 3-line Python script to check the password entry in /etc/shadow against my plaintext password. This succeeded.
So, my stored password is NOT corrupted, but I still can’t log in. This seems to imply a bug somwhere in the login path that is mis-handling either the entry of my plaintext password, or the hashing and comparison of the value.
I am having same issue. New install, all good, downloaded a bunch of apps, then went to Apps Bauh and it did a syst snapshot and now, “password is incorrect”.
Had worse password issue with Cent OS on first boot after install. Searching found a (*) changed to a (!) somewhere in the system files. Bad Bug still not addressed and been around for a long while from what I saw. I can’t find a stable distro that will install correctly AND render the display correctly on my monitor, besides Ubuntu and Mint, which are not stable but work.
Wish somebody would fix the issue for everybody.
If I am correct you need to ‘fix’ it yourself. Please follow the instructions at the link above.
(note - this is how arch/manjaro works. Its one of the basics of administering a rolling system)
Thanks for the pointer @cscs. Having been running a Debian home server before which has been “fit and forget” for nigh-on 5 years i’m not familiar with the ways of a rolling distro yet.
After some awkward fiddling around while booted from a live environment I came to the conclusion that some changes to /etc/pam.d/system-login might be the culprit.
I made some guesswork-based merges of the existing file and the .pacnew file and I can log in now, but I must admit I felt I was groping around in the dark with no information on WHY the various files indicated by .pacnew versions had changed in the update, so which lines were essential to incorporate and which weren’t.
In your particular case of pam it was most likely this old thing which I wrote up as one of the first to try and document the ‘proper handling’ of that situation … as all pacnew situations can be wildly different in and of themselves, let alone system-dependent.
I had no need of failed login count based account locking, so removing pam_tally2 seemed a safe bet.
However I had tweaked system-login to enable pam based automounting of home dirs. It was a while since I set this up, and I couldn’t remember all the details. I ended up with pam_mount in all the system-login sections which is probably overkill, but it works, and maybe at some point i’ll go back over it and see if i can clean up any unnecessary entries.
