Container did not run after performing docker compose up - Verdin imx8m-mini

V_D_ALMEIDA · July 5, 2022, 11:24pm

Hello Everyone !

I have two containers which are working very well while executing in my host pc.

Is a node.js application, a server that listen in the port 3000.
Is a static html page which communicates with a javascript program and access the routes of the server that runs in node.js (Container 1).

I read the documentation, and to perform this I need to creat a docker compose, I created it, but it failed with the following erros:

weston_1 | NXP EULA has already been accepted.
ihmestufateste1 | standard_init_linux.go:211: exec user process caused “exec format error”
nodeestufateste1 | standard_init_linux.go:211: exec user process caused “exec format error”
weston_1 | SoC is: ‘i.MX8MM’
weston_1 | SoC has GPU: true
weston_1 | SoC has DPU: false
weston_1 | g2d implementation: viv
weston_1 | Removing previously created ‘.X*-lock’ entries under /tmp before starting Weston. Pass ‘IGNORE_X_LOCKS=1’ environment variable to Weston container to disable this behavior.
ihmestufateste1 exited with code 1
weston_1 | dos2unix: converting file /etc/xdg/weston/weston.ini to Unix format…
weston_1 | dos2unix: converting file /etc/xdg/weston-dev/weston.ini to Unix format…
nodeestufateste1 exited with code 1
weston_1 | Switching VT mode of /dev/tty7 to text
weston_1 | openvt: Unable to open file: /dev/tty7: Operation not permitted
estufateste_weston_1 exited with code 5

Have you faced this kind of issue before ? I’m trying to construct a docker-compose in order to run the containers in toradex.

docker-compose.override.arm64.yml
version: "2.4"
services:

  weston:
    image: torizon/weston-vivante:2
    # Accept the EULA required to run imx8 vivante graphic drivers
    environment:
     - ACCEPT_FSL_EULA=1
    # Required to get udev events from host udevd via netlink
    network_mode: host
    volumes:
      - type: bind
        source: /tmp
        target: /tmp
      - type: bind
        source: /dev
        target: /dev
      - type: bind
        source: /run/udev
        target: /run/udev
    cap_add:
      - CAP_SYS_TTY_CONFIG
    # Add device access rights through cgroup...
    device_cgroup_rules:
      # ... for tty0
      - 'c 4:0 rmw'
      # ... for tty7
      - 'c 4:7 rmw'
      # ... for /dev/input devices
      - 'c 13:* rmw'
      - 'c 199:* rmw'
      # ... for /dev/dri devices
      - 'c 226:* rmw'
    command: --developer weston-launch --tty=/dev/tty7 --user=torizon


  kiosk:
    image: torizon/kiosk-mode-browser:2
    security_opt:
      - seccomp:unconfined
    command: --browser-mode http://localhost/index.html
    shm_size: '256mb'
    device_cgroup_rules:
      # ... for /dev/dri devices
      - 'c 226:* rmw'
    volumes:
      - type: bind
        source: /tmp
        target: /tmp
      - type: bind
        source: /var/run/dbus
        target: /var/run/dbus
      - type: bind
        source: /dev/dri
        target: /dev/dri
    depends_on:
       - weston
       - ihmestufateste1
       - nodeestufateste1
 
docker-compose.yml
version: "2.4"
services:
  ihmestufateste1:
    container_name: ihmestufateste1
    networks:
      - backend
      - frontend
    ports:
      - "80:80"
    image: vdalmeida/ihmestufa

  nodeestufateste1:
    container_name: nodeestufateste1
    networks:
      - backend
    ports:
      - "3000:3000"
    image: vdalmeida/nodeestufa


networks:
  backend:
    internal: true
  frontend:
    internal: false

lucas_a.tx · July 6, 2022, 1:57pm

Hi @V_D_ALMEIDA ,

ihmestufateste1 | standard_init_linux.go:211: exec user process caused “exec format error”
nodeestufateste1 | standard_init_linux.go:211: exec user process caused “exec format error”

This error usually indicates that you’re trying to execute a program intended for a different computer architecture found in the module: Given that your containers ran fine on your host PC they were created for x64 machines, and will not run on Arm64 devices, like the Verdin iMX8M Mini you’re using.

You need to edit the Dockerfile for these containers to explicitly create images made for Arm64 architecture. To do this you need to change the FROM line in your Dockerfile to be something similar to this:

FROM --platform=linux/arm64/v8 debian:bullseye-slim

The relevant part is --platform=linux/arm64/v8. You don’t need to use debian:bullseye-slim if you are already using something else.

After doing this enable ARM emulation on your host as described here: Configure Build Environment for Torizon Containers | Toradex Developer Center then just run docker build as you did before.

As for the tty7 permission error, that seems odd. In the module, what is the output of ls -l /dev/tty7?

Best regards,
Lucas Akira

V_D_ALMEIDA · July 6, 2022, 3:03pm

Lucas, I’ve tried to modify as it follows bellow via Torizon OTA, but the update failed.

version: “2.4”
services:

weston:
image: torizon/weston-vivante:2

Accept the EULA required to run imx8 vivante graphic drivers

environment:

ACCEPT_FSL_EULA=1

Required to get udev events from host udevd via netlink

network_mode: host
volumes:

type: bind
source: /tmp
target: /tmp
type: bind
source: /dev
target: /dev
type: bind
source: /run/udev
target: /run/udev
cap_add:
CAP_SYS_TTY_CONFIG

Add device access rights through cgroup…

device_cgroup_rules:

… for tty0

‘c 4:0 rmw’

… for tty7

‘c 4:7 rmw’

… for /dev/input devices

‘c 13:* rmw’
‘c 199:* rmw’

… for /dev/dri devices

‘c 226:* rmw’
command: --developer weston-launch --tty=/dev/tty7 --user=torizon
healthcheck:
test: [“CMD”, “test”, “-S”, “/tmp/.X11-unix/X0”]
interval: 5s
timeout: 4s
retries: 6
start_period: 10s

kiosk:
image: torizon/kiosk-mode-browser:2
security_opt:

seccomp:unconfined
command: --browser-mode http://localhost/index.html:80
shm_size: ‘256mb’
device_cgroup_rules:

… for /dev/dri devices

‘c 226:* rmw’
volumes:
type: bind
source: /tmp
target: /tmp
type: bind
source: /var/run/dbus
target: /var/run/dbus
type: bind
source: /dev/dri
target: /dev/dri
depends_on:
ihmestufateste1
nodeestufateste1
weston:
condition: service_healthy

ihmestufateste1:
container_name: ihmestufateste1
platform: linux/arm64 torizon/debian:2-bullseye
networks:

backend
frontend
ports:
“80:80”
image: vdalmeida/ihmestufa

nodeestufateste1:
container_name: nodeestufateste1
platform: linux/arm64 torizon/debian:2-bullseye
networks:

backend
ports:
“3000:3000”
image: vdalmeida/nodeestufa

networks:
backend:
internal: true
frontend:
internal: false

lucas_a.tx · July 6, 2022, 4:29pm

You added the platform parameter in the docker-compose.yml, but you should instead change the Dockerfile that created your images, like nodeestufa and ihmestufa.

For instance, in another topic you posted one Dockerfile that you created. Change it like this:

HTML application

FROM --platform=linux/arm64/v8 nginx

LABEL version=“1.0.0” description=“Teste Linux-Toradex” maintainer=“Victor Davi Almeida victor.davi@hotmail.com”

RUN cd / && mkdir Arquivos && chmod 777 -R Arquivos/

COPY . /usr/share/nginx/html/

VOLUME /Arquivos/

EXPOSE 80

ENV API_URL=http://localhost:8000/api/
ENV API_BANCO=meu_site

WORKDIR /usr/share/nginx/html/

ENTRYPOINT [“/usr/sbin/nginx”]
CMD [“-g”, “daemon off;”]

Node.js Application

FROM node:16.15.1

RUN mkdir -p /usr/src/app

WORKDIR /usr/src/app

COPY package.json /usr/src/app/

RUN npm install

COPY . /usr/src/app

EXPOSE 3000

CMD [ “npm”, “start” ]

After that enable ARM emulation as I said in my previous reply, use docker build to rebuild your image (if you want, use another tag like vdalmeida/ihmestufa:arm64) then push it to your docker hub. If you used another tag update that in your docker-compose.yml (like image: vdalmeida/ihmestufa:arm64).

V_D_ALMEIDA · July 6, 2022, 5:14pm

Lucas,

How could I create a docker compose in order to deploy these two modified container to arm64 with Weston and Kiosk ?

V_D_ALMEIDA · July 6, 2022, 5:19pm

One thing I’m wondering, I just need to change the HTML DockerFile with the FROM … ? Should I change the Node.js too ?

lucas_a.tx · July 6, 2022, 7:01pm

The first docker-compose.yml that you posted here seemed pretty much correct to me and it should work after you rebuild your images to be Arm64 and push them to your docker hub.

Yes, you should change both of your images to be Arm64. Try that and see how it goes.

Best regards,
Lucas Akira

V_D_ALMEIDA · July 6, 2022, 7:31pm

Lucas, Do you provide some consult service in order to help me deploy my containers into Verdin ?

Yes, you should change both of your images to be Arm64. Try that and see how it goes.

Do I need to change the platform in DockerCompose too ?

The first docker-compose.yml that you posted here seemed pretty much correct to me and it should work after you rebuild your images to be Arm64 and push them to your docker hub.

Lucas, Do you mean the docker compose below ?

version: “2.4”

services:

weston:
image: torizon/weston-vivante:2

Accept the EULA required to run imx8 vivante graphic drivers

environment:

ACCEPT_FSL_EULA=1

Required to get udev events from host udevd via netlink

network_mode: host
volumes:

type: bind
source: /tmp
target: /tmp
type: bind
source: /dev
target: /dev
type: bind
source: /run/udev
target: /run/udev
cap_add:
CAP_SYS_TTY_CONFIG

Add device access rights through cgroup…

device_cgroup_rules:

… for tty0

‘c 4:0 rmw’

… for tty7

‘c 4:7 rmw’

… for /dev/input devices

‘c 13:* rmw’
‘c 199:* rmw’

… for /dev/dri devices

‘c 226:* rmw’
command: --developer weston-launch --tty=/dev/tty7 --user=torizon
healthcheck:
test: [“CMD”, “test”, “-S”, “/tmp/.X11-unix/X0”]
interval: 5s
timeout: 4s
retries: 6
start_period: 10s

kiosk:
image: torizon/kiosk-mode-browser:2
security_opt:

seccomp:unconfined
command: --browser-mode http://localhost/index.html:80
shm_size: ‘256mb’
device_cgroup_rules:

… for /dev/dri devices

‘c 226:* rmw’
volumes:
type: bind
source: /tmp
target: /tmp
type: bind
source: /var/run/dbus
target: /var/run/dbus
type: bind
source: /dev/dri
target: /dev/dri
depends_on:
ihmestufateste1
nodeestufateste1
weston:
condition: service_healthy

ihmestufateste1:
container_name: ihmestufateste1
platform: linux/arm64 torizon/debian:2-bullseye
networks:

backend
frontend
ports:
“80:80”
image: vdalmeida/ihmestufa

nodeestufateste1:
container_name: nodeestufateste1
platform: linux/arm64 torizon/debian:2-bullseye
networks:

backend
ports:
“3000:3000”
image: vdalmeida/nodeestufa

networks:
backend:
internal: true
frontend:
internal: false

V_D_ALMEIDA · July 6, 2022, 8:01pm

I’ve tried to run only the the image created by the DockerFile from HTML application, which I’ve modified as showned below:

FROM --platform=linux/arm64/v8 nginx

LABEL version=“1.0.0” description=“Teste ARM Linux-Toradex” maintainer=“Victor Davi Almeida victor.davi@hotmail.com”

RUN cd / && mkdir Arquivos && chmod 777 -R Arquivos/

COPY . /usr/share/nginx/html/

VOLUME /Arquivos/

EXPOSE 80

ENV API_URL=http://localhost:8000/api/
ENV API_BANCO=meu_site

WORKDIR /usr/share/nginx/html/

ENTRYPOINT [“/usr/sbin/nginx”]
CMD [“-g”, “daemon off;”]

But I still get the same error

V_D_ALMEIDA · July 6, 2022, 8:33pm

Lucas,

I’ve followed the steps

Edited the DockerFile from the HTML application
Configured the Build Enrironment for Torizon Containers
Build the new image
Only ran the image of the HTML application
As result it didn’t show the error as before.

Although when I tried to create the DockerCompose and upload it using Torizon OTA the update failed.

Host PC Steps 2

Use ‘docker scan’ to run Snyk tests against images to find vulnerabilities and learn how to fix them
PS C:\Users\Lucas\OneDrive - IGT Tecnologia\Área de Trabalho\Documentos Victor\Estufa - Edição (V2 C-Emergencia)\HMI-Projeto-Hidroponia - v2> docker run --rm -it --privileged torizon/binfmt
PS C:\Users\Lucas\OneDrive - IGT Tecnologia\Área de Trabalho\Documentos Victor\Estufa - Edição (V2 C-Emergencia)\HMI-Projeto-Hidroponia - v2> docker run --rm -it arm64v8/debian arch
WARNING: The requested image’s platform (linux/arm64/v8) does not match the detected host platform (linux/amd64) and no specific platform was requested
aarch64
Host PC Steps 3

PS C:\Users\Lucas\OneDrive - IGT Tecnologia\Área de Trabalho\Documentos Victor\Estufa - Edição (V2 C-Emergencia)\HMI-Projeto-Hidroponia - v2> docker build --pull -t vdalmeida/arm64estufateste1 .
Sending build context to Docker daemon 330.2kB
Step 1/11 : FROM --platform=linux/arm64/v8 nginx
latest: Pulling from library/nginx
Digest: sha256:10f14ffa93f8dedf1057897b745e5ac72ac5655c299dade0aa434c71557697ea
Status: Image is up to date for nginx:latest
—> cd4e03b35a8e
Step 2/11 : LABEL version=“1.0.0” description=“Teste ARM Linux-Toradex” maintainer=“Victor Davi Almeida victor.davi@hotmail.com”
—> Using cache
—> f0b7322bfc9a
Step 3/11 : RUN cd / && mkdir Arquivos && chmod 777 -R Arquivos/
—> Using cache
—> 9b71f2032be0
Step 4/11 : COPY . /usr/share/nginx/html/
—> Using cache
—> 5b5d36f42fbc
Step 5/11 : VOLUME /Arquivos/
—> Using cache
—> 409acf372233
Step 6/11 : EXPOSE 80
—> Using cache
—> a767529c0b1f
Step 7/11 : ENV API_URL=http://localhost:8000/api/
—> Using cache
—> b17128ebb35a
Step 8/11 : ENV API_BANCO=meu_site
—> Using cache
—> bea04ee5a22f
Step 9/11 : WORKDIR /usr/share/nginx/html/
—> Using cache
—> 4dd37996da12
Step 10/11 : ENTRYPOINT [“/usr/sbin/nginx”]
—> Using cache
—> 8b13a3331cc1
Step 11/11 : CMD [“-g”, “daemon off;”]
—> Using cache
—> 406b08a1d53c
Successfully built 406b08a1d53c
Successfully tagged vdalmeida/arm64estufateste1:latest
SECURITY WARNING: You are building a Docker image from Windows against a non-Windows Docker host. All files and directories added to build context will have ‘-rwxr-xr-x’ permissions. It is recommended to double check and reset permissions for sensitive files and directories.

Verdin mini step 4

verdin-imx8mm-06827717:~$ docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
verdin-imx8mm-06827717:~$ docker pull vdalmeida/arm64estufateste1
Using default tag: latest
latest: Pulling from vdalmeida/arm64estufateste1
3b157c852f27: Pull complete
b0badd78900d: Pull complete
7cea0199de6e: Pull complete
1574e1772b11: Pull complete
09af57e2ac73: Pull complete
61db1e71029d: Pull complete
a9389d55e981: Pull complete
c8422525989b: Pull complete
Digest: sha256:87a84a8da3e865778c27687345e5089ad6839a5d8f9ad7d8591d2ba5dcbdc6ba

Results
Status: Downloaded newer image for vdalmeida/arm64estufateste1:latest
docker.io/vdalmeida/arm64estufateste1:latest
verdin-imx8mm-06827717:~$ docker run --rm -it -v /var/run/dbus:/var/run/dbus -v /dev:/dev vdalmeida/arm64estufateste1
2022/07/06 20:15:27 [notice] 1#1: using the “epoll” event method
2022/07/06 20:15:27 [notice] 1#1: nginx/1.23.0
2022/07/06 20:15:27 [notice] 1#1: built by gcc 10.2.1 20210110 (Debian 10.2.1-6)
2022/07/06 20:15:27 [notice] 1#1: OS: Linux 5.4.161-5.6.0+git.0f0011824921
2022/07/06 20:15:27 [notice] 1#1: getrlimit(RLIMIT_NOFILE): 1048576:1048576
2022/07/06 20:15:27 [notice] 1#1: start worker processes
2022/07/06 20:15:27 [notice] 1#1: start worker process 6
2022/07/06 20:15:27 [notice] 1#1: start worker process 7
2022/07/06 20:15:27 [notice] 1#1: start worker process 8
2022/07/06 20:15:27 [notice] 1#1: start worker process 9
2022/07/06 20:15:27 [notice] 1#1: signal 28 (SIGWINCH) received
2022/07/06 20:15:27 [notice] 7#7: signal 28 (SIGWINCH) received
2022/07/06 20:15:27 [notice] 8#8: signal 28 (SIGWINCH) received
2022/07/06 20:15:27 [notice] 9#9: signal 28 (SIGWINCH) received
2022/07/06 20:15:27 [notice] 6#6: signal 28 (SIGWINCH) received

lucas_a.tx · July 7, 2022, 12:42pm

Yes, but you can keep the platform parameter in the docker-compose.yml, it shouldn’t be a problem.

Docker Compose just tries to run all containers as described in docker-compose.yml. It’s equivalent to executing docker run for each image. So if one of the containers doesn’t work docker-compose up will not work either, hence the OTA update will fail. You need to get every container to run correctly before trying to do an OTA update.

The FROM --platform=linux/arm64/v8 nginx line from the Dockerfile you showed is correct. The reason it didn’t work is due to a bug in docker run: https://github.com/docker/for-linux/issues/1144.

To correct it just remove the nginx image with:

docker rmi nginx

Enable ARM emulation with

docker run --rm -it --privileged torizon/binfmt

Then try running docker build with the Dockerfile you showed me. Repeat the same thing with your node.js image (docker rmi node:16.15.1 → change line to: FROM --platform=linux/arm64/v8 node:16.15.1 → Enable ARM emulation, build then push to docker hub)

That seems to be working. These messages don’t look like error messages.

Try doing the above and see if that helps.

Best regards,
Lucas Akira

lucas_a.tx · July 7, 2022, 1:01pm

Looks like you managed to create the Arm64 images. I also forgot to mention, you should change your docker-compose.yml to put the Arm64 images. For instance, try to run this docker-compose.yml:

version: "2.4"
services:

  weston:
    image: torizon/weston-vivante:2
    # Accept the EULA required to run imx8 vivante graphic drivers
    environment:
     - ACCEPT_FSL_EULA=1
    # Required to get udev events from host udevd via netlink
    network_mode: host
    volumes:
      - type: bind
        source: /tmp
        target: /tmp
      - type: bind
        source: /dev
        target: /dev
      - type: bind
        source: /run/udev
        target: /run/udev
    cap_add:
      - CAP_SYS_TTY_CONFIG
    # Add device access rights through cgroup...
    device_cgroup_rules:
      # ... for tty0
      - 'c 4:0 rmw'
      # ... for tty7
      - 'c 4:7 rmw'
      # ... for /dev/input devices
      - 'c 13:* rmw'
      - 'c 199:* rmw'
      # ... for /dev/dri devices
      - 'c 226:* rmw'
    command: --developer weston-launch --tty=/dev/tty7 --user=torizon

  kiosk:
    image: torizon/kiosk-mode-browser:2
    security_opt:
      - seccomp:unconfined
    command: --browser-mode http://localhost/index.html
    shm_size: '256mb'
    device_cgroup_rules:
      # ... for /dev/dri devices
      - 'c 226:* rmw'
    volumes:
      - type: bind
        source: /tmp
        target: /tmp
      - type: bind
        source: /var/run/dbus
        target: /var/run/dbus
      - type: bind
        source: /dev/dri
        target: /dev/dri
    depends_on:
       - weston
       - arm64estufateste1
       - arm64estufanodejs
 
  arm64estufateste1:
    container_name: arm64estufateste1
    networks:
      - backend
      - frontend
    ports:
      - "80:80"
    image: vdalmeida/arm64estufateste1

  arm64estufanodejs:
    container_name: arm64estufanodejs
    networks:
      - backend
    ports:
      - "3000:3000"
    image: vdalmeida/arm64estufanodejs

networks:
  backend:
    internal: true
  frontend:
    internal: false

If the image names are incorrect, just correct the image field to have the correct name. Try doing docker-compose up on your Verdin with this docker-compose.yml and see if it works.

Best regards,
Lucas Akira

V_D_ALMEIDA · July 7, 2022, 1:05pm

Lucas, Good Morning !

Yes, but you can keep the platform parameter in the docker-compose.yml, it shouldn’t be a problem. - OK.

The reason it didn’t work is due to a bug in docker run: docker run’s --platform option is ignored if the image already exists locally · Issue #1144 · docker/for-linux · GitHub.

To correct it just remove the nginx image with:

After enabling the Arm it work properly.

I’ve ran the arm64estudanodejs - no erros occurred.
I’ve ran the arm64estufateste1 - no errors occurred.

Although the dockercompose still not work when I try to update the Verdin through Torizon OTA.

Can I debug this through TorizonOta ?

V_D_ALMEIDA · July 7, 2022, 1:48pm

Lucas,

I update through TorizonOta instead of using docker-compose up, it worked.
But the HTML page is not openning yet.

All containers seems to be running.

What could be the reason for the html not work ?

V_D_ALMEIDA · July 7, 2022, 2:14pm

It worked, I used the TorizonOTA instead.

All containers are running, but the HTML didn’t open in the browser.

How could I debug it ?

lucas_a.tx · July 7, 2022, 2:48pm

Good that docker-compose worked!

How could I debug it ?

You can see the logs in each container with docker logs <name-of-the-container>.

To see the names of each container run docker ps -a and replace <name-of-the-container> with the container name you want.

On my side, I will try running this docker-compose.yml to see if I can reproduce your results.

Best regards,
Lucas Akira

V_D_ALMEIDA · July 7, 2022, 2:59pm

Lucas,

These are the containers running, I dont know exactly which thing I should change.
When I open the containers in Docker Stop and run in my notebook for example, they work very well.
Do I need to change some port parameter in the docker compose to run in the Verdin ?

V_D_ALMEIDA · July 7, 2022, 3:08pm

Lucas,

Its seems that they are working, but I still dont know how to see the html application.

Could you help me ?

V_D_ALMEIDA · July 7, 2022, 4:01pm

Lucas, I modified the docker compose, removed the network configuration, the html worked.

I’ll test the app server now.

V_D_ALMEIDA · July 7, 2022, 5:37pm

Lucas,

Although the HTML page is now working, the nodejs server does not communicate with it, or the HTML does not communicate with the nodejs server.
Even sending commands through the HTML page and then putting the cmd docker logs arm64estufanodejs the log that return is always the same. Is this normal ? I believe the log should be different.
Can I run a command to keeps the terminal of the arm64estufanodejs while I perform some commands in the HTML application ?

I’ve tested the containers in my development computer ($), it’s working properly.

As is shows below, the nodejs log is different than the Verdin Nodejs Log.

Computer development Log - Log changes when I change, send a command through the HTML page.

Verdin Nodejs Log - Always the same