On Tue, Feb 2, 2021 at 1:13 AM Shengjing Zhu <z...@debian.org> wrote: > > On Tue, Feb 2, 2021 at 12:49 AM Shengjing Zhu <z...@debian.org> wrote: > > > > Hi, > > > > On Tue, Feb 2, 2021 at 12:27 AM Detlef Vollmann <d...@vollmann.ch> wrote: > > > That's correct, you don't need to mount binfmt. > > > But you need to mount /proc. > > > qemu-s390x-static opens /proc/sys/vm/mmap_min_addr and I suspect > > > it segfaults because it can't open it. > > > I might be wrong, but then I don't know why it segfaults > > > inside the container but not outside. > > > > > > > However it seems it does work. > > > > $ docker run --rm -it --platform s390x debian:buster-slim sh -c 'ldd > > /bin/sh' > > libc.so.6 => /lib/s390x-linux-gnu/libc.so.6 (0x0000004001852000) > > /lib/ld64.so.1 (0x0000004000000000) > > > > Anyway in container /proc is mounted, > > > > $ docker run --rm -it --platform s390x debian:buster-slim sh -c 'cat > > /proc/sys/vm/mmap_min_addr' > > 65536 > > > > > >> BTW, I'm still not really clear why dockerd starts an S/390 > > > >> binary at all. It doesn't do that for any other (foreign) > > > >> architecture. > > > > > > > > I think it's the script in the image. Especially what is the `check` > > > > binary? Who calls it? > > > > If your image doesn't have that, then maybe you have some custom hooks > > > > on the host. > > > No. Sorry if my bug report was not clear about this. > > > I don't have any docker images to start at system boot. > > > And I have no S/390 binaries. > > > But I saw the segfault in my boot log and was interested > > > who causes this. > > > The way I tracked it down was by replacing the qemu-s390x-static > > > with my own binary that just did a sleep, so that after boot I > > > could login and find and examine the process. > > > And the root of this process only contains a single file 'check'. > > > dockerd starts it completely on its own. > > > My suspicion was that it wants to find out whether the host > > > can handle S/390 binaries at all. > > > > > > > It's interesting, could you share the process tree? > > I really have now idea why docker will start a process called check, > > if it's not in a container. > > > > apt-file search check|grep -E '/check$' > > > > I also don't find any file named 'check' related to docker, or > > container, or qemu. > > > > It's magic, and I finally find where the 'check' binary comes from... > > The binary is hardcoded here, > https://github.com/moby/moby/blob/3e0025e2fc137f51e95758618e1b42627fe6ea1c/vendor/github.com/moby/buildkit/util/archutil/s390x_binary.go#L8 > > Then it's created on fly and executed. > https://github.com/moby/moby/blob/3e0025e2fc137f51e95758618e1b42627fe6ea1c/vendor/github.com/moby/buildkit/util/archutil/check_unix.go#L22 >
This part of code is from buildkit. Since I doesn't enable it by default in my env, so I haven't notice this segfault. After enable buildkit in /etc/docker/daemon.json, and restart docker, I can reproduce this segfault. -- Shengjing Zhu
