6:04 p.m.
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...
9:16 p.m.
On Sat, May 31, 2008 at 7:04 PM, Paul B Schroeder
<paul.schroeder(a)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) :)
7:19 a.m.
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(a)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?
8:25 a.m.
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(a)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
8:46 a.m.
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(a)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...
9:11 a.m.
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(a)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
12:47 p.m.
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(a)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.
5806
days inactive
5808
days old
buildsys@lists.fedoraproject.org
6 comments
3 participants
participants (3)
-
Dennis Gilmore -
Jon Stanley -
Paul B Schroeder