[7251] in testers

home help back first fref pref prev next nref lref last post

Re: rpmdb corruption

daemon@ATHENA.MIT.EDU (Jonathon Weiss)
Tue Jul 12 20:49:01 2005

Message-Id: <200507130048.j6D0mnfg014928@the-other-woman.mit.edu>
From: Jonathon Weiss <jweiss@MIT.EDU>
To: Jonathon Weiss <jweiss@MIT.EDU>
cc: testers@MIT.EDU
In-reply-to: Your message of "Sat, 09 Jul 2005 07:58:32 EDT."
             <200507091158.j69BwWGt003734@bearing-an-hourglass.mit.edu> 
Date: Tue, 12 Jul 2005 20:48:49 -0400

> 
> I tried to take 9.4.10 on vorpal-blade, and the update failed because
> of a fissing findutils package.  Note that I've never un-installed
> this package, and all of the files that are in it exist on vorp.  
> 
> /etc/athena/rpmupdate -n -p /dev/null /var/athena/release-rpms
> 
> confirmed that findutils was the only missing package, but removing
> the -n caused it to spew errors of the form:
> 
> error: rpmdbNextIterator: skipping h#    2770 Header V3 DSA signature: BAD, key ID db42a60e
> 
> running 'rpm --rebuilddb' allowed rpmupdate to re-add the findutils
> rpm, and allowed me to proceed to the next error:
> 
> vorpal-blade.mit.edu# update_ws
> Beginning update from 9.4.9 to 9.4.10 at Sat Jul  9 07:25:56 EDT 2005.
> Version: $Id: update,v 1.20 2005/07/08 17:12:56 ghudson Exp $
> warning: rhel-4-updates/RPMS/cpp-3.4.3-22.1.i386.rpm: V3 DSA signature: NOKEY, key ID db42a60e
> error: rhel-4-updates/RPMS/glibc-common-2.3.4-2.9.i386.rpm: V3 DSA signature: BAD, key ID db42a60e
> rpmupdate: Invalid package file rhel-4-updates/RPMS/glibc-common-2.3.4-2.9.i386.rpm
> *** The update has failed ***
> Please contact Athena Cluster Services at x3-1410.  -Athena Operations
> Update complete; please reboot for changes to take effect.
> 
> Whcih after some fumbling I fixed by stoping afs, mkfs-ing the cache
> partition and rebooting.
> 
> Unfortunately, my machine then hung during the update (it hung last
> weekend too, and I currentyl suspect a hardware problem, but that's a
> guess.  I guess I will be sad now.
> 
> 	Jonathon
> 
> 

OK, at this point I'm fairly convinced that I have a hardware problem
that's causing data read from the disk to be corrupted by the time the
CPU is done with it.  All of the above should be disregarded.

	Jonathon


home help back first fref pref prev next nref lref last post