Christian, Appreciate the response. I've never tried the the qemu-bootstrap, i'll definitely look into it. To be honest, this is mostly just my attempt to learn more about different architectures and QEMU. I've been writing up a script to set up VMs of different architectures without the hassle. So far MIPS has actually been pretty easy. For whatever reason the fully functioning AARCH64 requires those extra steps that are not necessarily easy to automate.
In any case, thanks for the heads up on the bootstrap+chroot route! Best, Mike On Sun, Jun 5, 2016 at 4:52 AM, Christian Seiler <christ...@iwakd.de> wrote: > 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. >
