I have a container that I built on “5.7.2+build.20.modified.containers”. I then Switched to “6.7.0+build.18.modified.container” because I started to write an application is VS code and wanted to use the latest and greatest for the Toradex plug-in. Long story short my previous container does not run anymore. It exited out with a “couldn’t get a file descriptor referring to the console”.
I went back to 5.7.2 and the container works. Then to 6.7.0 again and same issue (does not run). Tells me something is very different between OS core 5 vs 6.
The core of my container uses “torizon/weston-vivante:2” For OS 6 do I need to use “torizon/weston-vivante:3”? I’m also loading up gstreamer and crank storyboard with this container.
Any documentation to what to look out for from OS 5 to 6. and I guess soon to be 7
Hi, I’m the Toradex AI Assistant. I’m in early beta, and I would appreciate your feedback.
The Toradex Support team will follow up with you shortly!
Did you like my answer?
It sounds like you’re encountering compatibility issues between TorizonCore 5.x and Torizon OS 6.x, particularly with the container images and their dependencies. Here are a few points to consider and steps to help you troubleshoot and resolve the issue:
Container Base Image
Weston Image Version: Yes, you should use the appropriate version of the Weston image for Torizon OS 6.x. For Torizon OS 6.x, you should use torizon/weston-vivante:3 instead of torizon/weston-vivante:2. The base images are versioned to match the underlying OS, and using the correct version ensures compatibility.
GStreamer and Crank Storyboard
GStreamer and Crank Storyboard: Ensure that the versions of GStreamer and Crank Storyboard you are using are compatible with Torizon OS 6.x. There might be changes in dependencies or configurations that need to be addressed.
Documentation and Release Notes
Release Notes: Review the release notes for Torizon OS 6.x, particularly the sections that discuss changes and updates from TorizonCore 5.x. This can provide insights into what has changed and what you might need to adjust in your container setup.
Debugging: To get more details on why the container is failing, you can try running the container with increased verbosity or debugging options. This might give you more information on what is causing the “couldn’t get a file descriptor referring to the console” error.
Transition Guide
Transition Guide: Follow the transition sequence provided in the documentation for upgrading from TorizonCore 5.x to Torizon OS 6.x. Ensure that you have updated the bootloader and performed a regular OS update as described.
Example Dockerfile and Docker-Compose
Example Dockerfile and Docker-Compose: Refer to the example Dockerfile and Docker-Compose configurations provided in the Torizon documentation. Ensure that your configurations align with the recommended practices for Torizon OS 6.x.
Yes, if you look at the diagram in the following links, you will find the respective :2 and :3 are for Torizon OS 5 and 6. So you could be mixing/matching to where something is throwing an error. Can you provide some logs for what you are doing?
The " Multi-Container Example Using Docker Compose" sections seems to put of date. It’s still referencing vivante:2 images. If I want a docker compose to launch a vivante:3 what are the changes I need between the two.
For example, I got this compose file, but Weston just shuts down after 5 seconds. but if I run the container like this:
docker run -e ACCEPT_FSL_EULA=1 -d --rm --name=weston --net=host --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’ torizon/weston-vivante:$CT_TAG_WESTON_VIVANTE --developer --tty=/dev/tty7
It stays running. Not sure what is wrong in the compose file
Hey there, i just ran through a similar issue, and after looking through docker logs etc, i found it to be an issue with the entrypoint script that starts wayland, and more particularly related to the HDMI ports.
One way you can debug and see what change is causing your docker to start your docker with an entrypoint and see if you can start there with this flag in you run command:
–entrypoint /bin/bash.
once you are in your docker is running you can also do a docker logs and see where that gets you.
