On Wed, 11 Aug 2021 at 12:20, Frans de Boer <frans@fransdb.nl> wrote:
However when I start:
qemu-i386 /path to i386 sbin/chroot "<path to new root> /usr/bin/env
-i ....... /usr/bin/bash --login
I end up that the chroot program complains that it can't find
/lib/libc.so.6, which actually does exist on <path to new
root>/lib/libc.so.6.
Can you give the command in a clearer way, please, ie without
spaces in the middle of it? I can't tell whether you mean
"/path to i386 sbin/chroot" to be a single argument, or
multiple arguments.
It looks as if you're trying to run the guest 'chroot' binary
from inside the chroot subdir under QEMU. This doesn't work
because the guest chroot binary is linked against the guest
libc but you're running it outside the chroot, so it can't find it.
You need to do it the other way around, so you run the host's
chroot binary and tell that to run QEMU, eg:
chroot /path/to/chroot /path/to/qemu-aarch64 /bin/ls
(Note that you need any host-architecture libs that qemu-aarch64
requires inside the chroot -- or do the sensible thing and
use a statically linked qemu.)
But usually for this sort of setup you have set binfmt-misc
so that it knows that aarch64 binaries are run with (eg)
"/usr/bin/qemu-aarch64-static", so you statically compile QEMU
(or use the distro's statically compiled QEMU), copy that
into /path/to/chroot/usr/bin/qemu-aarch64-static, and then
you can just "chroot /path/to/chroot" with no arguments.
Also, 'i386' is a weird architecture to be using QEMU
in a chroot for, assuming your host architecture is
x86-64 (which it is for most people). You can run i386
binaries under x86-64 kernels, so you don't need to
emulate anything.
-- PMM