On 8/26/21 11:14, Frans de Boer wrote:
On 8/26/21 10:19, Andreas Schwab wrote:
On Aug 26 2021, Frans de Boer wrote:
I was not sure, but I tried the same also with x86_64 cross compiled
programs using qemu-i386, which worked.
Of course, they can be natively executed.
Andreas.
I understand
On 8/26/21 10:19, Andreas Schwab wrote:
On Aug 26 2021, Frans de Boer wrote:
I was not sure, but I tried the same also with x86_64 cross compiled
programs using qemu-i386, which worked.
Of course, they can be natively executed.
Andreas.
I understand now better how things are connected
On 8/26/21 01:25, Assaf Gordon wrote:
tag 50151 notabug
close 50151
stop
On 2021-08-25 12:54 p.m., Frans de Boer wrote:
On 8/25/21 10:16 AM, Assaf Gordon wrote:
qemu-aarch64 -strace -L /newroot \
/newroot/usr/sbin/chroot /newroot /usr/bin/env --version 2&1 \
| tee log
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
On 8/21/21 6:43 PM, Paul Eggert wrote:
On 8/21/21 3:33 AM, Frans de Boer wrote:
So, I guess chroot is to blame?
Seems unlikely that it'd be a coreutils bug. Possibly you simply have
the wrong type of executable installed as /newroot/usr/sbin/chroot.
If it is a coreutils bug, please
LS,
I have an issue with chroot in the next context:
qemu-aarch64 -cpu cortex-a53 -L /newroot /newroot/usr/sbin/chroot /newroot \
/usr/bin/env -i \
HOME=/root \
TERM="$TERM" \
PS1='(arm chroot) \u:\w\$ ' \
PATH=/usr/bin:/usr/sbin \
/usr/bin/bash --login +h
qemu-aarch64 is
