Segfault with qemu-aarch64-static doing debootstrap for debian bullseye but not buster
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
qemu (Ubuntu) |
Fix Released
|
Undecided
|
Unassigned | ||
Focal |
Confirmed
|
Undecided
|
Unassigned | ||
Groovy |
Won't Fix
|
Undecided
|
Unassigned | ||
Hirsute |
Fix Released
|
Undecided
|
Unassigned |
Bug Description
On 20.04 amd64 trying to build a Debian bullseye chroot using debootstrap we hit a segfault apparently calling /sbin/ldconfig ,,, but don't have the same issue building a Debian buster chroot.
Can't make out if this is problems with our older qemu or something in the bullseye compilation options or a bit of both.
Myself and a colleague have both hit this.
$ sudo qemu-debootstrap --arch=arm64 bullseye bullseye-arm64 http://
I: Running command: debootstrap --arch arm64 --foreign bullseye bullseye-arm64 http://
I: Retrieving InRelease
I: Checking Release signature
I: Valid Release signature (key id 0146DC6D4A0B291
I: Retrieving Packages
I: Validating Packages
I: Resolving dependencies of required packages...
I: Resolving dependencies of base packages...
I: Checking component main on http://
...
I: Extracting zlib1g...
I: Running command: chroot bullseye-arm64 /debootstrap/
W: Failure trying to run: /sbin/ldconfig
W: See //debootstrap/
$ tail bullseye-
2021-05-11 11:42:17 URL:http://
2021-05-11 11:42:20 URL:http://
2021-05-11 11:42:21 URL:http://
2021-05-11 11:42:22 URL:http://
2021-05-11 11:42:23 URL:http://
2021-05-11 11:42:23 URL:http://
2021-05-11 11:42:24 URL:http://
2021-05-11 11:42:24 URL:http://
qemu: uncaught target signal 11 (Segmentation fault) - core dumped
Segmentation fault (core dumped)
$ file bullseye-
bullseye-
$ apt list qemu-user-static
Listing... Done
qemu-user-
I've seen similar issues due to e.g. a newer glibc (could be any other program or even guest kernel) to use newer instructions and thereby trigger an issue that exists in the emulation.
This usually ends in the need to bisect the host to identify a (hopefully already existing) fix and then consider if it can be backported.
For a start I'd ask if you can reproduce the same on Hirsute with the newer qemu/kernel (those to are the most important components in this - an that is also the reasons why container based tests are not sufficient).
If the new code works then we need to find what fixed it, if the new code does not work we need to get you onto a super-recent kernel/qemu and if that also fails convert this to an upstream bug.
Could you do this initial "check newer versions" for this case?