On 4/10/07, 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?

-- 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 :

On 4/10/07, 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?

-- 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 (Роман Кирилич)

Roman Kyrylych wrote:

2007/4/10, Roman Kyrylych :

...

...

On 4/10/07, 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?

-- 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 : 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

Roman Kyrylych wrote:

2007/4/10, Andrew Fyfe :

...

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 :

Roman Kyrylych wrote:

...

2007/4/10, Andrew Fyfe :

...

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 (Роман Кирилич)

On 4/10/07, Andrew Fyfe  wrote:
> Roman Kyrylych wrote:
> > 2007/4/10, Andrew Fyfe :
> >> Roman Kyrylych wrote:
> >>> 2007/4/10, Andrew Fyfe :
> >>>> 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

Dan McGee wrote:

On 4/10/07, 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?

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 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 wrote:

...

On 4/10/07, Andrew Fyfe 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