Note: Due to technical difficulties, the Archives are currently not up to date.
GMANE provides an alternative service for most mailing lists. c.f. bug 424647
List Archive: gentoo-amd64
On 12/17/05, Peter Humphrey <prh@...> wrote:
> Sebastian Redl wrote:
>
> > Actually, emerge doesn't care about what uname reports - only some
> > broken ebuilds might. Emerge only cares about the architecture set in
> > the make profile.
>
> Maybe so, but the l32 utility still isn't doing what it should.
> --
> gentoo-amd64@g.o mailing list
>
>
Hi Peter,
Off list Billy sent me some experiments to do. I did them and sent
my results back to him over the weekend I think. I've not heard back
from him yet. Here's what he asked me to do:
<QUOTE>
(1) Make some placeholders so you know where you are
# touch /in64.txt
# touch /mnt/gentoo32/in32.txt
(2) run l32 as root and as user, and see if you're in the chroot:
(root)# l32 bash
(root)# ls /in32.txt
(root)# uname -a
(2') now do it as a normal user
(user)$ l32 bash
(user)$ ls /in32.txt
(user)$ uname -a
(3) run "linux32 chroot /mnt/gentoo32 bash", and see if you're in the chroot:
(root)# linux32 chroot /mnt/gentoo32 bash
(root)# ls /in32.txt
(root)# uname -a
(4) make sure the environment in /mnt/gentoo32 is really 32-bit:
(root)# file /mnt/gentoo32/bin/uname
(it should say something about a 32-bit LSB executable.)
</QUOTE>
In my case l32 is taking me to the chroot'ed directory (/mnt/gentoo32
in my case) but it's not using the chroot'ed 32-bit identity. For now
I continue to use Firefox as root. I'm sure this is probably something
simple that we'll work out this week.
- Mark
--
gentoo-amd64@g.o mailing list
|
|