But the above command just printed a string of digits and the container is not up running. CodeSys Development System could not find the device and I ran the following command, there was no active container:
docker container ls -a
docker ps -a
I then changed the command to:
docker run --rm -t --name codesys --network host --privileged torizonextras/codesys
I could see it dumped the following error:
docker run --rm -t --name codesys
--network host --privileged torizonextras/codesys
********* CoDeSysControl DEMO VERSION - runs 2 hours********* ./entrypoint.sh: line 3: 7 Segmentation fault (core dumped) ./codesyscontrol
The version of TorizonCore is as follows:
colibri-imx6-10638825:~$ uname -a
Linux colibri-imx6-10638825 5.4.2-+git.0a15b6b8f633 #1 SMP Fri Dec 6 13:39:24 UTC 2019 armv7l armv7l armv7l GNU/Linux
I have the same hardware setup as you on my end and the codesys container stays up after the docker run command. Just to make sure it’s not any weird environment issue can you quick reinstall Torizon on your device.
I’ll investigate internally to see if there’s something that could possible cause a segmentation fault here.
I don’t believe it’s an issue of hardware since the container runs on my setup and I’m using the same exact module and carrier board as you are.
Unfortunately I can’t comment too much on the segmentation fault as the binary that is causing the seg fault in your case was provided by our partner Codesys, for the purpose of this container.
Could you try flashing one of the more recent Torizon images using our Easy Installer tool to access our CI/CD feeds. Perhaps try one of the images with PREEMPT_RT enabled.
I’ll see if I can get any more information about the codesyscontrol binary.