1

After all these years of using Linux, I have never goofed up this badly. I should have known better, I honestly don't know what I was thinking.

While trying to fix a small error message I was getting (this is irrelevant to my now much bigger issue), I found a post that said to "just run pacdiff and overwrite old files", and without much looking into it, I began to overwrite..

I guess I did have the fortitude to back up /etc/shadow before overwriting it and stopped overwriting after just a few entries, but I am now locked out of root and all my users. I'm on the computer right now as I'm scared to restart as I also overwrote /etc/grub.d (which I did not backup)! The /etc/shadow backup is in my /home and is owned by root so I cannot read it now, but I do have it.

What exactly does pacdiff and (O)verwrite with pacnew do? I have found instructions to recover /etc/shadow file, but will I be able to get into grub-boot loader on restart now?

My root and home partition are not encrypted, but I do have a LUKS encrypted partition. If worse comes to worse, and I have to reinstall without formatting my /home and encrypted partition, is any instance of cryptsetup able to open a LUKS encrypted partition with the passphrase? The information to mount and open is stored in the LUKS partition header, so I should be good, right? I am unable to find out which cipher I am using as I don't have root access, but I'm almost positive it's whatever the default is.

How do I proceed from here? I'm not going to shutdown this machine until I have a plan in place. I'm on a dual boot Manjaro/Windows. I do have a bootable Manjaro USB made and another machine if need be. Any help would be much appreciated. This is not my proudest moment, but a great lesson learned. I need you guys more than ever.

0
2

I have never used Manjaro, but the process that works for Arch Linux should be fine in your case too.

You should be able boot off a Manjaro live USB, mount the root file system of your Manjaro installation, mount your existing /home directory and put the backup copy you have of shadow back to its place.

Then you should also be able to boot your installed Manjaro, because /etc/grub.d is only used to (re-)create your GRUB configuration and is not required during the boot process. It is however important that you restore (editing them again, if you have no backup) the files it contains, otherwise your system risks becoming unbootable (or, more likely, not dual-bootable anymore) the next time some package update triggers the re-creation of your boot loader configuration.

This also likely worked if you had an encrypted root file system. udev takes care of activating any block devices (e.g. MD RAID arrays or LVM volumes) as soon as they become available, and the only things usually left to you are:

  • Opening encrypted devices; in your case, you should be able to:

    cryptsetup open /dev/your_encrypted_device decrypted_device_name
    

    Unless something wiped your LUKS headers this will only require the passphrase. (Note that there is no way to recover your data if the LUKS headers have been wiped or damaged and you don't have a backup).

  • Mounting file systems. E.g. mount /dev/sdaN / or mount /dev/mapper/mapped_dev /.

lsblk may help you explore your device tree and locate the right devices to open/mount (look at the TYPE column).


When pacman installs a new version of a file whose modification time does not match the one recorded in the packages database, the existing file is not overwritten and a .pacnew file is created instead.

Promptly taking care of .pacnew files is important because, on a rolling-release distribution, any package update may introduce breaking changes. For instance, an existing configuration file may mention options that have been deprecated in the to-be-installed version of a program, which needs different options instead. Distribution maintainers can not take care of all the possible cases and checking configuration files is left to the user.

pacdiff is aimed at helping in this process: it walks through the pacnew (and .pacsave) files tracked by the package manager and offers you to review them. "(O)verwrite with pacnew" does just what is says: the existing file is replaced with the .pacnew version and your custom configuration is lost.

While the most proper action is usually to review the existing and .pacnew versions of a file and merge them when needed, some .pacnew files are not meant to be acted upon. Assuming Manjaro aligns with Arch in this respect, this is true for the user database (which includes /etc/passwd and /etc/shadow) "unless Pacman outputs related messages for action".

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.