Your message dated Mon, 11 Aug 2025 11:45:45 +0300
with message-id <[email protected]>
and subject line Re: Bug#988655: qemu-user-static: qemu-sparc64-static often
coredumps running a sid chroot
has caused the Debian Bug report #988655,
regarding qemu-user-static: qemu-sparc64-static often coredumps running a sid
chroot
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 [email protected]
immediately.)
--
988655: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=988655
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: qemu-user-static
Version: 1:5.2+dfsg-9~bpo10+1
Severity: normal
Dear Maintainer,
I am trying to debug an issue with an external kernel module on sparc64, so I
wanted
to rebuild said module faster than my poor (real) UltraSPARC IIi would permit.
For
bisecting reasons on another problem, I needed to try a kernel from the past,
so I
debootstrapped (from the real SPARC) a chroot environment over NFSv4 pointed at
https://snapshot.debian.org/archive/debian-ports/20180331T141542Z.
So I bootstrapped that, verified that it worked by chrooting in from the SPARC
and
installing the various development packages I needed, everything worked fine,
then
I thought I'd try qemu-sparc64-static to build on my much faster server.
I was already running qemu-user-static from buster-backports, so I thought this
would
likely work well.
Instead, during ./autogen.sh, I got back several "Assertion failure (core
dumped)",
and the compile did not continue. (This does not happen on native hardware.)
I also tried and observed the same behavior on the qemu-user-static from
experimental,
albeit in a bullseye VM because it didn't install particularly readily on
buster.
Please LMK if I can do anything to be helpful in further investigating this.
- Rich
-- System Information:
Debian Release: 10.9
APT prefers stable
APT policy: (1000, 'stable'), (900, 'testing-debug'), (900, 'testing'), (800,
'unstable-debug'), (800, 'unstable'), (500, 'stable-updates'), (500,
'stable-debug'), (500, 'proposed-updates-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.19.0-16-amd64 (SMP w/16 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE,
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
qemu-user-static depends on no packages.
Versions of packages qemu-user-static recommends:
ii binfmt-support 2.2.0-2
Versions of packages qemu-user-static suggests:
ii sudo 1.8.27-1+deb10u3
-- no debconf information
--- End Message ---
--- Begin Message ---
Version: 1:7.2+dfsg-1
On Mon, 17 May 2021 08:18:30 -0400 Rich Ercolani <[email protected]>
wrote:
Package: qemu-user-static
Version: 1:5.2+dfsg-9~bpo10+1
Severity: normal
Dear Maintainer,
I am trying to debug an issue with an external kernel module on sparc64, so I
wanted
to rebuild said module faster than my poor (real) UltraSPARC IIi would permit.
For
bisecting reasons on another problem, I needed to try a kernel from the past,
so I
debootstrapped (from the real SPARC) a chroot environment over NFSv4 pointed at
https://snapshot.debian.org/archive/debian-ports/20180331T141542Z.
So I bootstrapped that, verified that it worked by chrooting in from the SPARC
and
installing the various development packages I needed, everything worked fine,
then
I thought I'd try qemu-sparc64-static to build on my much faster server.
I was already running qemu-user-static from buster-backports, so I thought this
would
likely work well.
Instead, during ./autogen.sh, I got back several "Assertion failure (core
dumped)",
and the compile did not continue. (This does not happen on native hardware.)
I also tried and observed the same behavior on the qemu-user-static from
experimental,
albeit in a bullseye VM because it didn't install particularly readily on
buster.
It looks like the issue has been fixed quite some time ago, - at least I
can't reproduce it on bookworm (qemu version 7.2).
Closing this bug report now. Please feel free to reopen it if you think
it is incorrect and the problem is still present.
Thanks,
/mjt
--- End Message ---
