0

I copied my root filesystem to another partition today, using cp -r --preserve=all, as I want to have a backup in case I have an issue with my main system. I am using Parabola, which is a libre variant of Arch Linux. I have only one /home partition, which both systems will share. After copying the system (using a live USB), I did a full system upgrade using pacman (it was quite out-of-date). When I try to log in to the new system, everything seems to work and it boots to the DM login screen; however, my user password isn't working. So, I switch to a virtual terminal and try to log in as root, but that isn't working either.

So, I go back into the live USB; chroot in to the new cloned root partition and refresh all of the passwords (with passwd), including root. I then reboot, but the exact same thing happens - I still can't log in to either my user account or as root.

Have I missed something here?

Edit:

To clarify, I have not 'cloned' the partition, I have copied a root filesystem (using cp) to a new partition, which I created with gparted (I will change the question title to clarify). So, the new partition has a different UUID to the parent. I had to do some manual tweaks in grub.cfg and /etc/fstab because of that, to get the duplicated system to boot. Is the password system linked to the partition UUID? Could that be the reason for the issues?

Also, I would like to add that, when I ran passwd in the chroot, it gave me a message saying the passwords had been updated successfully (although still no password worked afterwards).

Time4Tea
  • 2,288
  • 5
  • 23
  • 54
  • After `chroot` into the cloned partition, can you run `sudo cat /etc/passwd` and `sudo cat /etc/shadow` to see if they are there and more or less look correct? You don't have to provide output. Also, while `chroot` you should also attempt to create a new user with corresponding password, just to test if you can login with that new account, and if so your problem likely lies with either original `passwd` or `shadow` and you can then attempt the second more dangerous approach: manually editing those fields in `passwd` file itself. – NetIceCat Oct 03 '20 at 03:23
  • Typically with a clone, you have to remove the cloned drive as you cannot have duplicate UUIDs or GUIDs if gpt. If cloned partition, do you have same UUID? Post this in your question: `lsblk -o name,mountpoint,label,size,fstype,uuid,partuuid` – oldfred Oct 03 '20 at 03:26
  • @BarBar1234 yes, `/etc/passwd` and `/etc/shadow` look normal in the new system, as far as I can tell. They were copied over directly from the parent system. I will try adding the new user account, that's a good suggestion. – Time4Tea Oct 03 '20 at 11:35
  • @oldfred thanks for your comment - I have edited the question to clarify. I did not actually 'clone' the partition, I copied the root filesystem to a new partition. So, the new UUID is different. – Time4Tea Oct 03 '20 at 11:45
  • I just find new installs easier than trying to resolve issues of a copy or clone. I was using Ubuntu with fallback (old Gnome menus), and installed Kubuntu to test partition on HDD. Liked it so much did new install to SSD and copied test install's /home to new install to have the changes I made. All data in separate data partition, so /home is tiny and in / partition. – oldfred Oct 03 '20 at 14:01
  • @oldfred I have some specific customizations/tweaks on my system, which I wanted to preserve. I have now resolved the issue and posted an answer as to what it was. Thanks for your input. – Time4Tea Oct 04 '20 at 01:02

2 Answers2

2

The inability to login, even after you've updated the passwords, would seem to indicate something fundamental is wrong.

I suggest going back to the live USB and chroot, and then trying su (both as root and non-root), and /bin/login (as root). They will hopefully give you error messages if you get the right password.

I would also examine the contents of /etc/nsswitch.conf and /etc/pam.d/.

I would also try removing the password (empty the second field in /etc/shadow) and see if you can get in that way. (Once the overall problem is fixed, you should assign a new password for that user.)

Additionally, there may be error messages in /var/log/auth.log (or some other file in that directory) that are worth reading.

David G.
  • 1,314
  • 1
  • 4
  • 15
  • Thanks for your answer. I went back into the chroot, as you suggested. `su` and `/bin/login` as root seem to do nothing. There are no error messages printed. If I do `su [username]` as root, it switches to that user, without prompting for a password. I can't find any file in `/var/log` that seems to be related to logon or authentication. I just tried changing the root password to something different and will see if it helps. The `/etc/shadow` file is being updated when I change password (via `passwd`). – Time4Tea Oct 03 '20 at 21:44
  • Hey, I figured it out. It was to do with pam. I'll post an answer to clarify what the problem was. – Time4Tea Oct 04 '20 at 00:53
  • 1
    Just to fill in the dots: `su [username]` as root should just switch to that user. As non-root, it should prompt for the password, and then switch. `/bin/login` as root should give you a normal login prompt and login sequence, except that it won't be cleaned up afterwards correctly. The noted pam corruption could well have affected `su` as non-root and `/bin/login`. – David G. Oct 04 '20 at 02:50
1

I think I figured out the problem. I checked /var/log/pacman.log for the details of the system update I had performed. There was a warning in there that the file /etc/pam.d/system-login had been saved as /etc/pam.d/system-login.pacnew. I think I had previously edited that file manually to fix another issue, so perhaps it recognized the file had been modified and so didn't overwrite it during the update. It's possible pam may have changed the way it handles logins, so it didn't work with the older file.

Anyway, logins are working again now. Perhaps my mistake was also running the system update from the chroot. I probably should have logged into the duplicate system after copying and run the update from there.

Time4Tea
  • 2,288
  • 5
  • 23
  • 54
  • You have probably come across [this issue](https://lists.archlinux.org/pipermail/arch-general/2020-August/048056.html). The `tally2` PAM module was removed upstream and several Arch users had `pam_tally2.so` in their `/etc/pam.d/system-login`, which eventually locked them out of their systems. Sorry, while reading your question I focused on "backup" and didn't realize you had updated the copied system independently of the original one. The useful piece of advice I've seen on the Arch mailing list is to run `pacdiff` after updating, to immediately take care of `.pacnew` files. – fra-san Oct 05 '20 at 08:32
  • @fra-san thanks for the info and for linking it to that issue. Also, I wasn't aware of `pacdiff`, thanks for pointing that out! – Time4Tea Oct 05 '20 at 12:59