Hello,
On 2021-08-24 2:39 a.m., Paul Eggert wrote:
However, I think it'll be a better use of our time for you to debug
this one yourself. It doesn't sound like a Coreutils problem; it
sounds like a problem in your virtual machine setup, and you're the
best expert on that setup.
Few suggestions to check, that might help you and us to troubleshoot:
1. ensure the binaries are indeed for aarch64:
file /newroot/usr/sbin/chroot
file /newroot/usr/bin/env
file /newroot/usr/bin/bash
it should say something like
"ELF 64-bit LSB pie executable, ARM aarch64"
for all of them.
2. ensure each binary works by itself:
qemu-aarch64 -L /newroot /newroot/usr/sbin/chroot --version
qemu-aarch64 -L /newroot /newroot/usr/bin/env --version
qemu-aarch64 -L /newroot /newroot/usr/bin/bash --version
(the actual version doesn't matter here, the main thing is that
the qemu user-mode emulator was able to run the binaries.)
On 2021-08-21 4:33 a.m., Frans de Boer wrote:
Running 'qemu-aarch64 -L /newroot /newroot/usr/bin/bash -c
/usr/bin/env> --help' does show the env help text. So, I guess chroot
is to blame?
Note that the above command runs your *host's* /usr/bin/env
because chroot is not used - the binary under qemu
(/newroot/usr/bin/bash) sees your host's file system.
Observe with:
qemu-aarch64 -L /newroot /newroot/usr/bin/bash -c /bin/uname -m
qemu-aarch64 -L /newroot /newroot/usr/bin/env /bin/uname -m
I'm guessing you will see "x86_64", not "aarch64".
3. What you should try is:
qemu-aarch64 -L /newroot \
/newroot/usr/bin/bash -c /newroot/usr/bin/env --version
and:
qemu-aarch64 -L /newroot \
/newroot/usr/bin/env /newroot/usr/bin/bash --version
In both cases, one aarch64 binary will try to execute another aach64
binary. Do these work for you, or are you seeing an error?
4. Use qemu's "-strace" to see the syscalls, hopefully
that will help pinpoint the cause:
qemu-aarch64 -strace -L /newroot \
/newroot/usr/sbin/chroot /newroot /usr/bin/env --version 2&1 \
| tee log.txt
If the command results in an error, the "log.txt" file will show
more details about what failed.
If you're not familiar with 'strace' output, post it here as an email
attachment.
Hope this helps,
- assaf
P.S.
On 2021-08-24 2:39 a.m., Paul Eggert wrote:
A complete set of instructions for an outsider to reproduce the
problem from scratch. Assume the outsider is running Fedora 34
x86-64 (since that's what I'm running :-).
I'm not familiar with Fedora, but on Debian/x86_64 the following works:
apt-get qemu-user
apt-get install crossbuild-essential-arm64 libc6-arm64-cross
cd coreutils
./configure --host=aarch64-linux-gnu
make
then:
$ qemu-aarch64 -L /usr/aarch64-linux-gnu/ ./src/uname -m
aarch64
Somewhat related:
$ qemu-aarch64 -L /usr/aarch64-linux-gnu/ ./src/env ./src/uname -m
/lib/ld-linux-aarch64.so.1: No such file or directory
This fails because once "inside" qemu, the aarch64 searches for
"/lib/ld-linux-aarch64.so.1" but the file is in
"/usr/aarch64-linux-gnu/lib/ld-linux-aarch64.so.1".
One possible work-around is to build static binaries.
I don't want to assume that is the culprit for Frans, so we'll wait
for the logs...