Red Hat Bugzilla – Bug 464780
Avahi update fails due to multiple avahi installs
Last modified: 2008-10-03 05:10:06 EDT
Description of problem:
On a number of different machines yum is failing because I appear to have multiple copies of avahi installed.
Version-Release number of selected component (if applicable):
5 out of 6 of our servers show the same symptoms.
Steps to Reproduce:
1. Take recently updated f9 system
2. Run yum update
Transaction Check Error:
file /etc/avahi/avahi-autoipd.action from install of avahi-autoipd-0.6.22-10.fc9.x86_64 conflicts with file from package avahi-0.6.17-1.fc7.x86_64
file /usr/sbin/avahi-autoipd from install of avahi-autoipd-0.6.22-10.fc9.x86_64 conflicts with file from package avahi-0.6.17-1.fc7.x86_64
file /usr/share/man/man8/avahi-autoipd.8.gz from install of avahi-autoipd-0.6.22-10.fc9.x86_64 conflicts with file from package avahi-0.6.17-1.fc7.x86_64
This may be an anaconda bug as it seems that somehow I've ended up with two copies of avahi installed on my systems:
$ rpm -q avahi
This then causes the update to fail. From a quick google it seems I'm not the only one either:
The work-round in that reference worked for me but I thought this should go into bugzilla in case anyone else has hit this.
I have the same problem.
Wouldn't a release bump of avahi clear the situation up? That is, suppose that avahi-0.6.22-11.fc9 were to be released. Unless I'm mistaken, then when we upgraded to that EVR, *both* of the previous version-releases that are installed would be removed and replaced with *only* the new version-release. (I.e., there would only be one installed version afterwards.)
I'm just trying to think of a solution that would be transparent to all users who haven't run into this yet.
I also suppose that going forward, someone might have to look at anaconda as well.
Lennart, next time when you re-assign something please explain why. So let me ask the 1 million dollar question then, why do you believe this is an anaconda bug, what exactly did anacando do wrong, and what should it have done instead?
I think it was me who first mentioned anaconda as a possible suspect but without saying why - sorry about that.
In our set of servers, the common factor among those who exhibited this bug was that they had been upgraded from a previous release of fedora. The machines which had F9 installed directly didn't do this.
Also, looking for avahi entries in /var/log/yum.log* I see this:
$ sudo grep avahi /var/log/yum.log* | grep -v glib
/var/log/yum.log:Sep 30 14:57:10 Installed: avahi-autoipd-0.6.22-10.fc9.i386
/var/log/yum.log.1:Dec 12 06:52:06 Updated: avahi.i386 0.6.15-1.fc6
/var/log/yum.log.1:Apr 28 06:30:42 Updated: avahi.i386 0.6.16-4.fc6
/var/log/yum.log.2:May 22 06:40:28 Updated: avahi.i386 0.6.9-9.FC5
/var/log/yum.log.2:Jun 13 04:54:54 Updated: avahi.i386 0.6.10-1.FC5
/var/log/yum.log.2:Nov 29 04:41:45 Updated: avahi.i386 0.6.11-2.fc5
/var/log/yum.log-20080114:Dec 29 06:37:38 Updated: avahi - 0.6.21-8.fc8.i386
/var/log/yum.log-20080114:Dec 29 06:37:39 Updated: avahi-compat-libdns_sd - 0.6.21-8.fc8.i386
/var/log/yum.log.3:Apr 12 09:33:53 Updated: avahi.i386 0.6.9-8.FC5
Neither of the offending duplicated packages are shown which I think means that they were installed via anaconda (all our updates are through yum so I'm pretty sure that nothing was done directly through rpm).
I don't know if this is a packaging problem or an update problem but I suspect anaconda is involved somewhere along the line. It may well be that this has been lying dormant since FC7 and is only now manifesting itself.
I have the same problem, and I tried to resolve it by saying
yum remove avahi-0.6.16-4.fc6.i386
and yum claimed to have removed it, but really didn't. So there's a yum problem to be resolved, I think.
I'm seeing this same issue. My system was upgraded from Fedora 8 with "preupgrade", and similarly from Fedora 7.
Doing "rpm -q avahi" I see
so there's an old avahi around. Great, I said, I'll try
rpm -e avahi-0.6.17-1.fc7.i386
but I then get
error: %postun(avahi-0.6.17-1.fc7.i386) scriptlet failed, exit status 1
So I read the man page and then tried
rpm -e --nopostun avahi-0.6.17-1.fc7.i386
That cleaned up the mess, and yum update then succeeded in installing avahi-autoipd and upgrading NetworkManager.
Brian @ #4, it looks like using yum instead of rpm directly hides the error. If so, that could be considered a yum bug.
(In reply to comment #5)
> I'm seeing this same issue. My system was upgraded from Fedora 8 with
> "preupgrade", and similarly from Fedora 7.
> Doing "rpm -q avahi" I see
> so there's an old avahi around. Great, I said, I'll try
> rpm -e avahi-0.6.17-1.fc7.i386
> but I then get
> error: %postun(avahi-0.6.17-1.fc7.i386) scriptlet failed, exit status 1
> So I read the man page and then tried
> rpm -e --nopostun avahi-0.6.17-1.fc7.i386
> That cleaned up the mess, and yum update then succeeded in installing
> avahi-autoipd and upgrading NetworkManager.
Thanks for this info! This explains the problem and also makes it an ahavi package problem post scripts should be written in such a way that they never fail!
Unfortunately we cannot retraactively fix the fc7 package, so I'm closing this as cantfix :(
I will file a bug against yum to add an option to ignore rpmpost script errors and erase the package anyways.
yum bug 465409
I'm still not quite clear about this.
If the scriptlet failed then how did the upgrade to the new version succeed leaving two versions installed? Should the whole transaction not have failed and been rewound? Is this something to do with the more brute force approach taken by anaconda when doing updates (where I believe it ignores errors which would otherwise cause a transaction to abort).
I'm just wondering if there's any way to stop this from happening again at a yum / rpm / anaconda level?
An rpm update roughly works like this (non relevant steps left out):
1) install new version
2) run %post install script of new version
3) enter new version into rpmdb
4) uninstall old version (not removng any files replaced by 1)
5) run %postun script of old version
6) remove old version from rpmdb
As 5 fails 6 is never done, this is really a packaging bug and the problem is its a packaging bug of the old package which thus cannot be fixed after a package is released. There are plans to change rpm to make bugs like these have less consequences, see bug 465409
I hope this helps.