we discovered some strange behaviour using the weston-vivante container.
Following setup:
Verdin IMX8MP
Torizon OS 6.5.0-build.8
weston-vivante:3.4.0.
One of our devices showed a locking screen after some time.
When inspecting the weston docker container, the weston.ini was empty.
The problem persists when rebooting the device.
When deploying the stack again using the same docker-compose file the weston.ini was filled with the normal content again.
This is the part of the docker compose we use for the weston container:
Hi, I’m the Toradex AI Assistant. The Toradex Support team will follow up with you shortly!
Did you like my answer?
Hello Erik,
Thank you for reaching out with your question. It sounds like you’re encountering an unusual issue where the weston.ini file in your weston-vivante container occasionally becomes empty, causing a locking screen on your Verdin iMX8MP device. Let’s explore some potential causes and solutions:
Container Restart Behavior: If the container restarts, it might not properly reinitialize the weston.ini file. Ensure your Docker Compose setup is configured to persist this file across restarts.
Volume Binding: Double-check your volume bindings in the Docker Compose file. Make sure the weston.ini file is correctly mounted and that the source path on the host contains the desired configuration. Incorrect bindings could lead to the file being overwritten or not found.
Startup Scripts: Review any startup scripts within the container that might overwrite the weston.ini file. It’s possible that an entry script or initialization process is modifying this file.
File Permissions: Verify that the file permissions allow the container to read and write to the weston.ini file as needed. Incorrect permissions might prevent proper access or modification.
Docker Compose Configuration: Ensure your Docker Compose file is correctly set up, particularly the volumes section, to bind the weston.ini file from the host to the container.
To further troubleshoot, you might want to manually inspect the weston.ini file on the host to ensure it contains the correct configuration before starting the container. Additionally, monitor the container logs for any errors or warnings related to the weston.ini file during startup.
By ensuring the correct setup and monitoring the container’s behavior, you should be able to identify and resolve the issue with the weston.ini file becoming empty. If the problem persists, consider testing with a minimal setup to isolate the cause.
I hope this helps! If you have any more questions, feel free to ask.
Best regards,
Toradex AI Assistant
Please, also check if these links can help you solve your problem:
Do you have any information on what seems to cause this issue to occur? Or, is it just completely random? At least in my experience I haven’t heard of such an issue before.
Looking at your compose file snippet, I can see you’re not bind-mounting an external weston.ini. Meaning you’re using the one built into the container image, so it doesn’t seem to be an issue related to volumes/bind-mounts.
Is it possible that the content of the weston.ini gets ovverwritten somehow at startup (by the entry script or something else)?
This sounds similar to an issue we had before and which was discussed here, where our findings were also that the running image had been corrupted somehow and weston.ini was similarly empty:
This sounds similar to an issue we had before and which was discussed here, where our findings were also that the running image had been corrupted somehow and weston.ini was similarly empty:
@bw908 True, though from what I recall in your case the empty/corrupted weston.ini file seemed related to hardware failures causing unexpected power resets in your system.
@erik.weber It didn’t sound like your situation involved such a power related fault, correct?
Yes, that was the instance we were able to investigate most thoroughly. We’ve seen a few others that we were never able to reproduce so I do not think the power loss is the only avenue to this issue.
I do not think the power loss is the only avenue to this issue.
I don’t doubt this. Though it’s hard to investigate further without anything more concrete. I can still say we’re not seeing anything similar on our own testing infrastructure that runs almost every night. Meaning I’m not sure if the conditions that can cause this are generic to everyone, but rare. Or, maybe it’s somewhat setup specific, which could explain why we haven’t seen this in our testing at Toradex.
@bw908 Thanks for the information. The underlying problem of the empty .ini seems to be the same. But at this point we dont have any clue what causes this issue on our devices. @jeremias.tx As the issue happened in our production line I cant say what exactly happened to the device. The production worker did not report any abnormalities concerning power to me. What definitely can happen is that the device is switched off (hard power disconnect) at the wrong time.
For now we modified the entry script to not use dos2unix as this is the only point we see the .ini gets written to. I think this should not cause any problems. We are still using the .ini from the image and do not mount our own.
In the meantime the problem is okay for us. If I get any more information on this topic I will report it here.
