From mboxrd@z Thu Jan 1 00:00:00 1970
Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org)
by finch.gentoo.org with esmtp (Exim 4.60)
(envelope-from <gentoo-embedded+bounces-3872-garchives=archives.gentoo.org@lists.gentoo.org>)
id 1Q22CC-0003Ao-Uw
for garchives@archives.gentoo.org; Tue, 22 Mar 2011 14:04:29 +0000
Received: from pigeon.gentoo.org (localhost [127.0.0.1])
by pigeon.gentoo.org (Postfix) with SMTP id A21D21C08C
for <garchives@archives.gentoo.org>; Tue, 22 Mar 2011 14:04:28 +0000 (UTC)
Received: from mail-gx0-f181.google.com (mail-gx0-f181.google.com [209.85.161.181])
by pigeon.gentoo.org (Postfix) with ESMTP id 4C2CB1C054
for <gentoo-embedded@lists.gentoo.org>; Tue, 22 Mar 2011 13:31:18 +0000 (UTC)
Received: by gxk28 with SMTP id 28so4151332gxk.40
for <gentoo-embedded@lists.gentoo.org>; Tue, 22 Mar 2011 06:31:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=gamma;
h=domainkey-signature:mime-version:in-reply-to:references:from:date
:message-id:subject:to:content-type;
bh=Hk2kJfJJOk5vsmHyx4xO7V8AMFe2Nar/xp856llVZ0M=;
b=FcbI7SaUU51Tq+CQl6XcBrJ6sH52zhhjYgfQYn7VIYTpVOy4AvUTYESCrJ+lAhV+zz
02u21UVi0s5SYLdFxAx4OuK1G1fFozA1H+wjUslQ/6JaSmfq5+r1V6mpawqIrdLOpbC5
LaGiRGho1q2yPM6LZW6GmEzkAuz5ZnoB+GgOg=
DomainKey-Signature: a=rsa-sha1; c=nofws;
d=gmail.com; s=gamma;
h=mime-version:in-reply-to:references:from:date:message-id:subject:to
:content-type;
b=Zf7Ss14cEEogtgQ3xeDKoU7ym3N5p/m+g1iRK3W0wlvvUfnm4aLGGqeeyfTJyr/tt5
/1CXaEacC3oRGrWvGoBpHXcmOqSGjrtTf7nrueMT861rikKRi6AGhx6/oe6/QMmcPKNC
3aEUbiG0bzxNl3ur+oDVvI79IrP9gwoMk96/M=
Received: by 10.236.200.138 with SMTP id z10mr7222576yhn.164.1300800677151;
Tue, 22 Mar 2011 06:31:17 -0700 (PDT)
Precedence: bulk
List-Post: <mailto:gentoo-embedded@lists.gentoo.org>
List-Help: <mailto:gentoo-embedded+help@lists.gentoo.org>
List-Unsubscribe: <mailto:gentoo-embedded+unsubscribe@lists.gentoo.org>
List-Subscribe: <mailto:gentoo-embedded+subscribe@lists.gentoo.org>
List-Id: Gentoo Linux mail <gentoo-embedded.gentoo.org>
X-BeenThere: gentoo-embedded@lists.gentoo.org
Reply-to: gentoo-embedded@lists.gentoo.org
MIME-Version: 1.0
Received: by 10.236.109.144 with HTTP; Tue, 22 Mar 2011 06:30:57 -0700 (PDT)
In-Reply-To: <4D88795A.5000309@gmx.ch>
References: <4D88795A.5000309@gmx.ch>
From: Kfir Lavi <lavi.kfir@gmail.com>
Date: Tue, 22 Mar 2011 15:30:57 +0200
Message-ID: <AANLkTi=w-Jxu4Nfbs1qi_2otCAuoOUMSut+YYoKcc9TU@mail.gmail.com>
Subject: Re: [gentoo-embedded] locales / sandbox violations
To: gentoo-embedded@lists.gentoo.org
Content-Type: multipart/alternative; boundary=20cf305b096a49024f049f124212
X-Archives-Salt:
X-Archives-Hash: 3595d988acd5b7a4e83d9cd8650b948d
--20cf305b096a49024f049f124212
Content-Type: text/plain; charset=UTF-8
On Tue, Mar 22, 2011 at 12:26 PM, Martin Gysel <m.gysel@gmx.ch> wrote:
> Hi
>
> I installed a dev chroot on 2 different systems each, both x64, one
> gentoo, one ubuntu as host. in both chroots I created a x-compiler using
> crossdev. in the first one I downloaded a prebuilt armv5tel stage and
> rebuilt it so it uses my USE flags using the x-compiler and qemu
> (depending on pkg). everything went fine so far. in the second chroot I
> used the binpkg from the first one to set up the arm sysroot/root. now
> if I chroot into the sysroot on the second using qemu I get some access
> violations from the sandbox:
> ACCESS DENIED open_wr: /dev/null
> /usr/lib/portage/bin/ebuild.sh: line 1558: /dev/null: Permission denied
> <snip>
> --------------------------- ACCESS VIOLATION SUMMARY
> ---------------------------
> LOG FILE "/var/log/sandbox/sandbox-10088.log"
>
> VERSION 1.0
> FORMAT: F - Function called
> FORMAT: S - Access Status
> FORMAT: P - Path as passed to function
> FORMAT: A - Absolute Path (not canonical)
> FORMAT: R - Canonical Path
> FORMAT: C - Command Line
>
> F: open_wr
> S: deny
> P: /dev/null
> A: /dev/null
> R: /dev/null
> C: /qemu-wrapper -cpu arm926 /bin/bash /usr/lib/portage/bin/ebuild.sh
> unpack
>
> after some googling I found a forum thread saying it's a locale issue.
> so I tried to play with the locale settings. now depending on the locale
> it stop at different stages during emerge. switching of the sandbox also
> works... (which I sometimes need to do anyway as the there's a
> sandbox/qemu 'malloc' issue)
> has someone experienced a similar behavior or knows a solution for this?
> does it help if I try to rebuild everything with my 'new' locale
> settings? can it be a problem to have not set the same locales in the
> 'sysroot/qemu chroot' than for the x-compiler?
>
> btw, the glibc natively built using qemu dosen't work but the x-compiled
> works fine...
>
> thanks
> martin
>
> If I'm understanding correctly, when you chroot on your Gentoo machine,
everything goes fine.
If you chroot on the Ubuntu machine, you get this problem.
Is that correct?
chroot also depends on the kernel running. On the Ubuntu, the kernel will be
the Ubuntu kernel. Is there
any diffs between the Gentoo kernel and the Ubuntu kernel?
Version of qemu, are close or the Ubuntu one is old?
I can't see why locales are involved here. Can you post the link to the
forum thread that state this?
Is 'ls -l /dev/null' the same in each chroot environment (after you bind
/dev)?
Kfir
--20cf305b096a49024f049f124212
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<br><br><div class=3D"gmail_quote">On Tue, Mar 22, 2011 at 12:26 PM, Martin=
Gysel <span dir=3D"ltr"><<a href=3D"mailto:m.gysel@gmx.ch">m.gysel@gmx.=
ch</a>></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"marg=
in: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-l=
eft: 1ex;">
Hi<br>
<br>
I installed a dev chroot on 2 different systems each, both x64, one<br>
gentoo, one ubuntu as host. in both chroots I created a x-compiler using<br=
>
crossdev. in the first one I downloaded a prebuilt armv5tel stage and<br>
rebuilt it so it uses my USE flags using the x-compiler and qemu<br>
(depending on pkg). everything went fine so far. in the second chroot I<br>
used the binpkg from the first one to set up the arm sysroot/root. now<br>
if I chroot into the sysroot on the second using qemu I get some access<br>
violations from the sandbox:<br>
ACCESS DENIED =C2=A0open_wr: =C2=A0 =C2=A0 =C2=A0/dev/null<br>
/usr/lib/portage/bin/ebuild.sh: line 1558: /dev/null: Permission denied<br>
<snip><br>
--------------------------- ACCESS VIOLATION SUMMARY<br>
---------------------------<br>
LOG FILE "/var/log/sandbox/sandbox-10088.log"<br>
<br>
VERSION 1.0<br>
FORMAT: F - Function called<br>
FORMAT: S - Access Status<br>
FORMAT: P - Path as passed to function<br>
FORMAT: A - Absolute Path (not canonical)<br>
FORMAT: R - Canonical Path<br>
FORMAT: C - Command Line<br>
<br>
F: open_wr<br>
S: deny<br>
P: /dev/null<br>
A: /dev/null<br>
R: /dev/null<br>
C: /qemu-wrapper -cpu arm926 /bin/bash /usr/lib/portage/bin/ebuild.sh unpac=
k<br>
<br>
after some googling I found a forum thread saying it's a locale issue.<=
br>
so I tried to play with the locale settings. now depending on the locale<br=
>
it stop at different stages during emerge. switching of the sandbox also<br=
>
works... (which I sometimes need to do anyway as the there's a<br>
sandbox/qemu 'malloc' issue)<br>
has someone experienced a similar behavior or knows a solution for this?<br=
>
does it help if I try to rebuild everything with my 'new' locale<br=
>
settings? can it be a problem to have not set the same locales in the<br>
'sysroot/qemu chroot' than for the x-compiler?<br>
<br>
btw, the glibc natively built using qemu dosen't work but the x-compile=
d<br>
works fine...<br>
<br>
thanks<br>
<font color=3D"#888888">martin<br>
<br>
</font></blockquote></div>If I'm understanding correctly, when you chro=
ot on your Gentoo machine, everything goes fine. <br>If you chroot on the U=
buntu machine, you get this problem. <br>Is that correct?<br>chroot also de=
pends on the kernel running. On the Ubuntu, the kernel will be the Ubuntu k=
ernel. Is there<br>
any diffs between the Gentoo kernel and the Ubuntu kernel? <br>Version of q=
emu, are close or the Ubuntu one is old?<br>I can't see why locales are=
involved here. Can you post the link to the forum thread that state this?<=
br>
Is 'ls -l /dev/null' the same in each chroot environment (after you=
bind /dev)?<br><br>Kfir<br>
--20cf305b096a49024f049f124212--