Problems with the Torizon IDE

Technical Support
, ,
1

I’m having recurring problems with the Torizon IDE.

I have several projects, mostly C# projects, but also C and Python projects.

The IDE usually runs in VS Code on a Windows machine, but on a separate Ubuntu 22.04 LTS installation. Sometimes also from a MAC VSCode remote to the same Torizon IDE installation on the Ubuntu computer. It works OK cince years.

Recently, I had trouble starting the release container in a C# project (using the run-container-torizon-release-arm64 task).

Today, remove dangling images isn’t executing… it says “permission denied,” even though it works in a similar parallel project.

If I make the *.xsh file executable, that works, but then I get a barrage of “permission denied” errors for the other tasks.

Everything gets messed up at some point, and I have no idea how to fix it.

Can anyone help me?

Best regards
Gerald

2

Hi, I’m the Toradex AI Assistant.

I might make mistakes or occasionally get you wrong. Our support team will step in if needed.

Hello Gerald,

I can help you troubleshoot these permission issues with the Torizon IDE Extension. Based on the documentation and similar issues reported by other users, here are several approaches to resolve these problems:

Understanding the File Structure

The Torizon IDE Extension uses several script files in the .conf directory that need proper execution permissions(1)(2). These include:

  • .conf/check-deps.xsh
  • .conf/validate-deps-running.xsh
  • .conf/torizon-packages.xsh
  • Various other .xsh scripts for project management

Troubleshooting Permission Issues

1. Check File Permissions

First, verify the permissions on your project files:

ls -la .conf/*.xsh

2. Fix Permissions for All Script Files

Instead of making individual files executable, set permissions for all necessary scripts:

chmod +x .conf/*.xsh
chmod +x .vscode/tasks.xsh

3. Verify Docker Permissions

Since you’re getting permission denied errors with Docker operations, ensure your user has proper Docker permissions:

sudo usermod -aG docker $USER

Then log out and back in, or restart your session.

4. Check WSL File System Location

The documentation emphasizes that on Windows, the project folder must be in the Linux filesystem inside WSL, not on /mnt/c/...(1). If your projects are stored on the Windows filesystem, this can cause permission issues.

Release Container Issues

For the run-container-torizon-release-arm64 task specifically, there’s a known issue pattern where Docker Compose build failures can occur due to invalid image tag formats(3). Check your docker-compose.yml file for proper formatting:

image: ${LOCAL_REGISTRY}:5002/your-app-name:${TAG}

Environment Validation

The extension includes environment validation scripts(2). Run the validation task to identify issues:

pwsh -nop .conf/validateDepsRunning.ps1

Recommended Recovery Steps

  1. Reset permissions on your entire project directory:

    find /path/to/your/project -name "*.xsh" -exec chmod +x {} \;

  2. Verify Docker daemon is running and accessible:

    docker ps

  3. Check environment variables in .vscode/settings.json for proper configuration(2)

  4. Restart VS Code and the Docker service if needed

If these steps don’t resolve the issue, the problem might be related to your specific Ubuntu installation or Docker configuration rather than the Torizon IDE Extension itself.

Best regards, Toradex AI Assistant.

Did you like my answer? :+1: :-1:

If I answered your question, please tick the “Solution” checkbox.

For follow-up questions to me, please use @ToradexAI in your post.

3

Hi Gerald,

what IDE version do you use? I had problem with the newest version 3.2.6 and downgrading to 3.2.5 helped me.

4

Version-Related Issues

Thank you for bringing up the IDE version issue. There have been documented problems with certain versions of the Torizon IDE Extension that can cause permission and execution errors(1).

Known Version Issues

The community has reported specific problems with newer versions of the Torizon IDE Extension, particularly around script execution and permission handling(1). Some users have found success by reverting to earlier versions when encountering these types of issues.

Checking Your Extension Version

To check your current Torizon IDE Extension version:

  1. Open VS Code
  2. Go to the Extensions panel (Ctrl+Shift+X)
  3. Search for “Torizon”
  4. Check the version number displayed

Alternative Solutions

If downgrading the extension version resolves the permission issues, you can also try:

Template Version Management

You can control which template versions to use by configuring the extension settings(2):

  • torizon.templatesTag: Controls which template version to fetch
  • torizon.templatesBranch: Specifies the branch for templates

For example, in your .vscode/settings.json:

{
  "torizon.templatesTag": "v2.8.1",
  "torizon.templatesBranch": "bookworm"
}

(2)

Environment Validation

The extension includes built-in environment validation that can help identify compatibility issues between different versions(3). When creating or opening projects, ensure you run the dependency check to verify your environment is properly configured.

This version-specific approach might be more targeted than the general permission fixes I mentioned earlier, especially if the issues started appearing after an extension update.

Best regards, Toradex AI Assistant.

Did you like my answer? :+1: :-1:

If I answered your question, please tick the “Solution” checkbox.

For follow-up questions to me, please use @ToradexAI in your post.

5

This alone helped.

I wonder how I can prevent this from happening again in the future.

I also have successful projects where I didn’t have to do anything like this.

…

@Lars.ceta :
Torizon IDE version :: 3.2.6
Latest Torizon IDE published :: 3.2.159

I’ll try that in an ‘emergency’ too…

6

Update:

now occures this:

Starting: "ssh" -T -q -p 2222 -o StrictHostKeyChecking=no -o "UserKnownHostsFile /dev/null" torizon@10.100.1.79 "/vsdbg/vsdbg --interpreter=vscode"
------------------------------------------------------------------------------
You may only use the Microsoft Visual Studio .NET/C/C++ Debugger (vsdbg) with
Visual Studio Code, Visual Studio or Visual Studio for Mac software to help you
develop and test your applications.
------------------------------------------------------------------------------
You must install or update .NET to run this application.

App: /home/torizon/app/NetworkTracingAPITorizon
Architecture: arm64
Framework: 'Microsoft.AspNetCore.App', version '8.0.0' (arm64)
.NET location: /dotnet

No frameworks were found.

Learn more:
https://aka.ms/dotnet/app-launch-failed

To install missing framework, download:
https://aka.ms/dotnet-core-applaunch?framework=Microsoft.AspNetCore.App&framework_version=8.0.0&arch=arm64&rid=linux-arm64&os=debian.12
The target process exited without raising a CoreCLR started event. Ensure that the target process is configured to use .NET Core. This may be expected if the target process did not run on .NET Core.
The program '[114] NetworkTracingAPITorizon' has exited with code 150 (0x96).
7

Hi @gerko,

Do you see this issue with any project or just with your existing one?

Could you try to create a new project and let me know if the same problem is present?
If the new project works, you could try to update your existing project template with the try-update-templates task, as described here: Update Project from Template | Toradex Developer Center

Please make sure to have your project in a git repository prior to doing the above, so you can always revert to the previous working state if needed.

Best Regards,
Bruno

8

Hi @bruno.tx …

that I’ve done. It worket fine a while.

I have to trace in a c# project via pcap in docker network host mode. As user torizon that ist not possible for me.
In a earlier Project I had used the setting “torizon_run_as”:root and all worked fine.

In the newly created project, I couldn’t start the debug process via SSH…

Terminal msgs:

Executing task: DOCKER_HOST=10.100.1.79:2375 LOCAL_REGISTRY=localhost TAG=arm64 GPU=-imx8 DEBUG_SSH_PORT=2223 DEBUG_PORT1= DEBUG_PORT2= DEBUG_PORT3= docker compose -p torizon up -d networktracingapi-debug 

WARN[0000] The "DOCKER_LOGIN" variable is not set. Defaulting to a blank string. 
[+] Running 2/2
 ✔ Container torizon-networktracingapi-debug-1                                        Started                                                                                                                               0.5s 
 ! networktracingapi-debug Published ports are discarded when using host network mode                                                                                                                                       0.0s 
 *  Terminal will be reused by tasks, press any key to close it. 

 *  Executing task: xonsh /home/carlton/Toradex/_GitLab/test-controller/toradex-hardware/apis/networktracing/NetworkTracingAPI/.conf/service-check.xsh ssh 1 2223 torizon 10.100.1.79 'echo ssh-ok' 

Exception occurred: Command '['sshpass', '-p', '1', 'ssh', '-p', '2223', '-o', 'UserKnownHostsFile=/dev/null', '-o', 'StrictHostKeyChecking=no', '-o', 'PubkeyAuthentication=no', 'torizon@10.100.1.79', 'echo ssh-ok']' returned non-zero exit status 5.
Attempt 1/15: waiting for ssh...
Exception occurred: Command '['sshpass', '-p', '1', 'ssh', '-p', '2223', '-o', 'UserKnownHostsFile=/dev/null', '-o', 'StrictHostKeyChecking=no', '-o', 'PubkeyAuthentication=no', 'torizon@10.100.1.79', 'echo ssh-ok']' returned non-zero exit status 5.
Attempt 2/15: waiting for ssh...

.... 15 x


then:

^Cxonsh: To log full traceback to a file set: $XONSH_TRACEBACK_LOGFILE = <filename>
Traceback (most recent call last):
  File "/home/carlton/Toradex/_GitLab/test-controller/toradex-hardware/apis/networktracing/NetworkTracingAPI/.conf/service-check.xsh", line 62, in <module>
    if result.returncode == 0:
  File "/home/carlton/.local/pipx/venvs/xonsh/lib/python3.10/site-packages/xonsh/procs/pipelines.py", line 735, in returncode
    self.end()
  File "/home/carlton/.local/pipx/venvs/xonsh/lib/python3.10/site-packages/xonsh/procs/pipelines.py", line 481, in end
    self._end(tee_output=tee_output)
  File "/home/carlton/.local/pipx/venvs/xonsh/lib/python3.10/site-packages/xonsh/procs/pipelines.py", line 489, in _end
    for _ in self.tee_stdout():
  File "/home/carlton/.local/pipx/venvs/xonsh/lib/python3.10/site-packages/xonsh/procs/pipelines.py", line 391, in tee_stdout
    for line in self.iterraw():
  File "/home/carlton/.local/pipx/venvs/xonsh/lib/python3.10/site-packages/xonsh/procs/pipelines.py", line 351, in iterraw
    time.sleep(timeout * cnt)
  File "/home/carlton/.local/pipx/venvs/xonsh/lib/python3.10/site-packages/xonsh/procs/posix.py", line 330, in _signal_int
    signal.pthread_kill(threading.get_ident(), signal.SIGINT)
  File "/home/carlton/.local/pipx/venvs/xonsh/lib/python3.10/site-packages/xonsh/procs/posix.py", line 330, in _signal_int
    signal.pthread_kill(threading.get_ident(), signal.SIGINT)
  File "/home/carlton/.local/pipx/venvs/xonsh/lib/python3.10/site-packages/xonsh/procs/posix.py", line 330, in _signal_int
    signal.pthread_kill(threading.get_ident(), signal.SIGINT)
  [Previous line repeated 29 more times]
  File "/home/carlton/.local/pipx/venvs/xonsh/lib/python3.10/site-packages/xonsh/procs/posix.py", line 328, in _signal_int
    self._restore_sigint(frame=frame)
  File "/home/carlton/.local/pipx/venvs/xonsh/lib/python3.10/site-packages/xonsh/procs/posix.py", line 341, in _restore_sigint
    old(signal.SIGINT, frame)
KeyboardInterrupt

 *  The terminal process "/usr/bin/bash '-c', 'xonsh /home/carlton/Toradex/_GitLab/test-controller/toradex-hardware/apis/networktracing/NetworkTracingAPI/.conf/service-check.xsh ssh 1 2223 torizon 10.100.1.79 'echo ssh-ok''" terminated with exit code: 1. 


chmod +x .conf/*.xsh
chmod +x .vscode/tasks.xsh

I’ve executed.

In the working project, there’s no ssh-check task in task.json… Maybe that gives us a clue?

Ha… if I remove the ssh-check from the deploy-torizon-arm64 task, it works again… so far, so good. :face_with_peeking_eye:

Best
Gerald

9

Hello @gerko,

Thanks for the update.
I will ask for the IDE Extension team to have a look, maybe there is some edge case that the ssh-check task is hitting.

Best Regards,
Bruno

10

Hello @gerko,

Could you provide a project that you see the issue mentioned here with the ssh-check task?
Our extension team asked for this to be able to diagnose the problem.

If yes, please compress it and upload it to share.toradex.com.
You can then send the link to support.eu@toradex.com or send me a private message with it here on the community.

Best Regards,
Bruno

11

Sorry for the late reply…

I tested the problem with a newly created C# project. You can easily reproduce it by simply creating a similar project and setting the variable "torizon_run_as" to "root" in the .vscode settings.

At some point, when debugging, you’ll see the following in the terminal:

'echo ssh-ok'" terminated with exit code: ...

Best
Gerald

12

Hello @gerko,

Is the board running any containers before you try to run your new project?

From the description of the problem, it would seem to be an interaction between the container configuration and some of the checks done by the extension.
Therefore, an existing running container from your original project could interfere with a brand new project in the same way.

Best Regards,
Bruno

13

I don’t think I understand correctly.

There are several containers running on the module. For example, Portainer, Weston, Chromium, and other C# -, python - web APIs for controlling the network, etc.

How is that supposed to work? … I don’t see how they affect each other.

On the other hand, a solution where I can use pcap tracing as “torizon_run_as”: “torizon”, would be better.

Best Regards
Gerald

14

Hi @gerko,

After speaking with the IDE Extension team, we think that the containers which are configuring the network are affecting this task from the IDE extension.
Therefore, we would like to understand how that is happening so that we can either recommend a possible solution or handle the task differently in the IDE Extension.

Either a running container from your original project or another running container on the device is likely causing the issue.
If we just create a normal C# project from the template and run it in a device which has no other containers running, we will not have the same issue that you are facing.

It is possible that just adding the CAP_NET_RAW and CAP_NET_ADMIN capabilities to the container will be enough.
If you don’t already have it configured in your docker compose file, I would recommend that you give it a try.

Best Regards,
Bruno

15

That’s not the case for me. Why ever …

here my docker compose:

 networktracingapi-debug:
    build:
      context: .
      dockerfile: Dockerfile.debug
    image: ${LOCAL_REGISTRY}:5002/networktracingapi-debug:${TAG}
    ports:
      - ${DEBUG_SSH_PORT}:${DEBUG_SSH_PORT}
      - 7001:7001
    profiles:
      - debug
    network_mode: host
    cap_add:
      - NET_ADMIN
      - NET_RAW
    privileged: true
    volumes:
      - type: tmpfs
        target: /home/torizon/app/pcaps
        tmpfs:
          size: 268435456   # 256 MB just for debug

The program runs …
Here I get following debug exception message at code CaptureDevice.Open(devConfig); :

Exception has occurred: CLR/SharpPcap.PcapException
An exception of type 'SharpPcap.PcapException' occurred in SharpPcap.dll but was not handled in user code: 'Unable to activate the adapter (ethernet0). (Error Code: PermissionDenied)'

As user torizon I cannot access the real interfaces, such as ‘ethernet0’… (there are 3 more on our custom board).
It’s surprising that I can successfully run tcpdump -i ethernet0 in ‘run as torizon mode’ inside the container.

In mode “torizon_run_as”: “root” It works perfectly.

And this mode sometimes doesn’t work… I suspect it’s due to some environment settings configured by the extension.

Because sometimes the problem can be “fixed” by restarting the Torizon host computer (Ubuntu).

It would be great if we could find the cause.

Best Regards
Gerald

16

Hello @gerko,

I tested this here to make sure our automated tests did not miss a regression on the C# template, and can confirm that the extension works correctly with this template on a clean Torizon OS installation.
Do you see the issue also with a device without anything running?

For this kind of access to the interface, root permissions are usually required.
Adding capabilities to the program itself may be a workaround.
For the release container, built with Dockerfile, you should be able to add the libcap2-bin package to the build container and add the capabilities to the executable itself with:

setcap cap_net_raw,cap_net_admin+ep <executable>

However, for the debug workflow, it is somewhat more complicated to get this done.
As the executable is copied to the target with the user configured by torizon_run_as, which, if not root, will not be able to set such capabilities.

Therefore, I would recommend that for debugging, the root user is used, as it will be simpler.

Regarding the issue with the ssh-check task, could you provide a way for us to reproduce this issue?
Either in the form of a minimal project or some steps to get there?
Without a reliable way to reproduce and understand the cause of it, there is not much we can do to suggest solutions for the ssh-check issue.

Best Regards,
Bruno

17

yes

I actually tested it with a fresh C# console project and I get the ssh-check errors in root mode… regardless of whether all other containers are removed or not.

  • Do you also test on a separate Ubuntu 22.04 installation, or only as a WSL 24.04 Ubuntu installation?
  • Do you test with multiple projects open?
  • Or do you sometimes open other projects while working on one project?

One possible problem is that I sometimes open projects that were created in an older version of the Torizon extension.

But I don’t know for sure. I only know that some projects work fine, and then seemingly for no reason, they suddenly stop building, starting, debugging, deploying, etc.

For example, in a current project, the run-container-release-arm64 task results in the following error message:

Executing task: sleep 1 && DOCKER_HOST=10.100.1.79:2375 docker pull localhost:5002/networktracingapi:0.0.8 

Error response from daemon: manifest for localhost:5002/networktracingapi:0.0.8 not found: manifest unknown: manifest unknown

Best
Gerald

18

Hello @gerko,

Thanks for the clarifications.

I tested in a system with multiple VSCode windows open, but only a single Torizon IDE project.
I don’t think that multiple projects open should impact anything, unless one of them is actually running.
My system is Debian 12, but I know our IDE team tests both with ubuntu and ubuntu under WSL.
The OS used could be relevant here.

Did you try with a board that had been rebooted after the containers were stopped?
It is conceivable to me that containers configured the network interface in a way that triggers the problem, then, if the container is stopped but the system not rebooted, the configuration will persist.

This issue actually looks like the following problem: Unable to run projects with docker "containerd snapshotter" backend (docker >=29) · Issue #427 · torizon/vscode-torizon-templates · GitHub

The workaround described in the following thread should avoid this problem: Docker 29.x on Ubuntu causes "no matching manifest for linux/arm64/v8" and Compose v5.0.0 crash

Best Regards,
Bruno

19

That doesn’t change anything.

Just so I understand correctly:

  • The image is being built.
  • The image is being pushed → to the registry on the development machine with binfmt enabled.
  • I can view the image by running:
    docker image ls | grep networktracing on the Ubuntu machine. but not as localhost:5002! as ourcompany/networktracingapi:0.0.###
  • However, the task wants to pull on the the module (DOCKER_HOST=10.100.1.79:2375) from localhost (e.g.: docker pull localhost:5002/networktracingapi:0.0.14), but it should be pulling it from the local registry. ???

Or am I misunderstanding something?

Best Regards
Gerald

20

Hello @gerko,

Speaking with the IDE Extension team, ourcompany/networktracingapi:0.0.### should only be be built when running the production container.
Otherwise, the container is expected from localhost:5002.

Could you send the initialization logs of the IDE Extension?

Best Regards,
Bruno