Created attachment 36342 [details]
rpmdb tar bal

Created attachment 36343 [details]
Error text from tar file creation and db_verify

Do a --rebuilddb with rpm-4.0.3-1.03 from (amongst other places)
    ftp://ftp.rpm.org/pub/rpm/test-4.0.3

Use rpm2cpio to install if you have to. Assuming all 6 rpm
packages are in /var/tmp, the procedure (as root) is
    mkdir /var/tmp/xxx
    cd /var/tmp/xxx
    for i in /var/tmp/{rpm,popt}-*
    do
        rpm2cpio $i | cpio -dim
    done
    find . -type d -exec chmod 755 {} \;
    tar cf - . | (cd /; tar xvf -)

Then an rpm --rebuilddb should fix your problem.

Please cc mcannon on any ticket correspondence.  I'm having
trouble with my mailserver on cannon-consultants.com (thanks!).

Follow instructions provided.
1. Installed 6 rpm-4.0.3-1.03 packages (including popt) using rpm2cpio
2. Executed rpm --rebuilddb and received the following error message:

   error: rpmdb: damaged header instance #36 retrieved, skipping
   Segmentation fauld (core dumped)

Two additional files were created in /var/lib/rpm:

   __db.001
   __db.002

One additional directory with 11 files created (looks like a working directory):

   /var/lib/rpmrebuilddb.4636

Executing rpm -qa yields the following error:

   error: cannot open Packages index using db1 - No such file or directory (2)

Let me know if you want the core file or a tarball containing the rebuilddb files.

Regards,

Matt Cannon

OK, give me a pointer (i.e. URL, attachments won't work as rpmdb files
are too big) to a tarball of your database
	cd /var/lib
	tar czvf /tmp/rpmdb-55671.tar.gz rpm
and I'll see what I can do.

I have included a URL to a tar file containing my rpm database.  It appears that
the only differences between the new tar file and the one originally attached to
this ticket are the presence of the core file and the __db.00[1-2] files in the
new tar file (both of which were created after running the rebuilddb option
after 4.0.3 was installed).

  The URL is http://cannon-consultants.com/rpmdb-55671.tar.gz

I sincerely appreciate your assistance.

Regards,

Matt Cannon
mcannon

Hmmm, your database is pretty smashed, dunno if I can save much.

You can see what I'm looking at if you do (you need the db3-utils package)
	db_verify /var/lib/rpm/Packages

The segfault is on header instance #56. If I carefully avoid that, I see
nothing but bad headers. I can try a few more things, but it's looking
bad. I'll help you get through the reconstruction however ...

Any idea how you got to this state? Any hints/clues are appreciated, so
that I can try to prevent this from happening in the future.

I believe I tried the early steps (db_verify and then db_dump Packages.old |
db_load Packages) from ticket 38454 before I created this ticket, but stopped
short before executing the t38454 C program.  The problem I was originally
experiencing (gripes about an assertion being violated in header.c after
installing 4.0.2-7x rpm) was quite similar to the one described in 38454.  After
looking at the source of the t38454 program, it looked like it had hard coded
records that it was trying to delete and that's when I stopped and created this
ticket (reference initial comment on 55671). Where I think I might have really
goofed (not sure if I did this or why if I did) is when I executed a rpm
--rebuilddb after the db_verify, db_dump and db_load.  This is when I started to
notice the Segmentation faults and created 55671.  I didn't leave myself a very
good crumb trail (keeping an original Packages - pre dump/re-load) and I should
have been more patient.
After reading the paragraph I just wrote I realized this information might have
been helpful in the original comment.  My guess is this whole situation is 5%
problem with rpm, 95% problem with end-user's solution methodology.  At any
rate, thanks for any assistance and if there's something tedious I can do to
help myself out here, let me know.  I don't know if it helps, but my installed
package list is on the RedHat Network.

Regards,

Matt Cannon
mcannon

OK, there are 3 basic ways to recreate an rpm database.

1) Easiest is to reinstall. If you want to be clever, you can do
an install without making new file systems on your existing
partitions, thereby preserving all your existing files.

2) Tar up a copy of /var/lib/rpm from the most similar machine,
and then use rpm -Va to detect packages in the database
that don't match the files on disk (those packages can then
be reinstalled). This procedure converges fairly fast, does
have the draw back of losing certain information like
install times that is added to package headers when they are
installed.

3) Using the rpmdb-redhat (or equivalent) as a reference, go
to all the usual places (i.e. /bin, /sbin, /usr/bin, etc ...) and
repeatedly run
	rpm -qf --redhatprovides some_file_here
to discover the package that has the file, and then reinstalling
that package. If you want to preserve exactly what is on
your disk, you can install just the database entries with
	--justdb --noscripts --notriggers --nodeps
options to the usual install.

What's your pleasure?

Created attachment 38644 [details]
Installed Package List for 55671

Hmmm...

I think I'll go for what's behind door #3.  I have an up-to-date package list 
from my system profile on RedHat Network (see attached list).  For the packages 
that aren't on the original distribution for 7.0, I assume I can use a remote 
location parameter for the updated or new version of the rpm files.  

A couple of questions:  How can I start with a clean slate with regard to the 
rpm database(s)?  Will installing the packages with the -- justdb --noscripts, -
-notriggers --nodeps establish the necessary db entries for future dependency 
checks for package installs/removes as well as file location information for 
package removal?

Thanks,

Matt Cannon
mcannon

Sorry for the delay ...

Doing
	mv /var/lib/rpm /var/lib/rpm-SAVE
	mkdir -p /var/lib/rpm
	rpm --initdb
is a "clean slate".

Yes, --justdb adds the metadata to the database, but does
not unpack payloads onto the file system.

This problem looks to be on the way to solution. If I'm wrong,
reopen the bug.