[Date Prev][Date Next] [Thread Prev][Thread Next]
more questions on RPM database, specifically corruption
- From: Dale Carstensen <dlc lampinc com>
- To: rpm-list redhat com
- Cc: red-carpet ximian com
- Subject: more questions on RPM database, specifically corruption
- Date: Wed, 28 Feb 2001 11:51:36 -0700
Last week I tried red carpet from ximian. Now rpm mostly doesn't work.
So I need details about the rpm database, or better yet a tool that
can rebuild my corrupted rpm database.
Note: I sent this to both email@example.com and firstname.lastname@example.org
I see a lot of these from rpm:
Program received signal SIGSEGV, Segmentation fault.
0x805dcef in providePackageNVR (h=0x82a45a0) at misc.c:787
(xxgdb) info stack
#0 0x805dcef in providePackageNVR (h=0x82a45a0) at misc.c:787
#1 0x8072712 in doGetRecord (pkgs=0x81ae2d8, offset=12686936) at db1.c:145
I'm learning more than I want to know about rpm. Unfortunately, the
docs don't say much about the database, except to try --rebuilddb when
there are problems. But --rebuilddb itself gets a seg fault, so that's
of no use.
I have RedHat 6.2 on an i686, plus lots of dangerous updates from ximian
cvs for evolution and redcarpet and rpms from ximian and elsewhere to
satisfy prerequisites for those, rpm-4.0.2-0.34, glibc-2.2.1-3, db1-1.85-5,
db2-2.4.14-5, db3-3.1.17-5, etc. Some of these came from rawhide.redhat.com.
I expect some difficulties using too new stuff from ximian and rawhide,
but having a corrupted rpm database kind of puts a crimp in changing
anything at all. I frequently think how lucky Linux users are not to
have a silly catchall database like Windows users have in the "registry,"
but I guess now I've found that Red Hat users really do have a very similar
I can only imagine what problems I would have if I had installed
XFree86-4 and/or kernel-2.4, without or with rpm involved. I do have
a laptop with RedHat 7.0 and XFree86-4 has been a nightmare with
power management on that. That's a digression, though.
The evolution cvs stuff is in /usr/local, and I hope that isolates it
from rpm's world. But, maybe that's too much to ask. Anyway, it seems
to be redcarpet, not evolution or its prerequisites, that broke the
I saw the message about using --rebuilddb immediately after upgrading
from rpm-3 to rpm-4. I don't recall doing that, but I used rpm-4 for
dozens of other queries and upgrades before redcarpet got it to mess
up the database. I tried downgrading to rpm-3 using --oldpackage,
then back to rpm-4 (wouldn't do it, got a seg fault,) then forced the
rpm-4 files in using rpm2cpio and --rebuilddb still got a seg fault.
While I had rpm-3, I did find that "rpm -qa" put two lines of
null-null-null (I don't know the exact string, though) after gnome-core
and quit with no seg fault.
Oh, I can't build redcarpet from source with rpm-4, either. The
redcarpet source wants a function named rpmErrorCode, and that's gone
in rpm-4. And rpm-4 doesn't seem to have an equivalent, either.
The reason I looked at the redcarpet source is because it started
giving me this, I'm thinking due to the rpm seg faults:
libredcarpet-ERROR **: file rc-rpmman.c: line 934 (rc_rpmman_dep\
ends_fill): assertion failed: (package->spec.name)
The red-carpet I built from source, working around the rpmErrorCode
problem, doesn't even allow me to explore that specific problem, though.
Back to rpm.
My rpmrc tells rpm to use db1. Updating glibc from 2.1 to 2.2 got rid
of the dbm utilities, and my old copies of them don't work with db1
files anyway. I can use db1_dump185 to look at 7 of the 8 files in
/var/lib/rpm, also 7 of 8 in /usr/lib/rpmdb/i386-redhat-linux/redhat.
The "file" command correlates with that, calling the 8th file, packages.rpm,
"data" and giving "Berkeley DB 1.85" details about the others. However,
requiredby.rpm does have a bogus key count in its "file" output of -162
for the /var/lib/rpm one (58 in the other directory.) But db1_dump185
seems to be happy with requiredby.rpm, and thinks it has 584 keys.
A "rpm -qa" gets to gnome-core OK, then seg faults. I used db1_dump185 to
look at nameindex.rpm, and the next name after gnome-core is gtk-engines.
A "rpm -q gnome-core" works but a "rpm -q gtk-engines" seg faults. The
next name after gtk-engines in nameindex is sawmill-gnome, and "rpm -q
So I'm thinking if I had some simple db1 copy program like the dbm
db_recover program used to be, maybe I could build a new database
without gtk-engines and be back in business.
But I don't have a clue how these files in /var/lib/rpm interrelate,
and I haven't found any handy comments in the rpm source or documents,
including Maximum RPM. I'm trying to dig the details out of the C
in the source, but I figure it's worthwhile to spend some time
posting this message, too.
I tried dumpdb from ./tools in the rpm source, which seems to extract
blocks from packages.rpm, but I have no clue where to get the block
number, and I seem to either get the "setup" package or a seg fault
for most numbers I try. A "1" does get the "filesystem" package.
A "0" seg faults, and I guess everything beginning "0x" seg faults.
But why would I think atoi recognizes 0x as a prefix for a hexadecimal
base. I think if I ever find where those block numbers show up, they'll
be hexadecimal when I see them, though.
I gather that packages.rpm is not a db1 file, but I wonder what it
is. It maybe is some kind of hash file. Who knows?
So, can anybody pass along some info on the internal details of the
rpm database, or better yet, a recovery tool that works better than
Mr Dale Carstensen
LAMP, Inc. office (505)662-2524
1504 S Sage FAX (505)662-3588
Los Alamos, NM 87544-3037 email@example.com
[Date Prev][Date Next] [Thread Prev][Thread Next]