Description of problem:
It looks like the autofs package will sometimes temporarily get removed during
upgrades. When yum is finished, the package is back, but /etc/auto.master and
/etc/sysconfig/autofs will have been renamed to .rpmsave at that time, so autofs
does not restart or it restarts with a non-functional configuration.
Version-Release number of selected component (if applicable):
Not really reproducible, at least, we have some 150 computers here, and autofs
has had lots of updates in fc6, and I have only seen this behaviour a couple of
I am not sure if this is a bug in the autofs packaging, or a bug in rpm or yum,
but I have seen this happen only with autofs and not with other packages.
Thanks for the bug report. I have had at least one other report of this
happening, so we should try to get to the bottom of this. I'll try to reproduce it.
Here is a short thread where David and I discussed this bug. Includes a snipit
of my yum.log.
"autofs broken by yum update"
(In reply to comment #2)
> Here is a short thread where David and I discussed this bug. Includes a snipit
> of my yum.log.
> "autofs broken by yum update"
I really can't see any pattern here.
I can't understand why autofs gets removed rather than just
Below is a careful selection of lines from my /var/log/yum.log.
Sometimes when yum installs a new kernel another package is also
erased and updated. Effected autofs twice and dhclient once.
This could just be a coincidence or it might just be a pattern.
Feb 14 21:19:53 Erased: kernel
Feb 14 21:20:28 Installed: kernel.i686 2.6.19-1.2911.fc6
Mar 03 12:03:50 Erased: autofs
Mar 03 12:18:57 Installed: kernel.i686 2.6.19-1.2911.6.4.fc6
Mar 03 12:19:01 Updated: autofs.i386 1:5.0.1-0.rc3.23
Mar 11 12:09:38 Erased: dhclient
Mar 11 12:31:51 Installed: kernel.i686 2.6.19-1.2911.6.5.fc6
Mar 11 12:31:58 Updated: autofs.i386 1:5.0.1-0.rc3.25
Mar 11 12:31:59 Updated: dhclient.i386 12:3.0.5-3.fc6
Mar 11 14:07:16 Erased: kernel
Mar 11 14:08:08 Installed: kernel.i686 2.6.19-1.2911.6.5.fc6
Apr 18 21:53:38 Installed: kernel.i686 2.6.20-1.2944.fc6
May 05 17:28:04 Erased: autofs
May 05 17:28:43 Installed: kernel.i686 2.6.20-1.2948.fc6
May 05 17:28:44 Updated: autofs.i386 1:5.0.1-0.rc3.29
If this is on fc6 it's a good chance it is one of the implicit obsoletes that
used to happen in rpm. And since obsoletes are always what rpm tells yum I'm
going to pass the buck over to rpm.
Well, I don't see where the implicit obsolete would come from, nothing in the
repo besides autofs itself provides autofs afaict.
I wonder if this is more or less the same thing as here:
1) what yum plugins do you folks have enabled?
2) is there always a kernel present in the transactions where this happens?
Unfortunately (for the sake of this bugreport), most of our computers that ever
had this bug, have been upgraded to fedora 7 now, so I don't have the details of
the yum logs any more. However, in the two cases where I still have a log, there
was a kernel present in the transaction.
Enabled plugins in yum:
Right, that pretty much confirms my suspicions, fedorakmod is likely to be the
problem here. IIRC it "emulates" upgrade behavior for kmod packages which can't
be normally upgraded (upgrade would remove the updated kmod for all older
kernels) and this happens by marking the old version for erase and new for
install. Which is exactly what's happening here, except for wrong packages.
Autofs has a dependency on kernel (well, a conflict), if fedorakmod triggers the
kmod-upgrade behavior because of that, it'd pretty much explain what's happening
Over to yum-utils...
This sounds really familiar -- thanks for the CC, Seth.
We have this problem at BU with our openafs kernel packages. We're not, however,
using any intelligent dependency system for the upgraded kernel modules -- we
just build a new openafs RPM for every new kernel release, and include upgraded
binary modules for all recent kernels in the new package.
On some systems, everything works fine. On others, the package is apparently
removed and then installed again. Particularly, on these systems, the
postinstall script is run with $1 set to 0. Since we had "shut down afs" as part
of that script in the case (but not if it's > 0, of course),on these systems,
AFS gets turned off mid-transaction. Since we're running our repository out of
AFS,this then causes yum to crash because it can't find files it thought it had.
My theory is that this happens *all the time* and that we're just noticing it
here because of the fatal condition that happens to occur.
We've seen this on FC3, RHEL4, and FC4 derivatives, with yum 2.4.x (where x =
all released values) and 2.6.1 on FC4.
I've been promising Seth a test case system for this for a while now. I'll see
if I can make it happen tomorrow. In the meantime, our workaround was to disable
the shutdown of AFS in the post script, which means I haven't actually been
alerted to the problem for a while. But I bet it's still happening.
Fedora apologizes that these issues have not been resolved yet. We're
sorry it's taken so long for your bug to be properly triaged and acted
on. We appreciate the time you took to report this issue and want to
make sure no important bugs slip through the cracks.
If you're currently running a version of Fedora Core between 1 and 6,
please note that Fedora no longer maintains these releases. We strongly
encourage you to upgrade to a current Fedora release. In order to
refocus our efforts as a project we are flagging all of the open bugs
for releases which are no longer maintained and closing them.
If this bug is still open against Fedora Core 1 through 6, thirty days
from now, it will be closed 'WONTFIX'. If you can reporduce this bug in
the latest Fedora version, please change to the respective version. If
you are unable to do this, please add a comment to this bug requesting
Thanks for your help, and we apologize again that we haven't handled
these issues to this point.
The process we are following is outlined here:
We will be following the process here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this
doesn't happen again.
And if you'd like to join the bug triage team to help make things
better, check out http://fedoraproject.org/wiki/BugZappers
This bug is open for a Fedora version that is no longer maintained and
will not be fixed by Fedora. Therefore we are closing this bug.
If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen thus bug against that version.
Thank you for reporting this bug and we are sorry it could not be fixed.