qemu-discuss
[Top][All Lists]
Advanced

[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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]