I've been trying to use qemu-binfmt-service-type to build a non-native chroot of a Debian system on Guix... because, well... because! In Debian, this works with the qemu-user-static package, where the binfmt sets these flags: $ cat /proc/sys/fs/binfmt_misc/qemu-aarch64 enabled interpreter /usr/bin/qemu-aarch64-static flags: OCF offset 0 magic 7f454c460201010000000000000000000200b700 mask ffffffffffffff00fffffffffffffffffeffffff In particular, the F flag allows the host system binaries to be used as the interpreter inside the chroot. But apparently, this only works with static-built qemu targets, according to the linux's Documentation/admin-guide/binfmt-misc.rst. On Guix there are no flags set, and the binary used is a dynamically linked executable: $ cat /proc/sys/fs/binfmt_misc/qemu-aarch64 enabled interpreter /gnu/store/sw2rrqmjij73wcy3ajd47ypvmzh12yz6-qemu-3.1.0/bin/qemu-aarch64 flags: offset 0 magic 7f454c460201010000000000000000000200b700 mask ffffffffffffff00fffffffffffffffffeffffff So there are (at least) two things needed to make this work on Guix: * A way to set the flags on qemu-binfmt-service-type. * A static build of qemu-user targets * A way to set which qemu to use for qemu-binfmt-service-type. The *three* things are... With this working correctly foreign-architecture chroots would become trivial: # on an amd64 host: $ debootstrap --arch=arm64 buster buster-chroot http://deb.debian.org/debian ... $ chroot buster-chroot /bin/bash Enabling qemu-binfmt-service-type to operate in this way would obviate the need for the "guix-support?" qemu-binfmt-configuration option, as you could simply assemble the build environment without having to include all of qemu's dependencies in the container. It's a pretty magical feature. live well, vagrant