Background:
We're running yum 2.4.2 on our CentOS-based BU Linux system. Yesterday, we
put out an update for our openafs packages to match the new kernel -- the
*only* change to the openafs package being that I added in the kernel module
for 2.6.9-42.0.2.EL and removed that for 2.6.9-34.0.1.EL. However, because
of the kernel-module-standard-situation, we just do this in a braindead way
and there's *no* dependencies for the kernel module in the RPM -- it just
happens to work if you have the latest kernel and the latest openafs
package, which you should. The important point is that from rpm and yum's
point of view, the only difference in these packages is that the release
went from 1.4.1-1bu45s.4s to 1.4.1-1bu45s.5s.
So:
On about 7/8ths of our systems, this update -- which included just the
updated kernel and openafs packages -- went without a hitch. However, on the
other eighth, we got behavior like this:
[...begin update report...]
Thu Aug 24 15:11:44 EDT 2006
Unmounting /afs and stopping AFS services: [ OK ]
Unloading AFS module: [ OK ]
=============================================================================
Package Arch Version Repository Size
=============================================================================
Installing:
kernel i686 2.6.9-42.0.2.EL bulinux-updates 11 M
kernel-devel i686 2.6.9-42.0.2.EL bulinux-updates 3.7 M
Updating:
kernel-hugemem-devel i686 2.6.9-42.0.2.EL bulinux-updates 3.7 M
kernel-smp-devel i686 2.6.9-42.0.2.EL bulinux-updates 3.7 M
openafs i386 1.4.1-1bu45s.5s bulinux-updates 2.4 M
openafs-client i386 1.4.1-1bu45s.5s bulinux-updates 1.5 M
Removing:
kernel i686 2.6.9-34.0.2.EL installed 26 M
kernel-devel i686 2.6.9-34.0.2.EL installed 11 M
Transaction Summary
=============================================================================
Install 2 Package(s)
Update 4 Package(s)
Remove 2 Package(s)
Total download size: 26 M
------------------------------------------------------------------------
The yum update generated the following errors. If there was
a serious problem, you may find some diagnostic information here.
Traceback (most recent call last):
File "/usr/bin/yum", line 29, in ?
yummain.main(sys.argv[1:])
File "/usr/share/yum-cli/yummain.py", line 175, in main
base.doTransaction()
File "/usr/share/yum-cli/cli.py", line 712, in doTransaction
self.runTransaction(cb=cb)
File "__init__.py", line 352, in runTransaction
File "/usr/share/yum-cli/callback.py", line 105, in callback
fd = os.open(rpmloc, os.O_RDONLY)
OSError: [Errno 2] No such file or directory:
'/afs/bu.edu/software/linux-dist/bulinux/yum/4.5s/updates/i386/RPMS/openafs-client-1.4.1-1bu45s.5s.i386.rpm'
[...end update report...]
Hhhuh? Why'd it stop AFS? The traceback is logical, since it's *getting* the
updates out of AFS and it's suddenly vanished, so yum is justifiably
startled. But what's rpm gone and stopped AFS for?
The openafs-client package has this scriptlet:
preuninstall scriptlet (using /bin/sh):
if [ "$1" = "0" ]; then
/sbin/service afs stop
/sbin/chkconfig --del afs
fi
but that should fire only on the last removal, not on an upgrade. And yum's
output clearly says it's doing an upgrade. But wait!
$ rpm -q openafs openafs-client
openafs-1.4.1-1bu45s.5s
package openafs-client is not installed
And the yum log says:
Aug 24 15:07:39 Updated: openafs.x86_64 1.4.1-1bu45s.5s
Aug 24 15:07:47 Installed: kernel-smp.x86_64 2.6.9-42.0.2.EL
Aug 24 15:07:48 Erased: openafs-client
and then that's it, because it blew up after that.
Now, these machines aren't totally screwed, since we have the repo
configured to fall back to FTP in the event AFS isn't available. But I'd
really, really like to figure out what went wrong. Any ideas totally
appreciated!
--
Matthew Miller mattdm@xxxxxxxxxx <http://mattdm.org/>
Boston University Linux ------> <http://linux.bu.edu/>
