Support foreign architectures (e.g. aarch64 on amd64)

[elloe]

Issue ##138 added the --architecture option, but it is limited to architectures compatible with the host (e.g. x86 on x86_64). That issue originally asked for armhf support.

We're working on a project that harnesses systemd-nspawn and mkosi creating base template images for amd64 and arm64 Debian architectures. Containers will run on native host architectures but whilst we're building and refining the images it is much faster working on powerful amd64 hosts when building and testing the arm64 (aarch64) images.

With the support of qemu-user-static and its qemu-aarch64-static we can successfully build and run Debian chroots using debootstrap --arch=arm64 --foreign ... followed by chroot target/ /debootstrap/debootstrap --second-stage, or more conveniently by simply calling the wrapper qemu-debootstrap --arch=arm64 ...

We're investigating adding support for this into mkosi locally but consider it would be a great addition to mkosi's capabilities and so are seeking feedback on any wider considerations we should take into account before submitting a PR.

Most obviously would be supporting it across distro's and there we'd need input and help from Fedora and dnf experts since we're a Debian/Ubuntu site.

Some changes to hard coded assumptions will be necessary as well, such as code of the form extra_packages.add("linux-image-amd64").

[elloe]

This appears to work perfectly. We're using Ubuntu 20.04 amd64 hosts and creating Debian bullseye (testing) containers as btrfs subvolumes.

There's an unrelated issue apparently in systemd-nspawn where machinectl stop <name> doesn't cause a shutdown and the container ends up in emergency mode.

Do we need to detect and confirm the presence of qemu-user-static and qemu-debootstrap on the host and bail out reporting it missing before allowing installation to proceed?

[poettering]

Do we need to detect and confirm the presence of qemu-user-static and qemu-debootstrap on the host and bail out reporting it missing before allowing installation to proceed?

right now, if some tool we need is missing we'll just fail invoking it, which isn't ideal, but also not a loss, since this is developer-focussed stuff and the error yous see pretty discriptive.

Also, if this works for Debian only initially, that's fine. If others are interested for other distros we can extend this later. Hence please submit the change as PR

[DaanDeMeyer]

This should work as is these days if the version of systemd-nspawn is recent enough (v250 or later) so let's close this. If there are any remaining issues, please open a new issue.