Dan McGee wrote:
On 4/10/07, Roman Kyrylych <roman.kyrylych@gmail.com> wrote:
Few hours ago I did an update on my server via ssh. First I updated pacman from 3.0.0 to 3.0.1, then did -Su. One of packages was filesystem-0.8-2. I don't have etc/fstab in NoUpgrade since 2.9.8. Then some idiot rebooted server before I checked .pacnew files etc. One of my coworker called my by cellphone (I also noticed PuTTY became inactive). When I get to my second job (where server is located) - I saw that /etc/fstab is rewritten with package's default, though pacman also created fstab.pacnew. Any ideas why did this happen?
I wonder if this is biting us: http://www.archlinux.org/pipermail/pacman-dev/2006-December/000838.html
Roman, before you update, it would be interesting to get the three different md5sums and see if this is the case. I'm just super surprised that this never happened to me in all of my pacman updates.
If this is it, then these should be the steps to reproduce (note that these reports are starting at step 5, the other stuff happened in the past): 1. Install a package that had a NoUpgrade line. 2. Edit a backup file. 3. Upgrade the package, causing the local md5sum to be written to the DB (instead of the original md5sum from the new package). 4. Do NOT edit the file again, and remove the NoUpgrade line from pacman.conf. 5. Upgrade the package, causing the 'original' and 'old' md5sum to be identical, which allows pacman to write an upgraded file over your custom config.
Possible fixes: 1. Put NoUpgrade lines back in. This is hacky/ugly IMO. 2. Back up all config files that are to be overwritten as .pacold files, even if they are supposedly legal candidates for overwriting. This will cause some clutter on systems, however, but will ensure no configurations are lost (although they would be moved).
Thoughts? Am I right on this? I wasn't deep enough in pacman yet when this issue came up.
-Dan
_______________________________________________ pacman-dev mailing list pacman-dev@archlinux.org http://archlinux.org/mailman/listinfo/pacman-dev
Confirmed, following Dan's instructions above I can replicate the problem. IMO option 2 plus a warning would be the best idea. Andrew