More RPM v3 database corruption fun..
Jeff Johnson
> So I've been occasionally getting malloc errors when I try to install
> some RPMS. Not all, just some, and, with the help of the list archive
> and some luck, have determined it's because of the packages.rpm entry
> for dialog (thanks to the reading nameindex.rpm and doing a rpm -qi on
> the resulting list). Further research have told me that something
> pretty bad has happened to the file, since nameindex.rpm lists ~570
> packages, while rpm -qa only lists 307.
>
> I've upgraded to RPM 4.0.2, but the databases are still db1 format.
> If I do a --rebuilddb, I get my 307 packages and in deep trouble since
> most of my dependencies aren't fulfilled.
>
> All indications are that I'm pretty much SOL at this point. I can't
> remove/reinstall dialog, and I can't rebuild the db. But I'm
> wondering if anyone has come up with a magic consistency restorer
> tool. It seems to me (And, obviously, I don't have a clue what I'm
> talking about) that although the chain thru packages.rpm is broken,
> all of the package offsets (save one) are still known. Is there any
> way to use this to rebuild the chain ?
>
The "magic consistency restorer" is to rebuild with rpm-3.0.x *before*
upgrading to rpm-4.0.2. The segfault's I've seen are due to corrupted
data before rpm-4.0.2 was installed. A --rebuilddb has worked for some.
If a --rebuilddb with rpm-3.0.x before upgrading doesn't "work", the next
step is to remove the header that is causing rpm-4.0.2 to segfault.
That can be done by
1) With rpm-4.0.2, run "rpm --rebuilddb -vv". Note the package
just before the segfault.
2) With rpm-3.0.5, run "rpm rebuilddb -vv" and erase the package
after the one identified above.
3) Reinstall rpm-4.0.2, run --rebuild to convert from db1 to db3.
I should point out the the what I am calling "db1" is not db-1.85, but
rather the first fit allocation scheme used to store package headers
which has had a problem forever, aka "free-list corrupt" in one of its
failure modes.
> I've heard other solutions mentioned, but having to recollect the 270
> packages that I'm missing seems a little daunting...
>
> Anyway, while I figure out how deep of a hole I'm in, I thought I'd
> ask if anyone has any better solutions.
>
The above is the best available solution at the moment. I've already fixed
the segfault in rpm-4.0.2, that was easy. I'm gonna try to improve the
error handling with db1 to try and be able to limit the scope of the damage
so that (in your case) you don't lose 270 packages, but dealing gracefully
with all cases of corrupted data is hard.
73 de Jeff
--
Jeff Johnson ARS N3NPQ
j...@jbj.org (j...@redhat.com)
Chapel Hill, NC
_______________________________________________
Rpm-list mailing list
Rpm-...@redhat.com
https://listman.redhat.com/mailman/listinfo/rpm-list
John Affleck
> The "magic consistency restorer" is to rebuild with rpm-3.0.x
> *before* upgrading to rpm-4.0.2. The segfault's I've seen are due
> to corrupted data before rpm-4.0.2 was installed. A --rebuilddb has
> worked for some.
Unfortunately, if I do this, I still end up with a fraction of my
original packages. I don't think this is the same 'segfault' problem
that has been discussed here before (although I can't say for certain
that I never installed the RPM packages in question). My database is
corrupt before I try and convert it.
> If a --rebuilddb with rpm-3.0.x before upgrading doesn't "work", the
> next step is to remove the header that is causing rpm-4.0.2 to
> segfault. That can be done by
[recipe snipped]
As I mentioned above, this unfortunately doesn't work for me.
> I should point out the the what I am calling "db1" is not db-1.85,
> but rather the first fit allocation scheme used to store package
> headers which has had a problem forever, aka "free-list corrupt" in
> one of its failure modes.
[more snippage]
> The above is the best available solution at the moment. I've
> already fixed the segfault in rpm-4.0.2, that was easy. I'm gonna
> try to improve the error handling with db1 to try and be able to
> limit the scope of the damage so that (in your case) you don't lose
> 270 packages, but dealing gracefully with all cases of corrupted
> data is hard.
Hmmm. Well, I guess it's back to package collecting for me then. I
guess I was wondering if there was a way to resurrect the package list
since I can still query all ~500 packages (minus 1). I'd assumed that
the 'direct' pointers were stored somewhere else and maybe the list
could be reconstructed from that.
While I'm here, does the --justdb do what it appears to do ? Can I
just do rpm -ivh --justdb <package> and put the database in the
correct state without modifying the filesystem ? I realize this is
exactly what it says it does, I just want to make sure.
Thanks for the help,
John A.