RPM Database Corruption

chris at idlelion.net chris at idlelion.net
Fri Feb 23 15:31:25 UTC 2007


> Date: Thu, 22 Feb 2007 18:39:22 -0500
> From: Sam Varshavchik <mrsam at courier-mta.com>

> chris at idlelion.net writes:
>> Lesson learned: *NEVER* kill a yum update, no matter how long it takes.
>
> Come and join the party we're having in another thread.

Seen it. It prompted me to write.

>> With that out of the way, how SHOULD I have proceeded after trashing an
>> FC5 or FC6 system that had the database so corrupt that yum and rpm
>> couldn't run?
>
> Although the rpm database is known to get wonky from times, winding it up in
> an unusable state is very rare.  It only really happens when corruption and
> various cruft has accumulated, slowly, over some time, and your final
> "event" pushed things over the edge, over the point of no return.

This had been a pretty stable system, fresh install of FC5 a while back, 
with updates along the way and "yum upgrade"-ing to FC6. I got impatient 
and ran kill -9 on it. Oh boy.

> Manually rm-ing all the __db* files in /var/lib/rpm, and then running "rpm
> --rebuilddb" usually manages to repair or minimize the damage, maybe about
> 99% of the time.  It's the remaining 1% of the time that puts you into a
> real pickle.

I tried that. Many times. Let it rest a few days, looked around for more 
ideas, tried again, formatted the drive.

I'm thinking that without some kind of existing database or repository of 
installed RPM's that there's just no way to know what you've got 
installed, short of getting all the headers of every version of every 
(recent) package and checking if those files exist in the expected places. 
No wonder there's no tool for that.

Live and learn.




More information about the users mailing list