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?
Attachment:
signature.asc
Description: This is a digitally signed message part
-- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
