On 06/05/2016 09:43 AM, Mike wrote: > https://gmplib.org/~tege/qemu.html > > Scrolling down to the aarch64 section describes the situation.
Is what is describe there for aarch64 actually that bad? Having to modify /etc/initramfs-tools/modules seems to be not too bad of a thing to me... You could probably even preseed the installer with a custom command, see [1] for details. On the other hand - what do you want to use emulated aarch64 for? Do you really need to have a full emulated system, to test the kernel etc.? Or would a chroot be sufficient? Because what works _really_ well with aarch64 is qemu-user, i.e. running aarch64 binaries directly on your local system. There's a nice tool called qemu-debootstrap with which you can automatically create a chroot with a different architecture. Some are supported better than others [2], but for aarch64 I've only had good experiences with it. For example, qemu-debootstrap --arch=arm64 sid aarch64-chroot works out of the box. (jessie as well as sid.) You can the just chroot into that, chroot aarch64-chroot /bin/bash and install stuff you like (just like any other regular chroot). (Probably want to edit /etc/apt/sources.list first and copy /etc/resolv.conf from your host system though.) The same caveats that apply for normal chroots also apply here - and as with regular chroots, I'd recommend using schroot to manage them once they're set up. (Or use them as basis for pbuilder, if you want to build Debian packages. Or both.) Obviously anything that is related to hardware access won't work in there (because no full system is emulated), but it's great for e.g. compiling software - and it's a bit faster than using the system emulator, because it just emulates the program's CPU instructions and translates syscalls, it still uses your host's kernel. Regards, Christian [1] https://www.debian.org/releases/stable/arm64/apbs05.html.en#preseed-hooks [2] Regarding only official ports: for ppc64el, you need to export QEMU_CPU=POWER8; on powerpc (32bit) some floating point instructions aren't properly emulated (it causes trouble with software compiled with -mpowerpc-gpopt); and the posix_fadvise() syscall is not mapped correctly on some 32bit platforms (armel, armhf, powerpc and mips; on mipsel it works though, funnily enough), but the aarch64 qemu-user port is in very good shape, from my experience.