Issue creating my own weston dockerfile

Hello,

I am currently trying to rebuild my own weston and chromium images.
I have copied your Dockerfile for the weston part and changed the name of it :
Dockerfile (421 Bytes)
weston.ini (1.4 KB)

And I am running this container with the following command : docker run -e ACCEPT_FSL_EULA=1 -d --rm --name=proengincore-weston --cap-add CAP_SYS_TTY_CONFIG
-v /dev:/dev -v /tmp:/tmp -v /run/udev/:/run/udev/
–device-cgroup-rule=‘c 4:* rmw’ --device-cgroup-rule=‘c 13:* rmw’
–device-cgroup-rule=‘c 199:* rmw’ --device-cgroup-rule=‘c 226:* rmw’
proengincore-weston

And building it with the command : docker build -t proengincore-weston .
The build is acting fine, I have no errors but when I am trying to run my container, I have the following error message :

When I am directly pulling the torizon/image without rebuilding it with my own Dockerfile, it’s working perfectly …

Thank you for your help,

Muzzy

Greetings @Muzzy,

I just took your Dockerfile and weston.ini exactly as you provided it and built my own image that should be the same as the one you built. And it worked fine for me here’s what the beginning of my logs look like:

Switching VT tty1 to text mode if currently in graphics mode
Switching to VT 7
SoC is: 'i.MX8MP'
SoC has GPU: true
SoC has DPU: false
g2d implementation: viv
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.
dos2unix: converting file /etc/xdg/weston/weston.ini to Unix format...
dos2unix: converting file /etc/xdg/weston-dev/weston.ini to Unix format...
00:00:00.000 [INFO] [seatd/seat.c:39] Created VT-bound seat seat0
00:00:00.000 [INFO] [seatd/seatd.c:194] seatd started
Date: 2023-11-13 UTC
[22:49:55.170] weston 10.0.1
               https://wayland.freedesktop.org
               Bug reports to: https://gitlab.freedesktop.org/wayland/weston/issues/
               Build: lf-5.15.52-2.1.0-10-g9452feba
[22:49:55.170] Command line: weston -Bdrm-backend.so --current-mode -Swayland-0
[22:49:55.170] OS: Linux, 5.15.129-6.4.0+git.67c3153d20ff, #1-TorizonCore SMP PREEMPT Wed Sep 27 12:30:36 UTC 2023, aarch64
[22:49:55.170] Flight recorder: enabled
[22:49:55.171] Using config file '/etc/xdg/weston/weston.ini'
[22:49:55.171] Output repaint window is 7 ms maximum.
[22:49:55.171] Loading module '/usr/lib/aarch64-linux-gnu/libweston-10/drm-backend.so'
[22:49:55.181] initializing drm backend
[22:49:55.181] Trying libseat launcher...
00:00:00.052 [INFO] [seatd/server.c:145] New client connected (pid: 28, uid: 1000, gid: 1000)
00:00:00.053 [INFO] [seatd/seat.c:170] Added client 7 to seat0
00:00:00.053 [INFO] [seatd/seat.c:480] Opened client 7 on seat0
[22:49:55.181] libseat: session control granted
[22:49:55.187] using /dev/dri/card0
[22:49:55.187] DRM: supports atomic modesetting
[22:49:55.187] DRM: does not support GBM modifiers
[22:49:55.187] DRM: supports picture aspect ratio
[22:49:55.187] Loading module '/usr/lib/aarch64-linux-gnu/libweston-10/gl-renderer.so'
...

As you can see it’s a bit different from yours. Interestingly your logs seem to state that there is no GPU and software rendering will be used instead. Which isn’t right for the Verdin i.MX8M Plus.

I did my test on Torizon OS 6.4.0, what version are you doing this on?

Best Regards,
Jeremias

Hi @jeremias.tx,

Thank you for your answer,

I am currently doing my test on a custom image based on 5.7.2 version of Torizon OS.

Regards,

Muzzy

Hi @Muzzy ,

Will you try on 6.4? Is that an option for you?

Best Regards
Kevin

I am currently doing my test on a custom image based on 5.7.2 version of Torizon OS.

That’s the issue right there. Your Dockerfile is using tag 3 for our containers. Tag 3 is only meant to be used alongside Torizon OS 6.X. For Torizon OS 5.X you want to use tag 2.

As per this page: Torizon Containers Tags and Versioning | Toradex Developer Center

You want to check the environment variables of whatever version of Torizon OS you are currently running. This will tell you which tag of our containers are meant to run on this version of the OS.

Best Regards,
Jeremias

Okay, tahnk you @jeremias.tx !
It is working now thank you.

Regards,

Muzzy

Perfect, glad I was able to help!