Your message dated Tue, 28 Oct 2025 05:40:51 -0400
with message-id <[email protected]>
and subject line Re: Bug#981509: docker.io: (Harmless) segfault on dockerd
startup
has caused the Debian Bug report #981509,
regarding docker.io: (Harmless) segfault on dockerd startup
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.)
--
981509: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=981509
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: docker.io
Version: 20.10.2+dfsg1-2
Severity: minor
X-Debbugs-Cc: [email protected]
Dear Maintainer,
* What led up to the situation?
On system startup, dockerd starts a container with a single
S/390 binary. Via binfmt this starts qemu-s390x-static with this
binary, and that segfaults:
kernel: check[2481]: segfault at 2346320 ip 000000000043afa0 sp
00007ffdb3fc62c8 error 4 in qemu-s390x-static[401000+2b0000]
I don't know what dockerd does on startup, but I assume
that it tries which architectures work.
If I run the qemu manually in my normal root fs, it simply returns:
/usr/bin/qemu-s390x-static check
This is probably the correct behaviour.
My suspicion is that this docker container doesn't mount /proc
correctly, but I haven't checked this.
This started with docker.io 20.10.1+dfsg1-1.
-- System Information:
Debian Release: bullseye/sid
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 5.10.0-2-amd64 (SMP w/4 CPU threads)
Locale: LANG=POSIX, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages docker.io depends on:
ii adduser 3.118
ii containerd 1.4.3~ds1-1+b1
ii init-system-helpers 1.60
ii iptables 1.8.7-1
ii libc6 2.31-9
ii libdevmapper1.02.1 2:1.02.175-2
ii libsystemd0 247.2-5
ii lsb-base 11.1.0
ii runc 1.0.0~rc92+dfsg1-5+b1
ii tini 0.19.0-1
Versions of packages docker.io recommends:
ii apparmor 2.13.6-7
ii ca-certificates 20210119
pn cgroupfs-mount <none>
ii git 1:2.30.0-1
pn needrestart <none>
ii xz-utils 5.2.5-1.0
Versions of packages docker.io suggests:
pn aufs-tools <none>
ii btrfs-progs 5.10-1
ii debootstrap 1.0.123
pn docker-doc <none>
ii e2fsprogs 1.45.7-1
pn rinse <none>
pn rootlesskit <none>
ii xfsprogs 5.10.0-2
pn zfs-fuse | zfsutils-linux <none>
-- no debconf information
--- End Message ---
--- Begin Message ---
Version: 26.1.4+dfsg1-1
On 2025-10-27 22:57, Detlef Vollmann wrote:
On 10/26/25 11:19, Reinhard Tartler wrote:
Detlef Vollmann <[email protected]> writes:
On system startup, dockerd starts a container with a single
S/390 binary. Via binfmt this starts qemu-s390x-static with this
binary, and that segfaults:
kernel: check[2481]: segfault at 2346320 ip 000000000043afa0 sp
00007ffdb3fc62c8 error 4 in qemu-s390x-static[401000+2b0000]
[...]
I know I'm late to the party. I don't observe that on current forky.
Are
you still seeing this? if yes, what needs to be done to trigger this
segfault?
I don't see this anymore.
However, it's a long time and it may be that back then I did something
to disable S/390 (as I really never needed it).
Any chance that some change in qemu has resovled this?
Maybe...
As I don't experience the bug anymore, you can close it [...]
Thank you for getting back to us on this.
Best,
-rt
--- End Message ---
