Tony Nelson wrote:
At 7:53 PM -0500 11/19/06, Jim Cornette wrote:
: Database verification failed
Well, your RPM database is pretty well hosed. The --rebuilddb option fails
because it uses Packages, which is damaged. This RHEL3 page
<http://people.redhat.com/berrange/notes/rpmrecovery.html> has suggestions
for what to try, such as dumping the Packages file and re-importing it
(some lossage will occur).
I was able to reboot, remove the __db* files in /var/lib/rpm and
follow-up with a successful rpm --rebuilddb which seemed to recover the
database correctly.
The problem seems to be that once an error is encountered in the
database, you cannot run any instance of yum or any rpm instance with
options until you remove the /var/lib/rpm/__db.* files and reboot the
system. I believe the rebooting of the system either clears memory where
there is problems or at least clears the system from temporary files
which are causing the lock.
Using --initdb will remove any chance of --rebuilddb working, so don't
until you are moving on to other methods. Per Matthew Saltzman on 20 Oct
2005 17:01:42 "Re: RPM Database broken", /var/log/rpmpkgs* lists the RPMs
on your system (yesterday); you can download all of them (eww -- possibly
just the headers?) and use "rpm -U --justdb <filename>" on them (frm a
script). Finish up by hand.
Fortunately, this was not needed. I was able to reinstall the rpms that
were cached in yum directories to ensure the rpms were all loaded
correctly. There were only a couple rpms related to fuse and the ntfs-3g
rpms in the transaction.
Yum may have its own separate opinion of what's installed?
When you finish, run "package-cleanup --problems" from yum-utils, and "rpm
-Va".
I'll try the option in the utilities. Presently I use a script that
Steve Grubb passed on in postings back and forth on the test list, which
I believe does the same thing. Though clean-up after detection is still
up to the user.
Jim
--
Support staff hung over, send aspirin and come back LATER.
