Subject: bug#50151: Coreutils, aarch64 and chroot

From: Assaf Gordon <[email-masked]>
Date: Wed, 25 Aug 2021 17:25:44 -0600

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.txt
>>
> @assaf: your suggestions no. 1 and 2, had the predicted results. Thus, 
> suggestion no. 3 failed because of suggestion no.2. I followed then 
> suggestion 4 and attached the strace output to this message. It seems 
> that chroot is working as expected, only env seems to fail with an error.

Not exactly:
The 'chroot' system-call *seems* to succeed,
followed by a failed "execve(2)" system call to execute another binary.
That "execve" system fails - so it is not 'env' per-se,
it is any program that will try to execute another aarch64 binary.

Learning that, searching for "qemu-user", "chroot" and "architecture"
leads to several web pages detailing similar errors (and few suggested
solutions):

https://wiki.gentoo.org/wiki/Crossdev_qemu-static-user-chroot

https://newbedev.com/how-can-i-chroot-into-a-filesystem-with-a-different-architechture

https://ownyourbits.com/2018/06/13/transparently-running-binaries-from-any-architecture-in-linux-with-qemu-and-binfmt_misc/

> I hope you have some clue of what is going wrong.

With the above information, we can conclude this is not a bug
in coreutils - it is a limitation of the linux+qemu-user setup.

So I'm closing this item and marking it as "not a bug",
but discussion can continue by replying to this thread.

regards,
  - assaf