Control: tag -1 + moreinfo
On Fri, 01 Oct 2021 17:30:16 +1000 Tim Connors <[email protected]> wrote:
Package: qemu-user-static
Version: 1:5.2+dfsg-11
Severity: normal
I noticed a /core file in the root directory, dated around about when
my machine was upgraded to bullseye. I checked another machine, and
it too had the same core file, dated from the upgrade:
24606,4> ls -lA /core
-rw------- 1 root root 11542528 Sep 15 00:41 core
0-0-16:27:43, Fri Oct 01 tconnors@fs:/snapshots/dirac/latest (bash)
24607,5> sudo file core
core: ELF 64-bit LSB core file, x86-64, version 1 (SYSV), SVR4-style, from
'/usr/libexec/qemu-binfmt/s390x-binfmt-P /check /check', real uid: 0, effective
uid: 0, real gid: 0, effective gid: 0, execfn: '/check', platform: 'x86_64'
Interesting. Do you by a chance also have /check binary?
This is apparently something checking for s390x availability,
so "not in use" is a bit interesting here in this context.
Neither binfmt-support nor systemd does that, and qemu-user-static
does not do this either.
It is interesting twice: the fact someone tried this s390x
abi, and the fact that qemu-s390-static (the binfmt-P is just
a symlink to it) crashed with a core dump. It was run as root
too (well, or else it wouldn't be able to create /core).
It'd be interesting to see the core file and especially the
/check binary.
Did it happen again since that? Can you reinstall qemu-user-static,
or upgrade it again (installing the buster version first) and see
if it triggers the issue again?
I have no idea what is going on there...
Thanks!
/mjt
