GNU bug report logs - #50151
Coreutils, aarch64 and chroot

Previous Next

Full log

View this message in rfc822 format

From: Assaf Gordon <assafgordon <at> gmail.com>
To: Frans de Boer <frans <at> fransdb.nl>
Cc: Paul Eggert <eggert <at> cs.ucla.edu>, 50151 <at> debbugs.gnu.org
Subject: bug#50151: Coreutils, aarch64 and chroot
Date: Wed, 25 Aug 2021 02:16:24 -0600

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...

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.