Artix Linux Forum

I think what you are looking for is here is

Code: [Select]

mv passwd.bak passwd

I know full well that if I copied it over /etc/passwd it would break my system.

The reason you still have easy root access is the actual passwords are in shadow

Well done for keeping a backup. If you hadn't the system probably made one for you the last time it altered the passwd file with a system tool. It's passwd-

Do not blindly replace config files with the *.pacnew files
The whole reason the pacnew file is created is because you (or a program) made changes to the config file.
When you replace the modified config files with the .pacnew file you lose all the changes which is almost never what you want.

You've less chance of breaking your system by just ignoring them than by blindly copying them.

If you are concerned use a diff program to view the diferances and make an informed decision.

Again well done for keeping a backup

This. Also, pacman won't overwrite files that have changed, will create file.pacnew instead if it has an update.

Okay. I believe you. The reason I did this is because, it is written in the Arch Wiki as you know. While studying package management some time ago:

https://wiki.archlinux.org/title/Pacman/Pacnew_and_Pacsave

Section 1 last paragraph:

"These files require manual intervention from the user and it is good practice to handle them right after every package  upgrade or removal. If left unhandled, improper configurations can result in improper function of the software or the software being unable to run altogether".


I know that the paragraph states that improper configuration "can" result to in improper function. It does not mean
that it is certain. So I thought it is best to rename "pacnew" as the default file or merge (which I still have to learn), before I might break my system if it is ignored. Also because it states "it is good practice to handle them right after every upgrade".

Clearly I was wrong by assuming that this rule applies to all ".pacnew" (or .pacsave) files, right?


Example, I did this a couple of times with mirrorlist.pacnew in the past. And never had any issues.

While "it is good practice to handle them right after every upgrade" might be technically correct it makes it sound way more necessary than I've found myself in years of using Pacman based systems.
I consider that particular wiki article poorly written as ideally, especially for newer users, it should clearly and simply define what is meant by "handle". As more damage can often be caused by an incorrect 'handling' than by just doing nothing.

Each case is different. Get yourself a diff program such as kdiff3 (qt) or meld.
When you open the original and the pacnew you'll see the differences.
Often they are trivial. Often the only difference is the change you actually wanted.
By replacing the current file with the pacnew you lose the change to the default configuration made either manually or by a program as I was saying before.
The idea is to look at the pacnew and then judge if any of the differences are needed (rare imho) or beneficial in some way.

Then either adapt your config file to have the newer bits of the pacnew or adapt the pacnew to contain your changes made to what would have been the default of the previous version. (I hope that makes some sense?)

You give the example /etc/mirrorlist.
Mirrors get added, mirrors get removed.  But it you have taken the time to select a particular mirror by un-commenting it and commenting the other mirrors that change get lost when replaced with the pacnew file. However that's not going to be system breaking.

Now look at /etc/passwd
A default version just contains the root user.
It's called 'passwd' as historically it did contain passwords but that was a long time ago.
What it really is now is a list of users, their UID's, home dir (if any) and shell.
As well as your user, which was added to the file when installing the system, many services add the users they run as when installed.
All of that is lost when the pacnew replaces your current version. Your system is now only partially functional and needs fixing. If you didn't have a backup you're a lot screwed unless you really know what you are doing.

If you didn't have a backup you're a lot screwed unless you really know what you are doing.

Rarely in my experience does a pacnew file require immediate intervention but it does happen.
The first instance that springs to mind is a program called opensmtp.
A few years back they completely changed the format, and much syntax, of smtpd.conf.
Without intervention an email server using the current file would not start.
But the answer would not have been to just move the pacnew to smtpd.conf
That would have resulted in an email server that did start but did next to nothing. I had to go and learn about the new format and then adapt my old server settings to use it.

Edit: I wouldn't worry too much about the file permission warnings either unless something isn't working
What they show in your examples is the permissions are more restricted that when the package was first installed. It's most likely the programs using those folders that did the restricting. Search and read about 'Octal file permissions'.

Even when you have not edited a file manually, do not blindly overwrite a live file with its .pacnew version. Always compare and merge the changes manually.

I see. I will try do be more cautious, when I am reading the Arch Wiki. Even thought it is sometimes difficult to tell the difference between what is accurate and what is poorly written, but I will try.

Okay, glad to know that now. But why is it still called passwd, if it doesn't store them anymore?
In that case, shouldn't passwords be stored in shadows anyway?