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