"Tim Woodall" <debianu...@woodall.me.uk> writes:
> Don't know about systemd-nspawn but I do something like this using
> unshare, binfmt-support and qemu-user-static.
>
> I don't have to do anything at all other than create the file system
> with the emulated architecture and then chroot into it with those
> packages installed.
Thanks, the hint to qemu-user-static solved the issue very easily.
Nothing to install inside the container or other things to setup. I
just installed qemu-user-static, which removed qemu-user-binfmt
because qemu-user-static brings its own binfmt support.
After installing I could simply run systemd-nspawn -D deb-arm64 and it
worked immediately, where deb-arm64 is the directory to which I have
installed the Debian/arm64 system using debootstrap.
I think systemd-nspawn does something very similar to what you do with
unshare and chroot.
> Perhaps systemd-nspawn would similarly work with those packages
> installed.
Yes, out of the box. I find this a litte bit surprising since
# head -n2 /proc/sys/fs/binfmt_misc/qemu-aarch64
enabled
interpreter /usr/libexec/qemu-binfmt/aarch64-binfmt-P
# ls -l /usr/libexec/qemu-binfmt/aarch64-binfmt-P
lrwxrwxrwx 1 root root 29 May 9 07:44
/usr/libexec/qemu-binfmt/aarch64-binfmt-P -> ../../bin/qemu-aarch64-static
these paths are not visible in the chroot environment or the mount
namespace, respectively. That means the kernel probably does the
interpreter lookup earlier, not at execution time in the chrooted
environment. Besides that, qemu-aarch64-static doesn't need any other
files from the host environment. In contrast, qemu-aarch64 which I had
used instead, needs libraries which it cannot find in the chrooted
environment and therefore fails.
Nevertheless, it would be nice to be able to run qemu-aarch64
dynamically linked which finds its libs in the host environment but
runs the command in the current inherited environment. But I guess
that's impossible.
Steve
