Build Debian-Stretch RootFS with qemu-arm-static: segmentation fault while "aptitude"

(HOST: Kubunu 17.04 64Bit)

Im trying to bulid a new Debian RootFS for a ARM-Device

Stage 1 and 2 of debootstrap works fine.

When i enter chroot from new RootFS
and run "aptitude"
i get a segmentation fault.

Same steps with jessie as target OS works fine.

"armel" or "armhf" maks no diffrents.

Bug in ARM-Version from aptitude, or problem with qemu?



Edited 1 time(s). Last edit at 07/23/2017 01:21PM by Kirsch.

My best guess is a problem with qemu. I can reproduce this problem. Unfortunately makes cross-building packages pretty much impossible.

All,

Are you having this qemu problem on armv7, as in this thread: http://forum.doozan.com/read.php?2,32146? I have not released a Debian stretch rootfs for it.

Or are you having problem on armv5, as in this thread: http://forum.doozan.com/read.php?2,12096? I have released a Debian stretch rootfs (Debian-4.12.1-kirkwood-tld-1-rootfs-bodhi.tar.bz2).

Have you tried chroot into either of the rootfs above to see if you have same problem?

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

Since we're both using qemu-arm-static, the host OS is likely using x86 or x86_64. Latter one for me.

I'm not using any ARM machine directly, but cross-building armhf packages on an x86_64 machine via Qemu's user mode emulation.

The issue is easily reproducible, hence I created a bug report upstream: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=872771

Ionic,

> Since we're both using qemu-arm-static, the host O
> S is likely using x86 or x86_64. Latter one for me
> .
>
> I'm not using any ARM machine directly, but cross-
> building armhf packages on an x86_64 machine via Q
> emu's user mode emulation.

Understood! what I was wondering what happen if we use my armv5 stretch rootfs, install qemu-arm-static on it. Would the error still occur when you chroot into it and run apt-get or compiling some packages.

I did not install qemu-arm-static on Debian-4.12.1-kirkwood-tld-1-rootfs-bodhi.tar.bz2, because it was built on ARM.

Quote

Or are you having problem on armv5, as in this thread: http://forum.doozan.com/read.php?2,12096? I have released a Debian stretch rootfs (Debian-4.12.1-kirkwood-tld-1-rootfs-bodhi.tar.bz2).

And,

I've installed qemu-arm-static in the MVEBU armhf rootfs, because I used x86_64 to build it. But it is a jessie rootfs.

Quote

Are you having this qemu problem on armv7, as in this thread: http://forum.doozan.com/read.php?2,32146? I have not released a Debian stretch rootfs for it.

I could upgrade the amrhf rootfs to stretch, and chroot into it to confirm the problem one more time for you both. Perhaps I will do that, to see if it helps to have one more data point, one way or the other.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

> what I was wondering what happen if we use my armv5 stretch rootfs, install qemu-arm-static on it. Would the error still occur when you chroot into it and run apt-get or compiling some packages.

Probably not, but I don't have a way to check that. There's nothing you could do about that situation, it's up for Debian/Qemu to fix the user mode emulation.

Essentially, you have to install the host-arch (e.g., x86_64) qemu-arm-static binary from the host-arch qemu-user-static package into the chroot. After that, ARM binaries can be executed as if they were native host-arch binaries (through some kernel magic via binfmt_misc.)

If I were to install qemu-user-static in the chroot as the target-arch version (e.g., armhf), nothing would be working any longer.

You already know that, though, since you've build rootfs' via this method. :)

User mode emulation has always been and still is a bit flaky.


My workaround so far has been to instruct sbuild to use apt-get instead of aptitude and to allow alternatives in build dependencies. All my packages built successfully this way. It might well be possible that stretch's qemu-user-static is causing more trouble than jessie's, though.

Be careful when upgrading.

So, just to confirm:

Quote

Or are you having problem on armv5, as in this thread: http://forum.doozan.com/read.php?2,12096? I have released a Debian stretch rootfs (Debian-4.12.1-kirkwood-tld-1-rootfs-bodhi.tar.bz2).

Downloaded, put /usr/bin/qemu-arm-static into its usr/bin directory, installed aptitude, ran aptitude update => segfault.

(There were additional error messages before the segfault, but these stem from /run/lock not existing on your rootfs. aptitude tried to create /var/lock/aptitude, which failed. /var/lock is a symlink to /run/lock, but /run/lock does not exist. No big deal, I guess, since such directories might be created by something (systemd?) during a "real" boot process.)

Quote

Are you having this qemu problem on armv7, as in this thread: http://forum.doozan.com/read.php?2,32146? I have not released a Debian stretch rootfs for it.

Downloaded Debian-4.9.0-mvebu-tld-12-rootfs-bodhi.tar.bz2, extracted it, ran the usual commands. aptitude worked fine.


Now, this said: my personal day-to-day system is a Gentoo x86_64 one. Gentoo currently has Qemu 2.9.0 available, so I'm inclined to test a stretch-based chroot with that.

And as far as qemu 2.9.0 is concerned:

qemu:handle_cpu_signal received signal outside vCPU context @ pc=0x6015043b
qemu:handle_cpu_signal received signal outside vCPU context @ pc=0x6016c6b9
[1]    3606 segmentation fault (core dumped)  chroot . aptitude update

Haven't seen the qemu:handle_cpu_signal messages with Debian's 2.8.0 version, but same result in the end.

I'll probably wait for 2.10.0 to be available and will test again with that.

Ionic,

Thanks for testing and confirming both rootfs.

Quote

/run/lock does not exist. No big deal, I guess, since such directories might be created by something (systemd?) during a "real" boot process.)

Indeed, it is created when the real system is booting.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)