[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: cross-building with qemu-i386/aarch64
From: |
Peter Maydell |
Subject: |
Re: cross-building with qemu-i386/aarch64 |
Date: |
Thu, 12 Aug 2021 10:15:10 +0100 |
On Wed, 11 Aug 2021 at 19:42, Frans de Boer <frans@fransdb.nl> wrote:
> Your proposal (copying qemu-aarch64 to the target directory) is just the
> thing I wanted to avoid. However, Philippe has offered the right
> solution. I missed the -L flag because that was what I needed and -
> albeit not very well - looked for.
> qemu-i386 "</path_to_i386_sbin">/chroot <path_to_new_root> /usr/bin/env
> -i ....... /usr/bin/bash --login
The thing is, this will run the "/path/to/i386/chroot" binary
in your outside-the-target-directory QEMU binary, but everything
else (/usr/bin/env, /usr/bin/bash, anything bash runs) will
be *inside* the chroot and cannot see that QEMU. Those processes
will only be able to run if
(a) it's an i386 binary on an x86-64 system, in which case
none of this needed QEMU in the first place
(b) your binfmt-misc setup uses the 'F' option to arrange that
all chroots use the same host-filesystem QEMU (opened once
rather than opened fresh to run each guest binary). Some
distros do this; it is probably the neatest way to achieve
the "don't have to have a QEMU in the target directory"
that you're after
(c) there's a QEMU in the right place inside the target directory
In any case, running the guest 'chroot' binary doesn't seem to
me like it serves any purpose compared to running the host
'chroot'.
(When you run an executable under QEMU and it does an 'exec' to
launch another program, we just pass that other program to the
host kernel execve() to run. We don't look at it to decide "if
this is another target-architecture binary run it directly",
so we rely on binfmt-misc to start another QEMU if needed.)
thanks
-- PMM