Hacker News Reader

Comment by seba_dos1 | Hacker News Reader

With qemu-user and binfmt you can even chroot into foreign CPU architectures, which is a handy thing to have when you mount your phone's eMMC to fix a hacking session gone wrong.

Though these days you may want to look into things like systemd-nspawn instead of plain chroot.

View on HN

> you can even chroot into foreign CPU architectures, which is a handy thing to have when you mount your phone's eMMC

This sounds very interesting! What's the scenario where you'd do this? Would you be, for example, emulating an ARM processor with qemu on an x86 computer and chrooting into Android on an eMMC?

yeah exactly that. your laptop is x86 and your phone or raspberry pi or other hardware is not.

I've done this on some tinker boards we use at work.

systemd-nspawn is a great tool for this.

I've done this to build custom RPi images. Way faster than trying to build on a low power ARM platform, and way less fragile than cross compilers.

Same here, and it is blazingly fast for me running on a M2 macbook air using macOS built in virtulization framework to run an arm64 Debian.

Probably even faster on Asahi Linux, but having both macOS and a fast Debian at the same time is soo neat :)

Perhaps it's fast because M2 is already arm64.

Here is an example of preparing a debian ARM image on x86 with debootstrap, qemu and chroot:

  ~# sudo apt install qemu-user-static debootstrap
  ~# mkdir /tmp/arm
  ~# debootstrap --foreign --arch=armhf buster /tmp/arm http://deb.debian.org/debian
  ~# cp /usr/bin/qemu-arm-static /tmp/arm/usr/bin/
  ~# chroot /tmp/arm   # from that point, you're running ARM!
  ~# /debootstrap/debootstrap --second-stage

These days (with recent kernels) you don't even have to copy the qemu binary into the rootfs nor use a static binary - these used to be workarounds for things that kernel now handles on its own.

This is very cool! I had no idea you could chroot into different architectures.

Well technically you can't, in the sense that chroot has no idea you're doing it... the magic of binfmt support in the kernel (setup for qemu by the post-install script for qemu-user-static I believe) basically lets you run any architecture's binary that qemu-user-* supports just by trying to execute it natively, it basically just translates the execution of "./other-arch-cmd" into "qemu-user-static ./other-arch-cmd".

Thank you. That makes sense. Even though there is a translation layer via qemu-user-static, still having the facilities to have that transparently is very fantastic. And also very fascinating and a revelation to learn about for a bearded old timer like me who has never seen it before.

I used it with Debian on my phone, but yes.

Yeah, that’s how we customize the NVidia Orin BSP before flashing it. Untar the rootfs onto a fast x86-64 machine, chroot into it, and use qemu-user to run a bunch of Arm commands and build some stuff. Way easier than trying to set up a cross-compiler toolchain.

chroot can be a alternative to setting up fussy cross-compilers. It'll be slower, but that slowness pays off as long as you spend less time on extra CPU cycles than you do on getting cross compilers to work.

It's also useful for reverse-engineering router/IoT firmware.

Indeed you can skip most of the unnecessary additional mount requirements with systemd-nspawn. If /dev/sde1 (your root partition) is mounted to /tmp/rescue just run:

systemd-nspawn --directory /tmp/rescue --boot -- --unit rescue.target

It should automatically find the boot partition and mount it as well.

Of course you don't need it, but if you're into docker images, docker or podman can be configured to use QEMU when running a container too.

Reply on news.ycombinator.com