Hallo Bernhard,
Bernhard Übelacker <bernha...@mailbox.org> (2021-05-23):
> I did a little further investigation and found that it could be
> reproduced with just the following line, inside the arm64 chroot:
>
> for i in {1..100}; do echo $i; python3.9 -c "exit()"; done
>
> This produced 13 crashes for the 100 runs.
>
> But the crashes stop to appear when /proc is mounted inside the chroot.
>
> With the help of strace:amd64, rr:amd64 and a self-built
> qemu-aarch64-static I could locate the access [2] to /proc that, if
> failing, seem to cause the segfault.
>
> And the backtrace leads to this upstream change [1], which matches
> this bug and a qemu-aarch64-static built with this patch does not show
> the segfault anymore, when /proc is not available.
[…]
> [1]
> https://git.qemu.org/?p=qemu.git;a=commitdiff;h=0266e8e3b3981b492e82be20bb97e8ed9792ed00That's terrific investigation work, thanks! Before possibly proposing a fix via bullseye-proposed-updates, to be extra sure, I've built a minimal version of the raspi_3_buster.yaml recipe that's been failing for me on a regular manner (gut feeling was that is was basically a coin toss: 50% chance of broken build). It's attached to this mail in case someone's curious. The first run will do the qemu-debootstrap dance then cache the results, so that the following runs are only about untar-ing that cache and attempting to install the python3-minimal package. Looping over this test case, I'm hitting 46 errors on 100 attempts. I've imported the upstream commit via debian/patches, on top of the existing debian-bullseye branch, added a debian/changelog entry for the existing CVE fix plus the new patch, trying to mimick existing practices, and pushed the result to this branch: https://salsa.debian.org/kibi/qemu/-/tree/pu/debian-bullseye-bug-988174 Test-build done in cowbuilder, and runtime is now perfect: 100/100 builds are successful. Dear maintainers, I'm happy to check with the security team to see if they'd like to go through security for the CVE fix, and to check with the stable release managers to see if they're OK with a bullseye-proposed-updates upload in case an upload via security isn't warranted. I'll open a merge request as well, in case this makes tracking easier. Cheers, -- Cyril Brulebois (k...@debian.org) <https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant
# See https://wiki.debian.org/RaspberryPi3 for known issues and more details. steps: - mkimg: "{{ output }}" size: 1500M - mklabel: msdos device: "{{ output }}" - mkpart: primary fs-type: 'fat32' device: "{{ output }}" start: 4MiB end: 20% tag: /boot - mkpart: primary device: "{{ output }}" start: 20% end: 100% tag: / - kpartx: "{{ output }}" - mkfs: vfat partition: /boot label: RASPIFIRM - mkfs: ext4 partition: / label: RASPIROOT - mount: / - mount: /boot mount-on: / dirname: '/boot/firmware' - unpack-rootfs: / - qemu-debootstrap: buster mirror: http://deb.debian.org/debian target: / arch: arm64 components: - main - contrib - non-free unless: rootfs_unpacked - create-file: /etc/apt/sources.list contents: | deb http://deb.debian.org/debian buster main contrib non-free deb http://security.debian.org/debian-security buster/updates main contrib non-free # Backports are _not_ enabled by default. # Enable them by uncommenting the following line: # deb http://deb.debian.org/debian buster-backports main contrib non-free unless: rootfs_unpacked - cache-rootfs: / unless: rootfs_unpacked - apt: install packages: - python3-minimal tag: /
signature.asc
Description: PGP signature
