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 the end. 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 been stuffed! I have got some scripts that I used to repopulate the RPM db if anyone is interested.... 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 useful. There are several other bug reports regarding database corruption, and what to do. 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 can give you nothing but sympathy, and very little of that if you're concerned about the severity of database corruption. Stick with the production version rpm-4.0.2 please.
If you don't have a "fix" yet, reopen this bug with a pointer to a tarball of your database cd /var/lib 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.