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