Bug#707629: qemu-user-static: setting up mips chroot fails (regression)

[Edward J. Shornock]

Package: qemu-user-static
Version: 1.5.0~rc0+dfsg-1
Severity: normal

The second stage of debootstrap for mips on an AMD64 host fails thusly:

-----
I have no name!@darkside:/# debootstrap/debootstrap --second-stage
I: Installing core packages...
W: Failure trying to run: dpkg --force-depends --install /var/cache/apt/archives/libc6_2.13-38_mips.deb
W: See //debootstrap/debootstrap.log for details (possibly the package libc6:mips is at fault)
-----


The last few lines of debootstrap.log:


-----
Setting up dpkg (1.16.10) ...
Selecting previously unselected package libc6:mips.
(Reading database ... 371 files and directories currently installed.)
Unpacking libc6:mips (from .../libc6_2.13-38_mips.deb) ...
dpkg: libc6:mips: dependency problems, but configuring anyway as you requested:
libc6:mips depends on libc-bin (= 2.13-38); however:
Package libc-bin is not installed.
libc6:mips depends on libgcc1; however:
Package libgcc1 is not installed.

Setting up libc6:mips (2.13-38) ...
qemu: uncaught target signal 11 (Segmentation fault) - core dumped
dpkg: error processing libc6:mips (--install):
subprocess installed post-installation script was killed by signal (Segmentation fault)
Errors were encountered while processing:
libc6:mips
-----


In a Wheezy vm using qemu 1.1.2+dfsg-6a within virtualbox, setting up
the chroot completes successfully.


-- System Information:
Debian Release: 7.0
APT prefers testing
APT policy: (990, 'testing'), (500, 'stable'), (50, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.2.0-4-amd64 (SMP w/6 CPU cores)
Locale: LANG=fi_FI.UTF-8, LC_CTYPE=fi_FI.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

qemu-user-static depends on no packages.

Versions of packages qemu-user-static recommends:
ii binfmt-support 2.0.13

Versions of packages qemu-user-static suggests:
ii sudo 1.8.5p2-1+nmu1

-- no debconf information

[Michael Tokarev]

Control: tags -1 + confirmed upstream

09.05.2013 23:30, Edward J. Shornock wrote:
> Package: qemu-user-static
> Version: 1.5.0~rc0+dfsg-1
> Severity: normal
>
> The second stage of debootstrap for mips on an AMD64 host fails thusly:
>
> -----
> I have no name!@darkside:/# debootstrap/debootstrap --second-stage
> I: Installing core packages...
> W: Failure trying to run: dpkg --force-depends --install /var/cache/apt/archives/libc6_2.13-38_mips.deb
> W: See //debootstrap/debootstrap.log for details (possibly the package libc6:mips is at fault)
> -----
>
>
> The last few lines of debootstrap.log:
>
>
> -----
> Setting up dpkg (1.16.10) ...
> Selecting previously unselected package libc6:mips.
> (Reading database ... 371 files and directories currently installed.)
> Unpacking libc6:mips (from .../libc6_2.13-38_mips.deb) ...
> dpkg: libc6:mips: dependency problems, but configuring anyway as you requested:
> libc6:mips depends on libc-bin (= 2.13-38); however:
> Package libc-bin is not installed.
> libc6:mips depends on libgcc1; however:
> Package libgcc1 is not installed.
>
> Setting up libc6:mips (2.13-38) ...
> qemu: uncaught target signal 11 (Segmentation fault) - core dumped

This is a typical problem of running modern multi-threaded applications
which use clone(2) under qemu-user.

I can confirm this issue, and I can also confirm that it is not fixed
by 1.6-rc1.

Thanks,

/mjt


--
To UNSUBSCRIBE, email to debian-bugs-...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

[Michael Tokarev]

Control: retitle -1 perl does not work under qemu-user-static (so debconf and debootstrap fails)
Found: -1 1.1.2+dfsg-1

06.08.2013 12:48, Michael Tokarev wrote:
> 09.05.2013 23:30, Edward J. Shornock wrote:

>> Setting up libc6:mips (2.13-38) ...
>> qemu: uncaught target signal 11 (Segmentation fault) - core dumped

It is debconf invocation which fails. debconf uses perl and actually
any attempt to run perl inside chroot fails with the same error, in
a tcg-generated code where the "guest" tries to access a (guest) address
which don't actually belong to the process address space.

> In a Wheezy vm using qemu 1.1.2+dfsg-6a within virtualbox, setting up
> the chroot completes successfully.

I just tried wheezy version, -- it fails in exactly the same way in
exactly the same place.

So I don't see how this works for you and how this can be a reguression.

Retitling the bugreport.

[Edward J. Shornock]

* Michael Tokarev <m...@tls.msk.ru> [06-08-2013 13:21 EEST]:

> I just tried wheezy version, -- it fails in exactly the same way in
> exactly the same place.
>
> So I don't see how this works for you and how this can be a reguression.

Perhaps I just "lucked out" the time that it worked. In retrospect I
should have tried multiple times before claiming success with the wheezy
version. Maybe running within vbox made it act differently?

I can say that some of the tcg errors, such as the ones that can be
triggered when update-ca-certificates runs when emulating ARM, do not
fail consistently. Perhaps it's the same situation here?

Anyhow, sorry for the incorrect report.

[Michael Tokarev]

06.08.2013 18:39, Edward J. Shornock wrote:
> * Michael Tokarev <m...@tls.msk.ru> [06-08-2013 13:21 EEST]:
>> I just tried wheezy version, -- it fails in exactly the same way in
>> exactly the same place.
>>
>> So I don't see how this works for you and how this can be a reguression.
>
> Perhaps I just "lucked out" the time that it worked. In retrospect I
> should have tried multiple times before claiming success with the wheezy
> version. Maybe running within vbox made it act differently?

Might be. The current error is always reproducible, and has been
reproduced by qemu developers as well. Gdb confirms it fails at
exactly the same place in 1.1 version too, with similar instructions
(give or take slightly different code generated by 1.1 vs 1.6-tobe).

> I can say that some of the tcg errors, such as the ones that can be
> triggered when update-ca-certificates runs when emulating ARM, do not
> fail consistently. Perhaps it's the same situation here?

Does update-ca-certificates run any multi-threaded apps?

I'm still referring to multi-threaded apps issues. Which, on
a modern system, can happen with non-multithreaded apps too
just because of the way how these run other apps - using
clone() instead of fork() (which is what bash does!).
The issue is that multi-threaded emulation in qemu-user is
known broken, with multiple steps and patches needed to fix
different parts of it, and with time the situation becomes
worse because more and more "guest" userspace use new, broken
ways.

If that's the case and this ARM stuff fails due to this MT
issue, it should be a bit random, because there are many race
conditions in the code which are triggered when running in
MT mode, so sometimes you will hit these, and sometimes not.
It is almost NEVER happens when you pin the whole process
on host into a single CPU/core on host (running it with
taskset).

> Anyhow, sorry for the incorrect report.

It isn't incorrect, it's perfectly fine bugreport. And if your
version actually did not break on wheezy, that might point to
a diffrent issue or a reason where you were lucky not hitting
it. The bug is still there and can be reproduced by multiple
people.