For systemd distros, you might already have systemd-binfmt.service in the systemd package, which when started will automatically register all architectures specified in config files under /usr/lib/binfmt.d with the kernel. Then your qemu package will probably contain one config file in that directory for every arch. So if you enable and start the systemd-binfmt service, you'll automatically have a bajillion architectures registered with the kernel to run under qemu and you don't have to do anything else.
Or you can register manually by writing to /proc/sys/fs/binfmt_misc/register . Note that you'll want to register the statically linked version of qemu (qemu-user-static or whatever your distro calls it), and that you'll want to use at least the O and F flags so that the binary works inside containers automatically insead of needing to be mounted from the host.
> For systemd distros, you might already have systemd-binfmt.service in the systemd package, which when started will automatically register all architectures specified in config files under /usr/lib/binfmt.d with the kernel. Then your qemu package will probably contain one config file in that directory for every arch. So if you enable and start the systemd-binfmt service, you'll automatically have a bajillion architectures registered with the kernel to run under qemu and you don't have to do anything else.
Note that this can screw up other kinds of builds, as the autoconf check for cross-compilation relies on a cross-compiled executable being unrunnable. (Seen with a wine binfmt handler and a MinGW cross compiler.)
Or you can register manually by writing to /proc/sys/fs/binfmt_misc/register . Note that you'll want to register the statically linked version of qemu (qemu-user-static or whatever your distro calls it), and that you'll want to use at least the O and F flags so that the binary works inside containers automatically insead of needing to be mounted from the host.