[pacman-dev] /etc/fstab rewritten by pacman!
Forwarding to pacman-dev. ---------- Forwarded message ---------- From: CHANTRY Xavier <xav@chantry.homelinux.org> Date: Apr 10, 2007 6:37 PM Subject: [pacman-dev] /etc/fstab rewritten by pacman! To: dpmcgee@gmail.com
I wonder if this is biting us: http://www.archlinux.org/pipermail/pacman-dev/2006-December/000838.html
Most certainly.
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.
I was also very surprised, but you explained it clearly below :)
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.
That's indeed when either 3 or 4 are missing that we avoid the bug. Once the config files have been edited, the package need to be upgraded at least once for the wrong checksums to be stored. So if NoUpgrade lines are removed before the damage is done, the bug doesn't happen.
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).
Like I said the on the forums : http://bbs.archlinux.org/viewtopic.php?pid=242384#p242384 the original plan was apparently to not remove NoUpgrade in the first place, and wait long enough so that it's safe to remove them. It could take a while though, before the last user updates the packages with NoUpgrade files using pacman 3, so that all checksums are corrected. Maybe the few packages containing NoUpgrade files should be forced to be reinstalled, after pacman 3 is installed. I'm not sure that's 100% bullet proof though. Maybe checking all checksums in the db would be safer. I've my part of responsibility in this problem, because I'm the one who started complaining about NoUpgrade, because it actually caused clutters, and it made it harder to keep all config files up to date. So 2. would cause even more clutters, which is quite contradictory, but well, if it's the only way.. I'm glad of pacman behavior once the transition is made, I already noticed the transition caused problems back then. But unfortunately, no one found a correct solution to it yet.
Thoughts? Am I right on this? I wasn't deep enough in pacman yet when this issue came up.
You look perfectly right to me (not that it means anything), but what disturbs be me highly is the behavior Roman describes. He claims he already did an upgrade of filesystem without NoUpgrade lines, so that should have put the correct checksums in the database. How could the bug be reproduced after that?
2007/4/11, Dan McGee <dpmcgee@gmail.com>:
I wonder if this is biting us: http://www.archlinux.org/pipermail/pacman-dev/2006-December/000838.html
Most certainly.
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.
Ok.
I was also very surprised, but you explained it clearly below :)
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.
That's indeed when either 3 or 4 are missing that we avoid the bug. Once the config files have been edited, the package need to be upgraded at least once for the wrong checksums to be stored. So if NoUpgrade lines are removed before the damage is done, the bug doesn't happen.
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).
Like I said the on the forums : http://bbs.archlinux.org/viewtopic.php?pid=242384#p242384 the original plan was apparently to not remove NoUpgrade in the first place, and wait long enough so that it's safe to remove them. It could take a while though, before the last user updates the packages with NoUpgrade files using pacman 3, so that all checksums are corrected.
Maybe the few packages containing NoUpgrade files should be forced to be reinstalled, after pacman 3 is installed. I'm not sure that's 100% bullet proof though. Maybe checking all checksums in the db would be safer.
I've my part of responsibility in this problem, because I'm the one who started complaining about NoUpgrade, because it actually caused clutters, and it made it harder to keep all config files up to date. So 2. would cause even more clutters, which is quite contradictory, but well, if it's the only way.. I'm glad of pacman behavior once the transition is made, I already noticed the transition caused problems back then. But unfortunately, no one found a correct solution to it yet.
Thoughts? Am I right on this? I wasn't deep enough in pacman yet when this issue came up.
You look perfectly right to me (not that it means anything), but what disturbs be me highly is the behavior Roman describes. He claims he already did an upgrade of filesystem without NoUpgrade lines, so that should have put the correct checksums in the database. How could the bug be reproduced after that?
Here are more details I've got when recovered my server: 1) parts of pacman.conf: . . . [12/19/06 17:59] starting full system upgrade [12/19/06 17:59] warning: extracting /etc/fstab as /etc/fstab.pacnew [12/19/06 17:59] warning: extracting /etc/group as /etc/group.pacnew [12/19/06 17:59] warning: extracting /etc/hosts as /etc/hosts.pacnew [12/19/06 17:59] warning: extracting /etc/passwd as /etc/passwd.pacnew [12/19/06 17:59] warning: extracting /etc/shadow as /etc/shadow.pacnew [12/19/06 17:59] warning: extracting /etc/ld.so.conf as /etc/ld.so.conf.pacnew [12/19/06 17:59] warning: extracting /etc/resolv.conf as /etc/resolv.conf.pacnew [12/19/06 17:59] upgraded filesystem (0.7.2-5 -> 0.8-1) . . . [2007-04-10 14:03] upgraded fbreader (0.8.1-1 -> 0.8.1c-2) [2007-04-10 14:03] warning: /etc/ld.so.conf installed as /etc/ld.so.conf.pacnew [2007-04-10 14:03] upgraded filesystem (0.8-1 -> 0.8-2) . . . First update was made by older pacman version, but I'm not sure if it was pacman2 or one of pacman3 RCs. 2) timestamps of files: /etc/fstab - Apr 10, 14:03 (ctime and mtime) /etc/fstab.pacnew - Dec 19 17:59 (ctime) & Dec 17, 15:54 (mtime) As you may see fstab.pacnew was created during 0.7.2-5 -> 0.8-1 move 3) hosts, resolv.conf, passwd and group were also rewritten :-( -- Roman Kyrylych (Роман Кирилич)
Hmm, now I did upgrade to my home system and guess what? pacman didn't create _any_ .pacnew when upgrading filesystem package, but no files were overwritten either. :-/ (oh, it just silently replaced /etc/issue but I didn't touch it so it's OK). So it doesn't create .pacnew when local file was changed but mainstream file was not changed since last version, or what? -- Roman Kyrylych (Роман Кирилич)
On 4/15/07, Roman Kyrylych <roman.kyrylych@gmail.com> wrote:
Hmm, now I did upgrade to my home system and guess what? pacman didn't create _any_ .pacnew when upgrading filesystem package, but no files were overwritten either. :-/ (oh, it just silently replaced /etc/issue but I didn't touch it so it's OK). So it doesn't create .pacnew when local file was changed but mainstream file was not changed since last version, or what?
RTFM. :P original=X, current=Y, new=X Both package versions contain the exact same file, but the one on the filesystem has been modified. Leave the current file in place. -Dan
2007/4/15, Dan McGee <dpmcgee@gmail.com>:
On 4/15/07, Roman Kyrylych <roman.kyrylych@gmail.com> wrote:
Hmm, now I did upgrade to my home system and guess what? pacman didn't create _any_ .pacnew when upgrading filesystem package, but no files were overwritten either. :-/ (oh, it just silently replaced /etc/issue but I didn't touch it so it's OK). So it doesn't create .pacnew when local file was changed but mainstream file was not changed since last version, or what?
RTFM. :P
original=X, current=Y, new=X Both package versions contain the exact same file, but the one on the filesystem has been modified. Leave the current file in place.
Yeah, I've already realised that. :-) -- Roman Kyrylych (Роман Кирилич)
Just to be complete here: This error is in fact caused by the old issue referenced by Dan. pacman2 writes incorrect md5sums into the DB when the file is listed in NoUpgrade. This is not an issue for those of us that have been running pacman3 for a while, as it would have rewritten the correct md5sums there on an upgrade. This was an oversight on my part, and I apologize to anyone this affected negatively. There are a few solutions to the issue, but I'd like to not introduce code changes to fix this. So I'll propose the following: 1) We know the packages this effects - it's a very small subset, unless someone added additional NoUpgrade entries. 2) A small shell script which sets the backup md5sums to all zeros for a given package could be written, with directions for users at the edge cases. 3) Run the script for all packages we know on post-install/post-upgrade from pacman. Any problems with this?
participants (3)
-
Aaron Griffin
-
Dan McGee
-
Roman Kyrylych