"Markus Schönhaber" writes: > No. systemd-nspawn does indeed simply run a container. You can think of > that as a chroot on steroids. This means, everything inside the > container is run using the host kernel. Or to put it the other way > round: what the host kernel can't execute won't run.
Actually, the kernel can execute such foreign ELF binaries. This works with the binfmt_misc file system and registering the appropriate interpreter which is then automaically executed by the kernel. This is similar to the she-bang (!#) mechanism where the kernel also loads the needed interpreter. I've shown that in my mail with executing the aarch64 date binary directly on the amd64 kernel. I didn't see any reason why this shouldn't work with all binaries in a container. Now, when looking at it again, I think the problem is the missing interpreter in the container's file system. Quite obvious. OK, I'll try copying the QEMU interpreter qemu-aarch64 and all needed libs and other files into the appropriate place... Steve
