scipy-notebook fails with standard_init_linux.go:207: exec user process caused "exec format error"

[1kastner]

What docker image you are using?

jupyter/scipy-notebook

What complete docker command do you run to launch the container (omitting sensitive values)?

docker run jupyter/scipy-notebook

What steps do you take once the container is running to reproduce the issue?

Only enter the command to the command line.

What do you expect to happen?

The docker image to start

What actually happens?

pi@raspberrypi:~/Documents/minimal-sample-jhub-exam $ docker run jupyter/scipy-notebook
standard_init_linux.go:207: exec user process caused "exec format error"

Additional Informaton
I installed docker on a RaspberryPi 3b with curl -sSL https://get.docker.com | sh as described at https://howchoo.com/g/nmrlzmq1ymn/how-to-install-docker-on-your-raspberry-pi

The RaspbeeryPi seems to have been detected as arm32v7 as it can be seen with the hello-world image, i.e.

pi@raspberrypi:~/Documents/minimal-sample-jhub-exam $ sudo docker run hello-world
Unable to find image 'hello-world:latest' locally
latest: Pulling from library/hello-world
c1eda109e4da: Pull complete 
Digest: sha256:2557e3c07ed1e38f26e389462d03ed943586f744621577a99efb77324b0fe535
Status: Downloaded newer image for hello-world:latest

Hello from Docker!
This message shows that your installation appears to be working correctly.

To generate this message, Docker took the following steps:
 1. The Docker client contacted the Docker daemon.
 2. The Docker daemon pulled the "hello-world" image from the Docker Hub.
    (arm32v7)
 3. The Docker daemon created a new container from that image which runs the
    executable that produces the output you are currently reading.
 4. The Docker daemon streamed that output to the Docker client, which sent it
    to your terminal.

To try something more ambitious, you can run an Ubuntu container with:
 $ docker run -it ubuntu bash

Share images, automate workflows, and more with a free Docker ID:
 https://hub.docker.com/

For more examples and ideas, visit:
 https://docs.docker.com/get-started/

[1kastner]

Following the argumentation of https://forums.docker.com/t/standard-init-linux-go-190-exec-user-process-caused-exec-format-error/49368/5 most likely it pulls a docker image with a wrong architecture.

According to https://stackoverflow.com/questions/52767983/docker-error-standard-init-linux-go185-exec-user-process-caused-exec-format-e?rq=1 it would need the image to be multi-arch.

At tiangolo/uwsgi-nginx-flask-docker#67 the solution was to explicitely build RaspberryPi images and store them separately on the hub.

Should there be arm-compatible images on docker? Should they be maintained together with all the other images which already exist?

[joshuacook]

@1kastner What would it take to build multi-architecture images? Would it effect the current images at all?

[1kastner]

At https://lobradov.github.io/Building-docker-multiarch-images/ a quick explanation is available.
Actually there is already a second supported architecture, namely PowerPC. How I came to that conclusion? At https://github.com/jupyter/docker-stacks/tree/master/base-notebook there is a second Dockerfile called Dockerfile.ppc64le. This is used in https://github.com/jupyter/docker-stacks/blob/master/Makefile in case the current architecture is a PowerPC.

In a similar manner I could create a new base image for other architectures. An example for RaspberryPi can be seen at https://github.com/Microsoft/onnxruntime/blob/master/dockerfiles/Dockerfile.arm32v7 and another explanation at how docker works internally with multi-arch docker images at dotnet/dotnet-docker#775 .
Yet it might be a question of style whether there should be several base image definitions (as it is currently the case) or whether some kind of templating should be used (see the first link).

If templating and cross-compilation with qemu is used as suggested in the first link, it would affect the whole pipeline and needs appropriate extensive testing beforehand. If, on the other hand, I just add another Dockerfile, namely Dockerfile.arm32v7, and define it as needed, then the current pipeline would not be affected. The consequence would be though that I need to clone the git repository and build the image on a computer with a matching architecture, e.g. under qemu. I don't think the RaspberryPi would easily do that job.

[1kastner]

Some more input can be taken from https://blog.hypriot.com/post/setup-simple-ci-pipeline-for-arm-images/

[parente]

We currently build x86 images on DockerHub. According to docker/hub-feedback#1261, it should be possible to configure DockerHub to build images for other architectures. I believe anyone can experiment with this setup in their own personal DockerHub account by forking this repo and setting up an automated build on the Hub like we recommend for community maintained stacks.

[zommuter]

The first problem lies here:

wget --quiet https://repo.continuum.io/miniconda/Miniconda3-${MINICONDA_VERSION}-Linux-x86_64.sh && \

Obviously the x86_64 version won't do. Unfortunately the latest armv7l release is 3.16.0 from 2015 😕

[1kastner]

At https://github.com/jjhelmus/berryconda somebody started a project to solve that.

[mathbunnyru]

We're tracking all the work on arm images in #1019 so this issue is a duplicate.
And you can already start using base and minimal images and build something on top of them!