"yum update" failure and resulting cleanup headaches.

[Callum Lerwick]

On Tue, 2007-01-23 at 23:27 +1100, David Timms wrote: 
> b. there is a different issue where there might be a problem with the 
> rpmdb. If this occurs, an rpm -q kernel would work, but an rpm -qa|grep 
> kernel hangs, forever. If this is the case, the other rpm based tools 
> (yum/pup/pirut) also hang if an attempt is made to run them. In this 
> case it is necessary to do the ~ rm /var/lib/__db.00* to fix rpm.
> 
> If you have both problems, you need to take care of b. first.
> 
> There has been some requests for yum to be more [bad eg mains reboot 
> during update!] fault tolerant. I forget whether these where on the yum, 
> yum-devel or comments on seths blog that has the dupes-cli.py

The having to rm /var/lib/__db.00* problem has been around since RH8.0,
and has yet to be completely fixed. This is not yum's fault, its rpm. Or
possibly, ultimately db4's fault. Or rpm using db4 incorrectly. Hell if
I know, all I know is I want it !@#$ing fixed. I'm hoping the new
community RPM upstream project can sort this out soon...

Especially now that we have yum-updatesd. On at least two occasions,
I've tried to use yum, only to have it lock up on me. I have to kill -9
the yum I attempted to run, then kill -9 yum-updatesd, and kill -9 the
rpmq cronjob that maintains /var/log/rpmpkgs thats hung in the
background, THEN I can rm /var/lib/__db.00* and use yum again. No idea
what broke the locking in the first place. Possibly the cron job and
yum-updatesd colliding?

WHY THE FUCK HAS THIS SHIT BEEN TOLERATED FOR SO LONG?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20070125/9e53a968/attachment.sig>