Re: aarch64 qemu workaround

[Mike]

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  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.
>

Re: aarch64 qemu workaround

[Christian Seiler]

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.

aarch64 qemu workaround

[Mike]

Folks,

I've been having a terrible time attempting to get debian to install into a
qemu aarch64 environment. It appears that this is an issue that has been
around for some time, though the only information I can find on it seems
dated.

https://gmplib.org/~tege/qemu.html

Scrolling down to the aarch64 section describes the situation. Has this
gotten any better? Is there a better workaround? I was hoping to be able to
automate this, but that's a pretty nasty hack just to get Debian up and
running.

Best,

Mike