Red Hat Bugzilla – Bug 36964
RPM Database Corruption on --rebuilddb
Last modified: 2007-04-18 12:32:46 EDT
From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 5.0)
I ran rpm --rebuilddb as ordered to by the upgrade intructions.
As it ran, it ran out of space on the /var/lib drive, and started to
produce db3 error messages. I fixed the space issue, and the rebuild
continued. The problem is that it appears to have completed writing a
corrupt rpm database out. I can no longer scan it, and I get core crashes
when I attempt to rebuild the rebuilt database.
I would have expected the rpm app to crash out when the database errors
occured. Certainly I would not have expected to get a corrupt database at
Reproducible: Didn't try
Steps to Reproduce:
I can't reproduce it. The database is corrupt!
I need to get this back ideally.... Is there a way of getting a copy of
what is stored by the RHN stuff to rebuild my original rpm database???
If not, how can I refresh the database to a useable state and then reapply
the RPMS that I have installed to get the database to a consistent state?
I would class this as a high sev as it has resulted in data corruption.
Reproduced here too. I had 20MB free on /var before the --rebuilddb, and
somehow RPM ran out of space during a rebuild and wrote a chronically corrupted
database back to what space was left on the partition.
As you can imagine, I had to reinstall almost every single RPM to re-register
all the RPMS and rebuild the RPM database to a usable state. Even though the
files were actually there on disk...
Using rpm version 4.0.3-0.8
That's what I had to do too.... Fortunately I was using Redhat network, and
Managed to get a list of my current RPM's from there, otherwise I would have
I have got some scripts that I used to repopulate the RPM db if anyone is
I notice some one has downgraded this from high sev...... So I guess someone
has looked at it!
Yes I read these bugs all the time. Please attach your scripts, they may be
There are several other bug reports regarding database corruption, and what to
Basically, there are two classes of problems:
1) your db1 format dtabase had a problem before upgrading.
The fix is to do "rpm --rebuilddb" with rpm-3.0.x,
upgrade to rpm-4.0.2, and then do "rpm --rebuilddb"
to convert from db1 to db3 format.
2) you've been using ximian, gnorpm, and other tools linked with
rpm-4.0 on a system upgraded to rpm-4.0.2. You have two choices
a) Deinstall everything installed by rpm-4.0.2, downgrade
to rpm-4.0, and continue using the tools.
b) upgrade any/all executables that link with rpmlib to a version
linked with the rpm-4.0.2 rpmlib.
BTW, you're insane if you're running the development version of rpm-4.0.3-0.8, I
give you nothing but sympathy, and very little of that if you're concerned about
severity of database corruption. Stick with the production version rpm-4.0.2
If you don't have a "fix" yet, reopen this bug with a pointer to a tarball
of your database
tar czvf /tmp/rpmdb.tar.gz
and I'll take a look.
Graceful behavior under ENOSPC conditions, the original bug, is gonna take
more work. Make sure you have enough free space before upgrading.