Welcome! Log In Create A New Profile

Advanced

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

Posted by Kirsch 
(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 12:21PM by Kirsch.
My best guess is a problem with qemu. I can reproduce this problem. Unfortunately makes cross-building packages pretty much impossible.
Re: Build Debian-Stretch RootFS with qemu-arm-static: segmentation fault while "aptitude"
August 20, 2017 11:48PM
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
===========================
Wiki
latest Kirkwood kernel builds and rootfs
latest u-boot-kirkwood builds
latest Oxnas kernel builds and rootfs
latest u-boot-oxnas builds
latest MVEBU Armada kernel builds and rootfs
U-Boot & Kernel Booting process
bodhi's u-boot GitHub
bodhi's corner
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
Re: Build Debian-Stretch RootFS with qemu-arm-static: segmentation fault while "aptitude"
August 21, 2017 02:40AM
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
===========================
Wiki
latest Kirkwood kernel builds and rootfs
latest u-boot-kirkwood builds
latest Oxnas kernel builds and rootfs
latest u-boot-oxnas builds
latest MVEBU Armada kernel builds and rootfs
U-Boot & Kernel Booting process
bodhi's u-boot GitHub
bodhi's corner
> 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.
Re: Build Debian-Stretch RootFS with qemu-arm-static: segmentation fault while "aptitude"
August 22, 2017 02:38AM
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
===========================
Wiki
latest Kirkwood kernel builds and rootfs
latest u-boot-kirkwood builds
latest Oxnas kernel builds and rootfs
latest u-boot-oxnas builds
latest MVEBU Armada kernel builds and rootfs
U-Boot & Kernel Booting process
bodhi's u-boot GitHub
bodhi's corner
Author:

Your Email:


Subject:


Spam prevention:
Please, enter the code that you see below in the input field. This is for blocking bots that try to post this form automatically. If the code is hard to read, then just try to guess it right. If you enter the wrong code, a new image is created and you get another chance to enter it right.
Message: