Hello all...
On my x86_64 (CentOS 5.1) system I use mock to init an i386 chroot for both Fedora 8 and CentOS 5.1. The init appears to work fine, but when I drop into a mock-shell for either F8 or CentOS my rpm database is corrupt on both accounts:
mock-chroot> rpm -qa rpmdb: Program version 4.3 doesn't match environment version error: db4 error(-30974) from dbenv->open: DB_VERSION_MISMATCH: Database environment version mismatch error: cannot open Packages index using db3 - (-30974) error: cannot open Packages database in /var/lib/rpm
Rebuilding the rpm database seems to fix this, but it's a pain to be sure. Any ideas as to why I'm seeing this corruption when creating an i386 mock chroot from a x86_64 system?
Also, FYI, when I do this for x86_64 chroots or if I do this from my i386 CentOS system, the rpm database does not get corrupt.
Thanks...Paul...
On Sat, May 31, 2008 at 7:04 PM, Paul B Schroeder paul.schroeder@bluecoat.com wrote:
Rebuilding the rpm database seems to fix this, but it's a pain to be sure. Any ideas as to why I'm seeing this corruption when creating an i386 mock chroot from a x86_64 system?
This is normal and expected. You created the rpmdb with x86_64 rpm, and are accessing it with i386 rpm. The Berkeley DB format is different based on the arch of the creating machine, therefore generates the database differently on the two platforms. If I plan on doing anything in a chroot (especially a non-native arch one) other than building a SRPM, the first thing that happens is to rm -f /var/lib/rpm/__db*. Don't worry, this got me the first time too (and is fatal to a pungi compose) :)
On Sat, 2008-05-31 at 22:16 -0400, Jon Stanley wrote:
On Sat, May 31, 2008 at 7:04 PM, Paul B Schroeder paul.schroeder@bluecoat.com wrote:
Rebuilding the rpm database seems to fix this, but it's a pain to be sure. Any ideas as to why I'm seeing this corruption when creating an i386 mock chroot from a x86_64 system?
This is normal and expected. You created the rpmdb with x86_64 rpm, and are accessing it with i386 rpm. The Berkeley DB format is different based on the arch of the creating machine, therefore generates the database differently on the two platforms. If I plan on doing anything in a chroot (especially a non-native arch one) other than building a SRPM, the first thing that happens is to rm -f /var/lib/rpm/__db*. Don't worry, this got me the first time too (and is fatal to a pungi compose) :)
Ah.. I see.. I would think there would be some way to tell it to create the DB in i386 format though? Is there an environment variable or something that can be set?
On Monday 02 June 2008, Paul B Schroeder wrote:
On Sat, 2008-05-31 at 22:16 -0400, Jon Stanley wrote:
On Sat, May 31, 2008 at 7:04 PM, Paul B Schroeder
paul.schroeder@bluecoat.com wrote:
Rebuilding the rpm database seems to fix this, but it's a pain to be sure. Any ideas as to why I'm seeing this corruption when creating an i386 mock chroot from a x86_64 system?
This is normal and expected. You created the rpmdb with x86_64 rpm, and are accessing it with i386 rpm. The Berkeley DB format is different based on the arch of the creating machine, therefore generates the database differently on the two platforms. If I plan on doing anything in a chroot (especially a non-native arch one) other than building a SRPM, the first thing that happens is to rm -f /var/lib/rpm/__db*. Don't worry, this got me the first time too (and is fatal to a pungi compose) :)
Ah.. I see.. I would think there would be some way to tell it to create the DB in i386 format though? Is there an environment variable or something that can be set?
No, the hosts rpm is used to populate the chroot. when you enter the chroot you can delete /var/lib/rpm/__db* and things will work.
You get the same issues with building say F-7 chroots on a F-9 host where the chroot has a different version of the the database than the host.
Dennis
On Mon, 2008-06-02 at 08:25 -0500, Dennis Gilmore wrote:
On Monday 02 June 2008, Paul B Schroeder wrote:
On Sat, 2008-05-31 at 22:16 -0400, Jon Stanley wrote:
On Sat, May 31, 2008 at 7:04 PM, Paul B Schroeder
paul.schroeder@bluecoat.com wrote:
Rebuilding the rpm database seems to fix this, but it's a pain to be sure. Any ideas as to why I'm seeing this corruption when creating an i386 mock chroot from a x86_64 system?
This is normal and expected. You created the rpmdb with x86_64 rpm, and are accessing it with i386 rpm. The Berkeley DB format is different based on the arch of the creating machine, therefore generates the database differently on the two platforms. If I plan on doing anything in a chroot (especially a non-native arch one) other than building a SRPM, the first thing that happens is to rm -f /var/lib/rpm/__db*. Don't worry, this got me the first time too (and is fatal to a pungi compose) :)
Ah.. I see.. I would think there would be some way to tell it to create the DB in i386 format though? Is there an environment variable or something that can be set?
No, the hosts rpm is used to populate the chroot. when you enter the chroot you can delete /var/lib/rpm/__db* and things will work.
You get the same issues with building say F-7 chroots on a F-9 host where the chroot has a different version of the the database than the host.
I understand how it's working. (Although, I didn't know Berkely DB had diff formats for diff archs beforehand) But I was hoping there might be a way (in my Makefiles) to tell my x86_64 host's rpm to always operate in i386 mode.
I can live with it, but I am setting up a build environment for other (read less Linux literate) folks to use. I'd like to head off any forthcoming confusion if possible.
Cheers...Paul...
On Monday 02 June 2008, Paul B Schroeder wrote:
On Mon, 2008-06-02 at 08:25 -0500, Dennis Gilmore wrote:
On Monday 02 June 2008, Paul B Schroeder wrote:
On Sat, 2008-05-31 at 22:16 -0400, Jon Stanley wrote:
On Sat, May 31, 2008 at 7:04 PM, Paul B Schroeder
paul.schroeder@bluecoat.com wrote:
Rebuilding the rpm database seems to fix this, but it's a pain to be sure. Any ideas as to why I'm seeing this corruption when creating an i386 mock chroot from a x86_64 system?
This is normal and expected. You created the rpmdb with x86_64 rpm, and are accessing it with i386 rpm. The Berkeley DB format is different based on the arch of the creating machine, therefore generates the database differently on the two platforms. If I plan on doing anything in a chroot (especially a non-native arch one) other than building a SRPM, the first thing that happens is to rm -f /var/lib/rpm/__db*. Don't worry, this got me the first time too (and is fatal to a pungi compose) :)
Ah.. I see.. I would think there would be some way to tell it to create the DB in i386 format though? Is there an environment variable or something that can be set?
No, the hosts rpm is used to populate the chroot. when you enter the chroot you can delete /var/lib/rpm/__db* and things will work.
You get the same issues with building say F-7 chroots on a F-9 host where the chroot has a different version of the the database than the host.
I understand how it's working. (Although, I didn't know Berkely DB had diff formats for diff archs beforehand) But I was hoping there might be a way (in my Makefiles) to tell my x86_64 host's rpm to always operate in i386 mode.
I can live with it, but I am setting up a build environment for other (read less Linux literate) folks to use. I'd like to head off any forthcoming confusion if possible.
Cheers...Paul...
Please dont CC me on list email just "reply to list"
you could try run setarch i386 before the mock command.
Dennis
On Mon, 2008-06-02 at 09:11 -0500, Dennis Gilmore wrote:
On Monday 02 June 2008, Paul B Schroeder wrote:
On Mon, 2008-06-02 at 08:25 -0500, Dennis Gilmore wrote:
On Monday 02 June 2008, Paul B Schroeder wrote:
On Sat, 2008-05-31 at 22:16 -0400, Jon Stanley wrote:
On Sat, May 31, 2008 at 7:04 PM, Paul B Schroeder
paul.schroeder@bluecoat.com wrote:
Rebuilding the rpm database seems to fix this, but it's a pain to be sure. Any ideas as to why I'm seeing this corruption when creating an i386 mock chroot from a x86_64 system?
This is normal and expected. You created the rpmdb with x86_64 rpm, and are accessing it with i386 rpm. The Berkeley DB format is different based on the arch of the creating machine, therefore generates the database differently on the two platforms. If I plan on doing anything in a chroot (especially a non-native arch one) other than building a SRPM, the first thing that happens is to rm -f /var/lib/rpm/__db*. Don't worry, this got me the first time too (and is fatal to a pungi compose) :)
Ah.. I see.. I would think there would be some way to tell it to create the DB in i386 format though? Is there an environment variable or something that can be set?
No, the hosts rpm is used to populate the chroot. when you enter the chroot you can delete /var/lib/rpm/__db* and things will work.
You get the same issues with building say F-7 chroots on a F-9 host where the chroot has a different version of the the database than the host.
I understand how it's working. (Although, I didn't know Berkely DB had diff formats for diff archs beforehand) But I was hoping there might be a way (in my Makefiles) to tell my x86_64 host's rpm to always operate in i386 mode.
I can live with it, but I am setting up a build environment for other (read less Linux literate) folks to use. I'd like to head off any forthcoming confusion if possible.
Cheers...Paul...
Please dont CC me on list email just "reply to list"
Oops.. Apologies..
you could try run setarch i386 before the mock command.
Yea.. I tried that one already.. Didn't work.
buildsys@lists.fedoraproject.org
-
Dennis Gilmore -
Jon Stanley -
Paul B Schroeder