RSS

Converting new rpm databases to old format

I better post this before I forget about it. One of the issues I had today was getting corp3/x86_64 installed in a chroot with Mandriva 2009.0 as the host. Of course, the db4 version had changed, so I had to take advantage of some conversion tools. urpmi is supposed to do this magically, but it doesn’t seem consistent. Anyways, the problem lies with 2009.0′s rpm using a newer version of the database than the older version. For instance:

# file /var/lib/rpm/Packages
/var/lib/rpm/Packages: Berkeley DB (Hash, version 9, native byte-order)
# file /chroots/64/cs3/var/lib/rpm/Packages
/chroots/64/cs3/var/lib/rpm/Packages: Berkeley DB (Hash, version 8, native byte-order)

So the trick is to convert them from the new format to the old format, which is easy enough to do once you know what to do. On the host (Mandriva 2009 in this case), make sure you have db46_utils and db42_utils installed:

# rpm -qa|grep "db.*\-utils"
db46-utils-4.6.21-9mdv2009.0
db42-utils-4.2.52-24mdv2009.0

Then you can use this rough-n-dirty script I wrote to convert them:

#!/bin/sh
#
# script to dump and reload the rpm db to convert from hash format 9 to format 8
# for older distribs (think cs3)

for i in $(ls -1); do
    if [ "`file ${i} | grep 9`" != "" ]; then
        db_dump ${i} >${i}.db46
        db42_load ${i}.db42 < ${i}.db46
        mv -f ${i} ${i}.org
        mv -f ${i}.db42 ${i}
    fi
done

That should fix the errors you would see in the chroot, plus make it so that rpm -qa and friends actually work.

2 Comments
Jan 30, 2009
By vdanen Linux Tags: ,

2 Comments

  1. littletux

    IIRC, you don’t need to convert anything if db*-utils are installed before creating the chroot.

    Anyway, nice script to avoid to re-install, thanks :-)

    Jan 31, 2009 @ 03:13:19

  2. vdanen

    No, urpmi is supposed to do this and for most cases it worked. With a 2009.0 host, I installed chroots for 2008.1, 2008.0, CS4 (both archs, 32bit and 64bit), and CS3/32bit. It was only CS3/64bit that did not work. I really have no idea why that one failed while the rest worked. It looked like it was initially converted back the first two urpmi runs, and then there were no messages from urpmi regarding converting back. So something went sideways on that chroot, and this was the only way to fix it.

    Jan 31, 2009 @ 08:37:10

Leave a Reply

*