On Fri, 2006-08-25 at 08:47 -0400, Matthew Miller wrote: > 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: > > 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. > > 1. is there anything common about the 1/8th? 2. is it possible to recreate this situation but do the transaction with rpm as much as possible? This feels like it is a function of the openafs package being updated but I don't know what's going on here from this. -sv
