WARNING:DO NOT UPGRADE TO CORE 4

[Matthew Saltzman]

On Thu, 14 Jul 2005, Gene Heskett wrote:

> On Thursday 14 July 2005 10:09, Matthew Saltzman wrote:
>> On Thu, 14 Jul 2005, Ralf Corsepius wrote:
>>> On Thu, 2005-07-14 at 14:20 +0200, Emmanuel Seyman wrote:
>>>> On Thu, Jul 14, 2005 at 01:37:55PM +0200, Ralf Corsepius wrote:
>>>>> Unfortunately, recovering from such kind of breakage is
>>>>> non-trivial and often impossible ...
>>>>
>>>> Is it? The repairdb page on rpm.org has always worked for me.
>>>> http://www.rpm.org/hintskinks/repairdb/
>>>
>>> If you're lucky you can get away with it.
>>>
>>> If you're even more lucky, the fix is to remove all gpg-key*'s
>>> from the db, the run rpm --rebuilddb and to re-import the gpg-keys
>>> (There had been a time when rpm screwed up badly on gpg-keys, some
>>> user might have inherited this problem from this time.)
>>>
>>> If you're even yet more lucky, an "rpm --rebuilddb" helps.
>>>
>>> If you're less lucky, your rpmdb is hosed in unrecoverable ways.
>>
>> Even here, if you have the list of installed RPMs (see
>> /var/log/rpmpkgs) and the RPMs themselves (say, all together in a
>> directory), you should be able to reinitialize the db and then
>>
>>   rpm -ivh --justdb *.rpm
>>
>> to repopulate it.
>
> Yes, and how valid will that be after yum has updated nearly 200
> packages before it got a tummy ache over a keys checksum?

I didn't say it would be easy...

If you meet the prerequisites:

 	RPM db hosed, but files OK
 	List of RPMs available
 	RPMs (the versions that were installed) available
 	GPG keys available

then it should recreate the db to match the installed system.  If I missed 
that you couldn't satisfy these conditions for some reason, then just 
forget I said anything.

-- 
 		Matthew Saltzman

Clemson University Math Sciences
mjs AT clemson DOT edu
http://www.math.clemson.edu/~mjs