Hide Forgot
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): current: autofs-5.0.1-0.rc3.29.i386 How reproducible: 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 times. 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" https://www.redhat.com/archives/fedora-list/2007-May/msg00637.html Thanks, Mike
(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" > https://www.redhat.com/archives/fedora-list/2007-May/msg00637.html I really can't see any pattern here. I can't understand why autofs gets removed rather than just updated. Ian
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. Thanks, Mike 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: https://lists.dulug.duke.edu/pipermail/yum/2006-August/009063.html 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: fedorakmod installonlyn
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 here. 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.
Matthew, anything?
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. http://fedoraproject.org/wiki/LifeCycle/EOL 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 the change. 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: http://fedoraproject.org/wiki/BugZappers/F9CleanUp 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.