Your message dated Sun, 14 Feb 2021 02:24:56 +0100
with message-id <debfde49a9c012de754284cbec4b065ebec2e4d5.ca...@ginger.ws>
and subject line Re: Bug#982422: debootstrap: segmentation fault around
ldconfig during debootstrapping bullseye/arm64 on a buster/amd64 host
has caused the Debian Bug report #982422,
regarding debootstrap: segmentation fault around ldconfig during
debootstrapping bullseye/arm64 on a buster/amd64 host
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)
--
982422: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=982422
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: debootstrap
Version: 1.0.114
Severity: normal
I'm struggling with a problem that I currently have with debootstrapping an
arm64 system on my amd64 machine. The attached script can reproduce the issue
here.
It crashes here on a debian buster amd64, in the 2nd debootstrap stage:
...
W: Failure trying to run: /sbin/ldconfig
W: See //debootstrap/debootstrap.log for details
...
2021-02-10 01:05:52 URL:http://deb.debian.org/debian/pool/main/x/xz-
utils/liblzma5_5.2.5-1.0_arm64.deb [164436/164436] ->
"/...//var/cache/apt/archives/partial/liblzma5_5.2.5-1.0_arm64.deb" [1]
2021-02-10 01:05:52
URL:http://deb.debian.org/debian/pool/main/z/zlib/zlib1g_1.2.11.dfsg-2_arm64.deb
[87944/87944] ->
"/...//var/cache/apt/archives/partial/zlib1g_1%3a1.2.11.dfsg-2_arm64.deb" [1]
qemu: uncaught target signal 11 (Segmentation fault) - core dumped
It works if I debootstrap a buster system instead. Then trying to upgrade to
bullseye in the same chroot crashes with a segfault during the upgrade of libc-
bin. It also segfaults when I just open a chrooted shell after the 1st stage
and then run "ldconfig". That worked here around new year, but then broke.
This looks like a software bug somewhere. I'm not sure if I'm right here. But
maybe you can tell me.
#!/bin/bash
set -e
LOOPFILE=removemelater.loopfile
INNERROOT=removemelater.loopmnt
LOOPDEV=/dev/loop5
reproduce() {
dd if=/dev/zero of=$LOOPFILE bs=1M count=2048
losetup $LOOPDEV $LOOPFILE
mkfs.ext4 $LOOPDEV
mkdir $INNERROOT
mount $LOOPDEV $INNERROOT
debootstrap --arch=arm64 --foreign bullseye $INNERROOT
mount -o bind /sys $INNERROOT/sys
mount -o bind /dev $INNERROOT/dev
mount -o bind /dev/pts $INNERROOT/dev/pts
mount -o bind /proc $INNERROOT/proc
chroot $INNERROOT /bin/bash -c "/debootstrap/debootstrap --second-stage"
}
reproduce || cat $INNERROOT/debootstrap/debootstrap.log
--- End Message ---
--- Begin Message ---
Fixed by buster-backports.
--- End Message ---
