[pacman-dev] /etc/fstab rewritten by pacman!
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? -- Roman Kyrylych (Роман Кирилич)
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?
-- Roman Kyrylych (Роман Кирилич)
Uh oh. Heard of this yesterday too: http://bbs.archlinux.org/viewtopic.php?id=31776 What the hell is regressing? -Dan
2007/4/10, Dan McGee <dpmcgee@gmail.com>:
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?
-- Roman Kyrylych (Роман Кирилич)
Uh oh. Heard of this yesterday too: http://bbs.archlinux.org/viewtopic.php?id=31776
What the hell is regressing?
Dunno. Some time ago I did successful upgrade of filesystem package with pacman 2.9.8 without any NoUpgrade line. -- Roman Kyrylych (Роман Кирилич)
2007/4/10, Roman Kyrylych <roman.kyrylych@gmail.com>:
2007/4/10, Dan McGee <dpmcgee@gmail.com>:
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?
-- Roman Kyrylych (Роман Кирилич)
Uh oh. Heard of this yesterday too: http://bbs.archlinux.org/viewtopic.php?id=31776
What the hell is regressing?
Dunno. Some time ago I did successful upgrade of filesystem package with pacman 2.9.8 without any NoUpgrade line.
Maybe something is still wrong or was broken after "proactive backup"? -- Roman Kyrylych (Роман Кирилич)
Roman Kyrylych wrote:
2007/4/10, Roman Kyrylych <roman.kyrylych@gmail.com>:
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?
-- Roman Kyrylych (Роман Кирилич) Uh oh. Heard of this yesterday too: http://bbs.archlinux.org/viewtopic.php?id=31776
What the hell is regressing? Dunno. Some time ago I did successful upgrade of filesystem package with
2007/4/10, Dan McGee <dpmcgee@gmail.com>: pacman 2.9.8 without any NoUpgrade line.
Maybe something is still wrong or was broken after "proactive backup"?
Roman other than repos/servers, what's in your pacman.conf? I've looked at the filesystem packages and it's got all the backup lines, so it's not a problem with the package itself. Andrew
2007/4/10, Andrew Fyfe <andrew@neptune-one.net>:
Roman other than repos/servers, what's in your pacman.conf?
I've looked at the filesystem packages and it's got all the backup lines, so it's not a problem with the package itself.
I know, that's why I wonder, especially that old bug (when file was replaced during first update after NoUpgrade removed) shouldn't work now. I don't have access to my server now, but can assure you that there's nothing unusual in pacman.conf. As I said all NoUpgrade was removed since pacman 2.9.8 out so even that old bug shouldn't cause this. Besides .pacnew was created which is right, but WTH file was replaced - that's the point. I will do upgrade at home tomorrow (sure, backing up /etc previously) and will do it with --debug=3 now. -- Roman Kyrylych (Роман Кирилич)
Roman Kyrylych wrote:
2007/4/10, Andrew Fyfe <andrew@neptune-one.net>:
Roman other than repos/servers, what's in your pacman.conf?
I've looked at the filesystem packages and it's got all the backup lines, so it's not a problem with the package itself.
I know, that's why I wonder, especially that old bug (when file was replaced during first update after NoUpgrade removed) shouldn't work now. I don't have access to my server now, but can assure you that there's nothing unusual in pacman.conf. As I said all NoUpgrade was removed since pacman 2.9.8 out so even that old bug shouldn't cause this. Besides .pacnew was created which is right, but WTH file was replaced - that's the point. I will do upgrade at home tomorrow (sure, backing up /etc previously) and will do it with --debug=3 now.
I did the upgrade last night and didn't have any problems, BUT I'm running with an updated copy of libalpm. I did notice that only group.pacnew was created. /etc/issue wasn't updated and there wasn't an issue.pacnew. (etc/issue was the file updated for the new release).
2007/4/10, Andrew Fyfe <andrew@neptune-one.net>:
Roman Kyrylych wrote:
2007/4/10, Andrew Fyfe <andrew@neptune-one.net>:
Roman other than repos/servers, what's in your pacman.conf?
I've looked at the filesystem packages and it's got all the backup lines, so it's not a problem with the package itself.
I know, that's why I wonder, especially that old bug (when file was replaced during first update after NoUpgrade removed) shouldn't work now. I don't have access to my server now, but can assure you that there's nothing unusual in pacman.conf. As I said all NoUpgrade was removed since pacman 2.9.8 out so even that old bug shouldn't cause this. Besides .pacnew was created which is right, but WTH file was replaced - that's the point. I will do upgrade at home tomorrow (sure, backing up /etc previously) and will do it with --debug=3 now.
I did the upgrade last night and didn't have any problems, BUT I'm running with an updated copy of libalpm. I did notice that only group.pacnew was created. /etc/issue wasn't updated and there wasn't an issue.pacnew. (etc/issue was the file updated for the new release).
Hm, could you please then diff your version with 3.0.1 in part of backing up files? -- Roman Kyrylych (Роман Кирилич)
Roman Kyrylych wrote:
> 2007/4/10, Andrew Fyfe <andrew@neptune-one.net>:
>> Roman Kyrylych wrote:
>>> 2007/4/10, Andrew Fyfe <andrew@neptune-one.net>:
>>>> Roman other than repos/servers, what's in your pacman.conf?
>>>>
>>>> I've looked at the filesystem packages and it's got all the backup
>>>> lines, so it's not a problem with the package itself.
>>> I know, that's why I wonder, especially that old bug (when file was
>>> replaced during first update after NoUpgrade removed) shouldn't work
>>> now.
>>> I don't have access to my server now, but can assure you that there's
>>> nothing unusual in pacman.conf. As I said all NoUpgrade was removed
>>> since pacman 2.9.8 out so even that old bug shouldn't cause this.
>>> Besides .pacnew was created which is right, but WTH file was replaced
>>> - that's the point.
>>> I will do upgrade at home tomorrow (sure, backing up /etc previously)
>>> and will do it with --debug=3 now.
>>>
>> I did the upgrade last night and didn't have any problems, BUT I'm
>> running with an updated copy of libalpm. I did notice that only
>> group.pacnew was created. /etc/issue wasn't updated and there wasn't an
>> issue.pacnew. (etc/issue was the file updated for the new release).
>
> Hm, could you please then diff your version with 3.0.1 in part of
> backing up files?
>
Looking at the version I'm using the only change in libalpm has been the
fix for {pre,post_remove. But it might have something to do with this
change
http://cvs.archlinux.org/cgi-bin/viewcvs.cgi/lib/libalpm/alpm.c.diff?r1=1.127&r2=1.128&cvsroot=Pacman&only_with_tag=R_3_0_1
I need to go and do some testing but now that I think about it glibc got
upgraded during an -Syu, that's not supposed to happen is it? HoldPkgs
shouldn't upgrade during -Syu should they?
Andrew
On 4/10/07, Andrew Fyfe <andrew@neptune-one.net> wrote:
> Roman Kyrylych wrote:
> > 2007/4/10, Andrew Fyfe <andrew@neptune-one.net>:
> >> Roman Kyrylych wrote:
> >>> 2007/4/10, Andrew Fyfe <andrew@neptune-one.net>:
> >>>> Roman other than repos/servers, what's in your pacman.conf?
> >>>>
> >>>> I've looked at the filesystem packages and it's got all the backup
> >>>> lines, so it's not a problem with the package itself.
> >>> I know, that's why I wonder, especially that old bug (when file was
> >>> replaced during first update after NoUpgrade removed) shouldn't work
> >>> now.
> >>> I don't have access to my server now, but can assure you that there's
> >>> nothing unusual in pacman.conf. As I said all NoUpgrade was removed
> >>> since pacman 2.9.8 out so even that old bug shouldn't cause this.
> >>> Besides .pacnew was created which is right, but WTH file was replaced
> >>> - that's the point.
> >>> I will do upgrade at home tomorrow (sure, backing up /etc previously)
> >>> and will do it with --debug=3 now.
> >>>
> >> I did the upgrade last night and didn't have any problems, BUT I'm
> >> running with an updated copy of libalpm. I did notice that only
> >> group.pacnew was created. /etc/issue wasn't updated and there wasn't an
> >> issue.pacnew. (etc/issue was the file updated for the new release).
> >
> > Hm, could you please then diff your version with 3.0.1 in part of
> > backing up files?
> >
> Looking at the version I'm using the only change in libalpm has been the
> fix for {pre,post_remove. But it might have something to do with this
> change
> http://cvs.archlinux.org/cgi-bin/viewcvs.cgi/lib/libalpm/alpm.c.diff?r1=1.127&r2=1.128&cvsroot=Pacman&only_with_tag=R_3_0_1
What do you think this would have changed? I know this was a fix for
the Turkish locale issue where I and i are not the same letter.
NoUpgrade lines should not be required anymore as far as I know and can tell.
> I need to go and do some testing but now that I think about it glibc got
> upgraded during an -Syu, that's not supposed to happen is it? HoldPkgs
> shouldn't upgrade during -Syu should they?
>
> Andrew
HoldPkg = package ...
If a user tries to --remove a package that's listed in HoldPkg,
pacman will ask for confirmation before proceeding.
This is a different concept than IgnorePkg:
IgnorePkg = package ...
Instructs pacman to ignore any upgrades for this package when
performing a --sysupgrade.
-Dan
Am Dienstag, 10. April 2007 16:50:00 schrieb Roman Kyrylych:
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?
Well, it`s not the first time that this happens. In most cases this is the fault of the package and not pacman itself. But anyway: pacman should never overwrite anything within /etc. We should replace the backup=... tag in the PKGBUILD with an option like overwrite=... which explicitly lists every file that has to be overwritten. In every other case pacman has to ask the user if a file in /etc should be overwritten. Of cause we have to check if there is a difference between the current and new file. As a workaround I have setup a cron job which backs up my /etc directory every day.
Roman Kyrylych 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?
On a side note should filesystem be added to HoldPkg in pacman.conf? I'm not sure I we really want to upgrade filesystem after it's initial install. Andrew
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
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
On 4/10/07, Andrew Fyfe <andrew@neptune-one.net> wrote:
Dan McGee wrote:
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).
Confirmed, following Dan's instructions above I can replicate the problem.
Wow, I'm half surprised I got that right. :) Good to hear since I hate bugs that are not reproducible.
IMO option 2 plus a warning would be the best idea.
Andrew
On 4/10/07, Andrew Fyfe <andrew@neptune-one.net> wrote:
Dan McGee wrote:
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). Confirmed, following Dan's instructions above I can replicate the problem.
Wow, I'm half surprised I got that right. :) Good to hear since I hate bugs that are not reproducible.
IMO option 2 plus a warning would be the best idea.
Andrew
_______________________________________________ pacman-dev mailing list pacman-dev@archlinux.org http://archlinux.org/mailman/listinfo/pacman-dev This is kicking off because NoUpgrade doesn't store an MD5 of the original file in var/lib/pacman/local/*. If NoUpgrade is removed before
Dan McGee wrote: the package is upgraded with the appropriate backup=(..) line, pacman overwrites the NoUpgrade files. A solution I think... Short-term: 1. Put NoUpgrade back into pacman.conf ...let a little time pass... 2. Update all packages containing NoUpgrade files to include the proper backup=() line. 3. Tell everyone to go run -Syu ...let a little time pass... 4. Remove NoUpgrade lines from pacman.conf Long-term: NoUpgrade needs to work the same way as backup=(..). Andrew
On 4/10/07, Andrew Fyfe <andrew@neptune-one.net> wrote:
On 4/10/07, Andrew Fyfe <andrew@neptune-one.net> wrote:
Dan McGee wrote:
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). Confirmed, following Dan's instructions above I can replicate the problem.
Wow, I'm half surprised I got that right. :) Good to hear since I hate bugs that are not reproducible.
IMO option 2 plus a warning would be the best idea.
Andrew
_______________________________________________ pacman-dev mailing list pacman-dev@archlinux.org http://archlinux.org/mailman/listinfo/pacman-dev This is kicking off because NoUpgrade doesn't store an MD5 of the original file in var/lib/pacman/local/*. If NoUpgrade is removed before
Dan McGee wrote: the package is upgraded with the appropriate backup=(..) line, pacman overwrites the NoUpgrade files.
A solution I think...
Short-term: 1. Put NoUpgrade back into pacman.conf ...let a little time pass... 2. Update all packages containing NoUpgrade files to include the proper backup=() line. 3. Tell everyone to go run -Syu ...let a little time pass... 4. Remove NoUpgrade lines from pacman.conf
Long-term: NoUpgrade needs to work the same way as backup=(..).
Sorry for the long wait guys. See new thread I'm going to open up soon with the fix to this problem. -Dan
2007/4/11, Dan McGee <dpmcgee@gmail.com>:
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.
I'll do few tests in virtual machine this week. Maybe it could be solved in some nice way. -- Roman Kyrylych (Роман Кирилич)
participants (4)
-
Andrew Fyfe
-
Dan McGee
-
Pierre Schmitz
-
Roman Kyrylych