How do you fix a corrupt rpm database?
mi...@crucis.net
fails as does --initdb. When using up2date, I get a number of error that specify
a number of errors by line.
Is there some tool that can fix this?
Mike W
_______________________________________________
Rpm-list mailing list
Rpm-...@redhat.com
https://listman.redhat.com/mailman/listinfo/rpm-list
Jeff Johnson
> I have a problem using up2date. The rpm database is corrupted. rpm --rebuilddb
> fails as does --initdb. When using up2date, I get a number of error that specify
> a number of errors by line.
>
> Is there some tool that can fix this?
No single tool, but here's what I do:
0) Make a copy of everything, just in case:
cd /var/lib
tar czvf /tmp/rpmdb.tar.gz rpm
1) Check /var/lib/rpm/Packages with db_verify.
The command is
db_verify /var/lib/rpm/Packages
If that fails, the fix is
cd /var/lib/rpm
mv Packages Packages-ORIG
db_dump Packages-ORIG | db_load Packages
At this point Packages should be OK.
2) Read all Package headers.
The command is
rpm -qa
If that "works", go to step 5), do "rpm --rebuilddb" and you're done.
If that segfaults, go to 3).
if that hangs, then do
rm -f /var/lib/rpm/__db*
and try again.
3) You have a segfault on a header.
The first step is to get the segfaulting header instance.
Append "debug" to the Packages configuration by
echo "%_dbi_config_Packages %{_dbi_htconfig} lockdbfd debug" \
>> /etc/rpm/macros
Try "rpm -qa", lots of boring glop until segfault.
On the screen will be something like
...
Get Packages key (0x8216580,4) data (0x4014f008,155244) "#612" 47000000 rc 0kernel-enterprise-2.4.9-26beta.17
Get Packages key ((nil),0) data ((nil),0) "" deadbeef rc -30990
<segfault here>
The 2nd to last "Get Packages" line is what you want, the
bad header instance above is "612" in decimal. Note the
package name-version-release, you'll want to reinstall
that package somewhen.
4) Nuke the bad header.
I usually whip out my handy-dandy header instance deleter,
edit the bad record into the source, compile, run, and go back
to step 2).
The program is at
ftp://people.redhat.com/jbj/t38454.c
FWIW, the program is named after the bugzilla report that
caused me to write it.
Retrieve, and edit the bad header instances into
...
int badrecs[] = {
--> EDIT --> 562, 566, 559, 561, 563, 560, 564,
-1
};
...
Compile with
cc -o t38454 t38454.c -ldb-3.2
Run as
t38454
Go back to step 2).
5) Clean up.
a) rpm --rebuilddb
b) rm -f /etc/rpm/macros
c) rm -rf /var/lib/rpmrebuild*
d) Reinstall the deleted package.
Otherwise, give me a bug report at
http://bugzilla.redhat.com
with a pointer (i.e. URL, bugzilla attachments won't work) to the
tarball you created in step 0), and I'll see what I can figger.
73 de Jeff
--
Jeff Johnson ARS N3NPQ
j...@redhat.com (j...@jbj.org)
Chapel Hill, NC
John A.Chick
> On Thu, Feb 28, 2002 at 04:34:05PM -0600, mi...@crucis.net wrote:
>> I have a problem using up2date. The rpm database is corrupted. rpm
>> --rebuilddb
>> fails as does --initdb. When using up2date, I get a number of error that
>> specify a number of errors by line.
>>
>> Is there some tool that can fix this?
>
> No single tool, but here's what I do:
>
> etc. etc. etc.
Hi Jeff (and RPM guru's),
I've been lurking around the linux.redhat.rpm news group for several days
now, sifting through all the stuff I can find on RPM seg faults, etc. I've
also checked out the 38454 and 62610 articles as well. Lots of
good info.
I have a corrupted database, but even after following your instructions to
the letter, I'm still getting seg faults.
I'm pretty sure it's associated with an entry in the Packages database for
kdegames, but I can't seem to get the index number for it, so the t38454
tool hasn't been much help in this case.
I'm just about ready to rebuild the box. It's not a production machine, so
it's no big deal, but it would be nice to know how to resolve this, just in
case it DID happen on a PM.
I dropped a tarball at http://www.monmouth-me.net/rpmdb.tar.gz containing
all the database files, in case you're interested in taking a look at it.
Thanks,
John A. Chick
jch...@maine.com