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 -- Shengjing Zhu
