I'm trying to chroot into a Arch Linux ARM filesystem from x86_64.

I've seen that it's possible to do using static qemu by copying the binary into the chroot system:

$ cp /usr/bin/qemu-arm archarm-chroot/usr/bin    

But despite this I always get the following error:

chroot: failed to run command ‘/bin/bash’: Exec format error

I know this means that the architectures differ. Am I doing something wrong?

up vote 12 down vote accepted

You cannot chroot into different architecture. By chrooting, you are executing the binaries (from the chroot) on your architecture. Executing ARM binaries on x86 (and x86_64 in that matter) would lead to "Exec format error".

If you want to run binaries from different architecture you will need an Emulator. Qemu is a good candidate for this, but you will need to learn how to use it. This would involve creating RootFS and compiling a kernel for ARM. You will need a toolchain for compiling ARM binaries (and kernel) perhaps. One thing is for sure: Forget the chroot method, you cannot run binaries compiled for ARM on x86 (x86_64).

Edit: After the small talk with @UrichDangel, I realized, it should be possible to enter the chroot environment with qemu-user programs (qemu-arm in this case). Chroot should be executing qemu-arm compiled for your host architecture, then the qemu-arm can execute your /bin/sh (compiled for arm).

  • 5
    You should be able to use binfmt and qemu in combination to run non native targets - wiki.debian.org/QemuUserEmulation – Ulrich Dangel Jun 28 '12 at 22:59
  • 2
    I know how to use Qemu for emulation. Apparently you can use it with chroot, although clearly I cannot work out how. – Jivings Jun 28 '12 at 23:01
  • @UlrichDangel, Yes, this is a good information. But I think the OP were not looking for this king of solution. binfmt would be possible once he has properly installed qemu with qemu-arm emulation, but I believe he is wanting to enter his ARM emulation environment (e.g. Raspberry Pi) where he would need qemu-system-arm. – 0xAF Jun 28 '12 at 23:07
  • @0xAF but the binfmt/qemu-user solution is exactly what OP described, being able to chroot into into an arm chroot and run the commands without the need to build a dedicated rootfs etc. – Ulrich Dangel Jun 28 '12 at 23:09
  • 1
    @UlrichDangel, now on a second though, I believe you're right. It is possible to enter emulated chroot with the qemu-arm (or should be). I'll Edit my comment on that. – 0xAF Jun 28 '12 at 23:16

I use an ARM chroot from time to time: my phone runs Linux Deploy and the image dies now and then. I then copy it to my computer and examine the situation with chroot like this:

# This provides the qemu-arm-static binary
apt-get install qemu-user-static

# Mount my target filesystem on /mnt
mount -o loop fs.img /mnt

# Copy the static ARM binary that provides emulation
cp $(which qemu-arm-static) /mnt/usr/bin
# Or, more simply: cp /usr/bin/qemu-arm-static /mnt/usr/bin

# Finally chroot into /mnt, then run 'qemu-arm-static bash'
# This chroots; runs the emulator; and the emulator runs bash
chroot /mnt qemu-arm-static /bin/bash
  • This one works , but after chroot all command gives no such file or directory. I'm using Fedora 24 , selinux problem? Need help please – Superbiji Sep 5 '16 at 10:33
  • @Superbiji Does running /bin/ls work? In that case, your $PATH variable is unset or garbled. Try export PATH=/sbin:/usr/sbin:/usr/bin:/bin. There might be other paths that you should add, but this is probably a good start. If that doesn't work, you probably forgot to copy binaries to the chroot environment. You can use bash to browse around the filesystem too, like echo /* is roughly equivalent to ls /*. I don't know if SELinux might get in the way, no experience there. – Luc Sep 5 '16 at 12:05
  • 1
    Even ls gives /bin/ls: no such file or directory. export shows good path. But echo /* is working, echo /usr/bin/qemu-arm* list the file. I have also mount sys, proc, dev – Superbiji Sep 5 '16 at 16:01
  • @Superbiji Where is your shell installed? That place should usually also contain other basics like ls. Check that, and if it doesn't have it, put them there. That's all I can say without knowing details, and as this is a Q&A and not tech support, you should create a new question if you want to go into details (perhaps also link to this comment thread). – Luc Sep 6 '16 at 18:43
  • Thanks for helping.. found the problem the cause is interpreter in binfmt point to invalid path – Superbiji Sep 8 '16 at 15:51

I think the problem is that you should not copy qemu-arm but qemu-arm-static. This is a static compiled executable able to run from inside the chroot without any libraries.

You can also look in /proc/sys/fs/binfmt_misc if there exists a file qemu-arm. If not restart the service binfmt_support.

  • I had to manually run: update-binfmts --importdir /var/lib/binfmts/ --import then everything showed up in /proc/sys/fs/binfmt_misc and the chroot works. – Mariano Alvira Jan 2 '15 at 22:58

To get this to work I installed qemu-static-arm and binfmt-support from AUR.

Read the comments for qemu-user-static. I had to update the PKGBUILD with the most recent download URL and hashes for makepkg to finish.

(To install from AUR, download the tarball, untar, cd, run makepkg -i)

Christian Wolf's answer is important. update-binfmts is not executed properly to enable these formats. To do so I ran:

update-binfmts --importdir /var/lib/binfmts/ --import

as described in the manpage for update-binfmts. After that, cat /proc/sys/fs/binfmt_misc will show the various binfmts.

Then make sure to copy the qemu-*-static to the usr/bin/ directory in the thing you want to chroot to and then the chroot should work.

You can most definitely 'chroot' into a (mounted) filesystem meant for a different architecture and do some meaningful work, you just need the right tools.

Have a look at PRoot, which is a user-space implementation of chroot, mount --bind, and binfmt_misc: https://proot-me.github.io/

Together with QEMU's user mode emulators, you're all set.

Although you usually cannot perform a 'full' boot (i.e. starting init and services), it is good enough to run some binaries from their 'natural' place, with access to all their configuration files, including some that are bind-mounted from the 'host' system, etc.

sudo apt-get update
sudo apt-get install debootstrap qemu qemu-user-static
sudo qemu-debootstrap --arch armhf bionic armhf-chroot
sudo chroot armhf-chroot

uname -m 

I just ran into the same issue on Ubuntu. I did have binfmt configured and qemu-arm-static copied to the same chroot-ed path as on host system.

After an hour, I did set|grep bash on a host machine. I found that I had /bin/bash in two env variables: SHELL and SUDO_COMMAND. After replacing the variables, my chroot to ARM worked:

SHELL=/bin/sh SUDO_COMMAND=/bin/sh chroot hd

I believe, for this OP, all he needed to do was configure binfmts, simply by running:

update-binfmts --enable qemu-arm

After running this, chroot into the arm filesystem would have been possible.

Adding to Luc's answer: you need to make sure the location of the interpreter is the same in the chroot as it is in the main file system. This is because the kernel detects the architecture of an executable and then uses the location of the interpreter as shown by update-binfmts --display to start it up. So the line

cp $(which qemu-arm-static) /mnt/usr/bin

should actually be

cp $(which qemu-arm-static) /mnt/$(which qemu-arm-static)

Otherwise, you may get "Not found"-errors inside your chroot as your kernel can't find the required interpreter, if the location of qemu-arm-static is not inside /usr/bin on your system.

Your Answer

 

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.