[pacman-dev] /etc/fstab rewritten by pacman!

[Andrew Fyfe]

Dan McGee wrote:
> On 4/10/07, Roman Kyrylych <roman.kyrylych at 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 at 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