Dear Support team,

I am trying in vain to test the templates you have provided for the new Torizon 6… . I set up the development environment with VSCode as you described on the website and everything seems to be working. However, as soon as I switch to “Torizon ARMv7” I get the following error message at:

Executing task: sshpass -p ssh123456789 ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no [email protected] LOCAL_REGISTRY=172.17.18.14 TAG=arm docker-compose pull test-net-console-debug
Warning: Permanently added ‘192.168.255.145’ (ED25519) to the list of known hosts.
time=“2023-06-15T11:48:23Z” level=warning msg=“The "DOCKER_LOGIN" variable is not set. Defaulting to a blank string.”
test-net-console-debug Pulling
test-net-console-debug Warning
WARNING: Some service image(s) must be built from source by running:
docker compose build %s test-net-console-debug
1 error occurred:
* Error response from daemon: Get “ http://172.17.18.14:5002/v2/ ”: dial tcp 172.17.18.14:5002: connect: no route to host * The terminal process “sshpass ‘-p’, ‘ssh123456789’, ‘ssh’, ‘-o’, ‘UserKnownHostsFile=/dev/null’, ‘-o’, ‘StrictHostKeyChecking=no’, ‘[email protected]’, ‘LOCAL_REGISTRY=172.17.18.14 TAG=arm docker-compose pull test-net-console-debug’” terminated with exit code: 18.

I tested that with Python 3-, .NET 6 C# Console Application- and ASP.NET 6 Blazor Application-Templates. Debugging stops allways with simular error code.
Do you have an idea, what I did wrong? Thanks in advance.

Plattform:
Apalis imx6 V1.1B
Ixora V1.1A
Torizon 6.2.0
VSCode 1.79.1
WSL2 → Ubuntu 22.04
ApolloX V2.0.0

I also have another question. When I start debug, all existing containers on device get stoped and removed. When working with Torizon 5 and Torizon extension V1, this behavior was not present. Can I set up this anywhere?

Hello @JanP ,

Thanks for reaching out to the Toradex Community!

Since you said it worked just fine with IDE extension V1 and now it has issues on V2, it really looks like a conflict between the two versions installed on VSCode.

Please take a look at this answer from @lucas_a.tx on a similar topic.
In summary, if you are trying to use V2, you must make sure that you have disabled V1 of the extension. Please let me know if that helps

Hello @rudhi.tx ,

Thanks a lot. I found the problem. I was connected to the company via VPN and then, I don´t know why, but Ubuntu distro became an IP from the wrong ethernet adapter. After disconnecting VPN and restarting the my mashine, everything works fine.

But one thing more to my second question: When starting debugging all other running containers will stopped and removed. Can you change that behavior?

JanP:

When starting debugging all other running containers will stopped and removed. Can you change that behavior?

Do you have more than one container? Could you please share a bit of your “container architecture”?

Best regards,

Hi @henrique.tx ,

No. I used the preinstalled standard templates from the ApolloX extension as single project and changed under Run and debug to “Torizon ARMv7” and pressed F5 without any changes. During deploy process this will shown in Termin.

Same thing happens on the pc of my college.

Hi @JanP !

Sorry, I didn’t quite understand your last message. Did some issue happen?

Could you give us some context?

Best regards,

Hi @henrique.tx ,

No problem. So again:
When I start debugging, all running containers on my iMX6 seems to be stopped and removed during deploy process (like you see in the screen shot from terminal output).
My question is: Can I change that behavior and if so, where to do that?

I don´t use multi container. I just create a new single container project (e.g. blazor-template, c#-console-template or c+±template). I did no changes at the projects. I just changed to “Torizon ARMv7” and start with F5. At all that three templates happens the same. Running containers get stopped and removed.

Deployment and debugging is working fine. There is no issue happen.

JanP:

When I start debugging, all running containers on my iMX6 seems to be stopped and removed during deploy process (like you see in the screen shot from terminal output).

This is indeed the expected behavior. Torizon extension will stop the containers currently running on the target and remove them before launching the container(s) of your project.

If you want to have some containers running during your tests/debugging sessions, you will need to adapt the docker-compose.yaml of your project by adding those containers in there.

Be aware that a breakpoint during your debug session will only pause the application that you are developing. The other container/applications of your architecture will not be paused (just like any usual debugging session )

At the same time, if this is not suitable for your use case, please share with us your needs. I can bring up your specific use case internally in Toradex to be analyzed

Best regards,

JanP:

I understand! Do you have an example how the construction of .yaml-file looks like, when I want that the default and preinstalled portainer backend funktionality is available during debugging?

Toradex has this nice repository with several examples: GitHub - toradex/torizon-samples: All sample code related to TorizonCore project.

In there, you will find e.g. the debian-container folder that holds something similar to what you have by default when you install TorizonCore with Evaluation containers. Please pay attention to the branch and the file that you will use as the reference for you. The link below is on the bookworm branch (the current version of Debian used in TorizonCore 6 containers) branch and is meant for Arm 32-bit modules with GPU (like your Apalis iMX6).

github.com

toradex/torizon-samples/blob/bookworm/debian-container/demonstration/docker-compose.armhf.yml

version: "2.4"
services:
  weston:
    image: torizon/weston:2
    # 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:
              
You are welcome, @JanP !
If your question/issue was solved, please don’t forget to mark the most suitable message as the solution 
Best regards,