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?


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).

  • 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
    Commented Oct 3, 2020 at 3: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
    Commented Oct 3, 2020 at 3: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
    Commented Oct 3, 2020 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
    Commented Oct 3, 2020 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
    Commented Oct 3, 2020 at 14:01

2 Answers 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.

  • 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
    Commented Oct 3, 2020 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
    Commented Oct 4, 2020 at 0: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.
    Commented Oct 4, 2020 at 2:50

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.

  • You have probably come across this issue. 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
    Commented Oct 5, 2020 at 8: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
    Commented Oct 5, 2020 at 12:59

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .