Bug 36964 - RPM Database Corruption on --rebuilddb
RPM Database Corruption on --rebuilddb
Status: CLOSED WORKSFORME
Product: Red Hat Linux
Classification: Retired
Component: rpm (Show other bugs)
7.0
i386 Linux
medium Severity high
: ---
: ---
Assigned To: Jeff Johnson
David Lawrence
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2001-04-21 05:01 EDT by misterb
Modified: 2007-04-18 12:32 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2001-05-04 13:33:54 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description misterb 2001-04-21 05:01:41 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.
Comment 1 Reuben Farrelly 2001-05-04 12:30:22 EDT
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
Comment 2 misterb 2001-05-04 12:36:11 EDT
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!
Comment 3 Jeff Johnson 2001-05-04 13:33:49 EDT
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.
Comment 4 Jeff Johnson 2001-05-21 09:29:04 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.