On Apr 16, 2012, at 10:37 PM, ext tuxor1...@web.de wrote:
> hello everyone,
>
> I'm trying to setup an ARM cross-compiling environment inside of an i386
> Xubuntu machine. What I do is:
>
> # build scratchbox2 from source
> # build qemu from source
>
> # setup environment in $ROOTFS
> $ cd $ROOTFS
> $ sb2-init -n -c $HOME/sbox2/bin/qemu/bin/qemu-arm /path/to/arm-linux-gcc
> $ fakeroot /usr/sbin/debootstrap --variant=scratchbox --foreign --arch armel
> wheezy $ROOTFS http://ftp.de.debian.org/debian
> $ sb2 -eR ./debootstrap/debootstrap --second-stage
>
> The last command fails. It doesn't create any output.
I think that debootstrap used to work, so something has been changed. Since you
seem to be using the old-but-stable version of SB2, it shouldn't be
that...maybe debootstrap has been evolving, maybe it is something else, but the
good news is that this can be handled with a newer SB2 + some patches that I
have been implementing today:
> Instead I get lots of lines like this in $ROOTFS/debootstrap/debootstrap.log:
>
> tar: dev/kmem: Cannot mknod: Permission denied
> tar: dev/mem: Cannot mknod: Permission denied
> tar: dev/core: Cannot open: File exists
> tar: dev/null: Cannot utime: Operation not permitted
>
> It seems to me like the problem is, that /dev is not remapped:
>
> $ sb2 -eR sb2-show path /dev
> /dev => /dev
No, that isn't the problem; mapping /dev to real /dev is intentional. Since SB2
has been designed to work without root privileges, the real /dev must be used.
Instead, some operations like mknod() must be mapped elsewhere.
Latest development versions can create simulated device nodes, and those are
perfect for solving this problem, too. There were similar issues with /dev ca.
three months ago, and some additional mapping rules were added to the
"obs-rpm-install" mode. All that is in the 2.3_development branch.
I just copied those special /dev rules to the "emulate" mode, and added a few
additional rules (debootstrap wanted to create symlinks to /dev, something
which rpm didn't do, etc).
Now debootstrap --second-stage passes here. There are some messages, but the
exit code is 0 and it seems to have succeeded.
I'll add these changes to the next development version, 2.3.53. I'll need to do
some additional testing, but probably I can release that tomorrow.
> I tried the "install" mapping, but ended up with this:
>
> $ sb2 -m install -R sb2-show path /dev
> sb2: Error: Failed to find out how /home/tuxor/sbox2/bin/qemu/bin/qemu-arm
> should be started
"install" mode has been obsoleted. It still exists in 2.2, but isn't in 2.3 and
won't come back, I think.
> # build scratchbox2 from source
> $ git clone git://gitorious.org/scratchbox2/scratchbox2.git
Please use sources from the 2.3 branch:
git checkout -b 2.3_development origin/2.3_development
(Once the fix to this debootstrap problem is ready, it will available only in
that branch. 2.3 should be quite mature, all mechanisms needed for fixing this
are only in that branch, and it isn't feasible to try to backport all necessary
things to 2.2)
> # build qemu from source
> $ git clone git://git.savannah.nongnu.org/qemu.git
> $ cd qemu
> $ git checkout v0.13.0 -b devel_env
That is a really old version, too. You'll probably want to get a fresh Qemu
from qemu.org.
Lauri
_______________________________________________
Scratchbox-users mailing list
Scratchbox-users@lists.scratchbox.org
http://lists.scratchbox.org/cgi-bin/mailman/listinfo/scratchbox-users
