RPM Community Forums

Mailing List Message of <rpm-users>

Re: I killed my RPMDB --- any rescue possible?

From: Jeff Johnson <n3npq@mac.com>
Date: Sun 12 Jun 2011 - 23:53:58 CEST
Message-id: <9ED6AD2D-774B-41C1-8A93-D18960AFCC3C@mac.com>

On Jun 12, 2011, at 4:35 PM, Eric MSP Veith wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Hello list,
> 
> I killed my RPMDB, propably by misusage. This is how I did it: I upgraded 
> from RPM-5.1.9 to 5.3.10. I ran dbconvert.sh (which told me that the 
> conversion failed), but repeated usage of db_recover -ev and rpm --rebuilddb 
> finally got things in order. I'm using a chroot, which went the same path.
> 

Well  mebbe.

> However, after using "rpm -r /my/chroot -Uvh ...", the RPMDB *outside* the 
> chroot is corrupted. When running "rpm -qa", this is what I get:
> 

So which rpmdb needs fixing? The rpm inside or outside the chroot?

And what versions of rpm are in use inside and outside the chroot?


> - ---%<---
> Freeing read locks for locker 0xa: 23945/3062028096
> Freeing read locks for locker 0xb: 23945/3062028096
> Freeing mutex for process: 23945/0
> Freeing mutex for process: 23945/0
> Freeing mutex for process: 23945/0
> Freeing mutex for process: 23945/0
> Freeing mutex for process: 23945/0
> Freeing mutex for process: 23945/0
> Freeing mutex for process: 23945/0
> Freeing mutex for process: 23945/0
> Freeing mutex for process: 23945/0
> libXfixes-4.0.3-1ev.i686
> error: rpmdb: header #33554432 cannot be loaded -- skipping.
> (none)-(none)-(none)
> Segmentation fault

Every time you see "Segmentation fault" you will see all the noise
on the next invocation of rpm as root.

> - --->%---
> 
> How, db_convert and rpm --rebuilddb don't help anymore. The latter one 
> prints:
> 
> - ---%<---
> Freeing read locks for locker 0xe: 25167/3062372160
> Freeing read locks for locker 0xf: 25167/3062372160
> Freeing mutex for process: 25167/0
> Freeing mutex for process: 25167/0
> Freeing mutex for process: 25167/0
> Freeing mutex for process: 25167/0
> Freeing mutex for process: 25167/0
> Freeing mutex for process: 25167/0
> Freeing mutex for process: 25167/0
> Freeing mutex for process: 25167/0
> Freeing mutex for process: 25167/0
> error: db3: header #33554432 cannot be loaded -- skipping.
> error: db3: header #67108864 cannot be loaded -- skipping.
> error: db3: header #83886080 cannot be loaded -- skipping.
> error: db3: header #100663296 cannot be loaded -- skipping.
> error: db3: header #117440512 cannot be loaded -- skipping.
> error: db3: header #134217728 cannot be loaded -- skipping.
> error: db3: header #150994944 cannot be loaded -- skipping.
> error: db3: header #167772160 cannot be loaded -- skipping.
> error: db3: header #201326592 cannot be loaded -- skipping.
> error: db3: header #218103808 cannot be loaded -- skipping.
> error: db3: header #234881024 cannot be loaded -- skipping.
> error: db3: header #268435456 cannot be loaded -- skipping.
> error: db3: header #285212672 cannot be loaded -- skipping.
> error: db3: header #301989888 cannot be loaded -- skipping.
> error: db3: header #385875968 cannot be loaded -- skipping.
> error: db3: header #486539264 cannot be loaded -- skipping.
> rpm: header.c:1050: headerLoad: Assertion `(rpmint32_t)rdl >= 0' failed.
> Aborted

This is a sainity check abort consistent with other failures. The
sanity check isn't strong enough to catch all failures because
(except for signature/digest checks which are often routinely disabled
by applications using an rpmdb) there's insufficient structural info
in the header blob to test that the data within is well-formed:
	bits == bits

> - --->%---
> 
> The underlying BDB version is 5.1.25.
> 

Underlying what?

> I'd be grateful for any hint, and also some explainations about why I did it 
> to kill the system rpmdb using "rpm -r".
> 

Clean-up and save what you have in /var/lib/rpm:
	cd /var/lib/rpm
	db51_recover -ev
	db51_load -r lsn Packages
	cd ..
	mv rpm rpm-SAVE

Create a new directory and copy what you have:
	cd /var/lib
	mkdir -p rpm/log rpm/tmp
	cp rpm-SAVE/DB_CONFIG rpm/
	cp rpm-SAVE/Packages rpm/

Check (as root) that Packages is at least mostly intact:
	rpm -qavv

Re-create the indices (and check that dbconvert.sh swapped the bytes):
	rpm --rebuilddb --vv

The check is that the "Max header instance" after the rebuild isn't
~4Gb (it should be a small positive integer of order the #pkgs you have installed).

hth

73 de Jeff

  • application/pkcs7-signature attachment: smime.p7s
Received on Mon Jun 13 00:54:50 2011
Driven by Jeff Johnson and the RPM project team.
Hosted by OpenPKG and Ralf S. Engelschall.
Powered by FreeBSD and OpenPKG.