I am working with the Colibri iMX7D 1GB module running TorizonCore OS. I want to run my PySide2 UI project on the iMX7 from Visual Studio Code, using the configured Toradex Extension. The device is successfully connected.
From the “Run and Debug” menu, I run the Torizon arm32 configuration, but I encounter a problem while building the Docker image.
I need all the steps required to run a basic PySide2 application (UI) on the iMX7.
Please guide me through these steps.
Hi, I’m the Toradex AI Assistant.
I might make mistakes or occasionally get you wrong. Our support team will step in if needed.
I understand you want to run a PySide2 UI application on your Colibri iMX7D 1GB module using the Torizon VS Code extension. Based on the available documentation, I can confirm that your hardware is supported (1), and the VS Code integration provides streamlined development workflows (2).
Before proceeding, ensure you have:
The VS Code integration requires a minimal configuration file to specify your target device and build parameters (2). Create a tcbuild.yaml file in your project directory:
# Sample configuration file:
input:
easy-installer:
local: images/torizon-core-docker-colibri-imx6-Tezi_5.3.0+build.7.tar
output:
easy-installer:
local: torizon-core-docker-colibri-imx6-Tezi_5.3.0.CUSTOM
The VS Code extension provides device discovery and connection capabilities (2):
Connectuser and password credentialsSince you’re experiencing Docker image build problems, this typically relates to:
The Torizon platform supports containerized application development (3), which simplifies:
Your Colibri iMX7D 1GB module is fully supported with Torizon (1), including:
Unfortunately, the provided documentation doesn’t contain specific step-by-step instructions for PySide2 application deployment. For detailed PySide2 container configuration and troubleshooting your specific Docker build issues, you may need to:
Best regards, Toradex AI Assistant.
Did you like my answer? 
If I answered your question, please tick the “Solution” checkbox.
For follow-up questions to me, please use @ToradexAI in your post.
Greetings @Coders,
but I encounter a problem while building the Docker image.
What is this “problem” you get?
It should also be noted that if you are using Torizon OS 7 on your device than the Pyside 2 template is deprecated: vscode-torizon-templates/DEPRECATED.md at dev · torizon/vscode-torizon-templates · GitHub
It should still be available on Torizon OS 6 though.
Best Regards,
Jeremias
You provided a template link for PySide2, but it appears to be blank on the website’s “python3Pyside2QML“ link. We also tried switching from PySide2 to PyQt5. Below are the additional details.
I created the project in VS Code using the Python Console Application template for TorizonCore.
Will this template work for a Qt-based Python UI project?
Also, could you please help me understand why the PySide2/PyQt5 libraries don’t get installed during the Docker build?
I replaced PySide2 with PyQt5 in my project, but both packages fail to install inside the container when built through the VS Code Torizon extension.
The container deployment to my Colibri i.MX7 device works fine, and the connection is established properly — but the PySide2/PyQt5 modules are missing inside the runtime environment.
I’m currently using the following OS on my device:
torizon@colibri-imx7-emmc-06673348:~$ cat /etc/os-release
ID=torizon-upstream
NAME=“Torizon OS Upstream”
VERSION=“7.3.0+build.18 (scarthgap)”
VERSION_ID=7.3.0-build.18
VERSION_CODENAME=“scarthgap”
PRETTY_NAME=“Torizon OS Upstream 7.3.0+build.18 (scarthgap)”
CPE_NAME=“cpe:/o:openembedded:torizon-upstream:7.3.0+build.18”
BUILD_ID=“18”
ANSI_COLOR=“1;34”
VARIANT=“Docker”
When I run the base image torizon/arm32v7-debian-wayland-base:3.0 manually and install the pyside2 or pyqt5 library inside the container, it installs and works fine.
However, when I try to install pyside2 or pyqt5 using a Dockerfile, the libraries don’t get installed within the container, and I get a ModuleNotFoundError at runtime.
Below is my Dockerfile , please take a look of it.
board architecture
ARG IMAGE_ARCH=
#Base container version
ARG BASE_VERSION=3.0
#Directory of the application inside container
ARG APP_ROOT=
FROM --platform=linux/${IMAGE_ARCH}
torizon/arm32v7-debian-wayland-base:${BASE_VERSION} AS deploy
ARG IMAGE_ARCH
ARG APP_ROOT
#your regular RUN statements here
install required packages
RUN apt-get -q -y update &&
apt-get -q -y install
python3-minimal
python3-pip
python3-venv \
# python3-pyside2.qtcore python3-pyside2.qtwidgets python3-pyside2.qtgui \
#DO NOT REMOVE THIS LABEL: this is used for VS Code automation
# __torizon_packages_prod_start__
# __torizon_packages_prod_end__
#DO NOT REMOVE THIS LABEL: this is used for VS Code automation
&& apt-get clean && apt-get autoremove && \
rm -rf /var/lib/apt/lists/*
#Create virtualenv
RUN python3 -m venv ${APP_ROOT}/.venv --system-site-packages
install pip packages on venv
COPY requirements-release.txt /requirements-release.txt
RUN . ${APP_ROOT}/.venv/bin/activate &&
pip3 install --upgrade pip && pip3 install -r requirements-release.txt &&
pip3 install pyqt5 &&
rm requirements-release.txt
#Copy the application source code in the workspace to the $APP_ROOT directory
#path inside the container, where $APP_ROOT is the torizon_app_root
configuration defined in settings.json
COPY ./src ${APP_ROOT}/src
WORKDIR ${APP_ROOT}
ENV APP_ROOT=${APP_ROOT}
ENV QT_QPA_PLATFORM=linuxfb
DISPLAY=:0
PYTHONUNBUFFERED=1
DEBIAN_FRONTEND=“noninteractive”
#Activate and run the code
CMD . ${APP_ROOT}/.venv/bin/activate && python3 -u src/main.py --no-sandbox
Could you please guide me on how to correctly install PySide2 or PyQt5 inside this container using the Torizon IDE extension?
I understand your PySide2/PyQt5 installation issues on Torizon OS 7.3.0. Based on the documentation, let me guide you through the correct approach for Qt-based Python applications on Torizon.
The Python Console Application template you’re using is designed for console-only applications(1). For GUI applications with Qt/PySide2, you need a different approach since you’re working with graphical interfaces that require Wayland support.
For Qt-based applications on Torizon, you should use the appropriate Qt containers. The documentation shows that Toradex provides specific Qt containers for different platforms(2):
For your Colibri iMX7 (ARM32 architecture), you should use containers from the upstream platform category since iMX7 uses upstream kernels(2):
torizon/qt5-wayland:4 for Qt5 applicationstorizon/qt6-wayland:4 for Qt6 applicationsBased on the Qt project importing guidance(3), here’s the corrected approach for your Dockerfile:
ARG IMAGE_ARCH=
ARG BASE_VERSION=4
ARG APP_ROOT=
FROM --platform=linux/${IMAGE_ARCH} torizon/qt5-wayland:${BASE_VERSION} AS deploy
ARG IMAGE_ARCH
ARG APP_ROOT
# Install Python and PySide2 packages
RUN apt-get -q -y update && \
apt-get -q -y install \
python3-minimal \
python3-pip \
python3-venv \
python3-pyside2.qtcore \
python3-pyside2.qtwidgets \
python3-pyside2.qtgui \
python3-pyside2.qtqml \
python3-pyside2.qtquick \
&& apt-get clean && apt-get autoremove && \
rm -rf /var/lib/apt/lists/*
# Create virtualenv with system packages access
RUN python3 -m venv ${APP_ROOT}/.venv --system-site-packages
# Copy and install requirements
COPY requirements-release.txt /requirements-release.txt
RUN . ${APP_ROOT}/.venv/bin/activate && \
pip3 install --upgrade pip && \
pip3 install -r requirements-release.txt && \
rm requirements-release.txt
# Copy application source
COPY ./src ${APP_ROOT}/src
WORKDIR ${APP_ROOT}
ENV APP_ROOT=${APP_ROOT}
ENV QT_QPA_PLATFORM=wayland
ENV DISPLAY=:0
ENV PYTHONUNBUFFERED=1
ENV DEBIAN_FRONTEND="noninteractive"
# Run the application
CMD . ${APP_ROOT}/.venv/bin/activate && python3 -u src/main.py
torizon/arm32v7-debian-wayland-base:3.0 to torizon/qt5-wayland:4(2)QT_QPA_PLATFORM=linuxfb to QT_QPA_PLATFORM=wayland for proper GUI supportpython3-pyside2.* instead of pip installation for better compatibility(3)4 tags for Torizon OS 7(2)For the VS Code extension, you’ll need to configure dependencies properly. Based on the Qt importing example(3), add these to your project configuration:
Build Dependencies (devpackages):
python3-dev:#%platform.debian-arch%#
python3-pyside2.qtcore:#%platform.debian-arch%#
python3-pyside2.qtwidgets:#%platform.debian-arch%#
python3-pyside2.qtgui:#%platform.debian-arch%#
Runtime Dependencies (extrapackages):
python3-minimal
python3-pyside2.qtcore
python3-pyside2.qtwidgets
python3-pyside2.qtgui
python3-pyside2.qtqml
python3-pyside2.qtquick
Create a proper Qt project structure following the guidance from the Qt importing documentation(3). Your main.py should properly initialize the Qt application for Wayland environment.
If your application needs hardware access (like GPIO, serial ports), add the necessary user groups as shown in the Qt importing example(3):
RUN usermod -a -G dialout torizon
The key issue was using the wrong base container and trying to install Qt packages via pip instead of using the pre-configured Qt containers that Toradex provides specifically for GUI applications.
Best regards, Toradex AI Assistant.
Did you like my answer?
If I answered your question, please tick the “Solution” checkbox.
For follow-up questions to me, please use @ToradexAI in your post.
Will this template work for a Qt-based Python UI project?
It can work though of course the console template has nothing installed or configured for graphics. Meaning you need to do this all yourself in the project.
Could you please guide me on how to correctly install PySide2 or PyQt5 inside this container using the Torizon IDE extension?
Are you installing these in Dockerfile or Dockerfile.debug in your project? One is used in the release configuration while the other is used during the debug configuration. If you’re running the debug configuration but putting the packages in Dockerfile then you wouldn’t see the packages installed of course.
Perhaps use this method instead to install your packages: Add Packages, Libraries, Tools and Files | Toradex Developer Center
This should place the packages into the correct Dockerfile.
Best Regards,
Jeremias
After following the suggested steps, I was able to successfully install PySide2 inside my container. However, when I try to re-run the project, I encounter the following error in VS Code:
TOR Extension: toradex.apollox-vscode@3.1.1
Please make sure to reload the VS Code Window if you had initialization errors
Docker container registry is not running!
Error cause: Not configured
The terminal process “xonsh ‘.conf/validate-deps-running.xsh’” terminated with exit code: 1.
However, my local Docker registry is running inside WSL, as shown below:
torizon@Lenovo~/octoProject: docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
64f2e62a0ed4 registry:2 “/entrypoint.sh /etc…” 35 minutes ago Up 35 minutes 0.0.0.0:5002->5000/tcp, [::]:5002->5000/tcp registry
When I check the registry, it responds correctly:
torizon@Lenovo~/octoProject: curl http://localhost:5002/v2/_catalog
{“repositories”:[“demo2”,“demo2-debug”]}
So the registry seems to be running fine, but the Torizon IDE extension still reports it as “not running.”
Could someone please help me understand why this happens and how to fix it @ToradexAI ?
I understand your Docker registry detection issue. Based on the documentation, this is a common problem with WSL environments and the Torizon IDE Extension.
The Torizon IDE Extension performs automatic dependency validation through the validate-deps-running task(1). This task checks if required services are running, including the local Docker registry that’s essential for the development workflow(2).
The documentation indicates that WSL environments can have specific networking challenges with the Torizon extension(3). During project creation, the extension runs several initialization tasks(2):
run-torizon-binfmt: Registers foreign architecture interpretersrun-docker-registry: Runs a local Docker registryrun-share-wsl-ports (Windows-only): Makes WSL services accessible from external networksThe run-share-wsl-ports task is particularly important for WSL users(2). It runs a PowerShell script that binds necessary ports in WSL to make them accessible from the target device, requiring administrator permissions.
The extension uses a specific script to verify running dependencies(1):
📜 validate-deps-running.xsh
This script checks if dependency processes are running and is used by the validate-deps-running task(1). When this validation fails, you get the “Docker container registry is not running!” error.
Based on the documentation, here are the recommended solutions:
The FAQ mentions that Docker-related issues on Windows can often be resolved by restarting the Docker daemon(4):
The only solution at the moment is to restart the Docker daemon on your host machine(4).
Since you’re using WSL, ensure the run-share-wsl-ports task completed successfully(2). This task should have opened a User Account Control window requiring administrator permissions.
The extension specifically recommends reloading the VS Code window after initialization errors(2). Use Ctrl+Shift+P and run “Developer: Reload Window”.
You can manually trigger the registry setup using the workspace tasks(1). The extension provides a run-docker-registry task that can be executed manually.
The extension uses the .conf directory structure(1) to manage project dependencies and validation scripts. The validate-deps-running.xsh script specifically checks for the registry service availability.
If the automatic detection continues to fail, you can try:
The registry detection issue is typically related to the WSL networking configuration and the extension’s dependency validation process. Following the reload and restart procedures should resolve the detection problem.
Best regards, Toradex AI Assistant.
Did you like my answer?
If I answered your question, please tick the “Solution” checkbox.
For follow-up questions to me, please use @ToradexAI in your post.
I did above steps but again getting same error what another way to solve this issue @ToradexAI
I understand you’re still experiencing the Docker registry detection issue. Let me provide additional troubleshooting approaches based on the documentation.
Since the automatic detection is failing, you can configure the registry manually. The documentation shows how to set up a local registry as a pull-through cache(1):
Create a custom config.yml file:
version: 0.1
log:
fields:
service: registry
storage:
cache:
blobdescriptor: inmemory
filesystem:
rootdirectory: /var/lib/registry
proxy:
remoteurl: https://registry-1.docker.io
http:
addr: :5000
headers:
X-Content-Type-Options: [nosniff]
health:
storagedriver:
enabled: true
interval: 10s
threshold: 3
Use this docker-compose file to run the registry with proper configuration(1):
version: "3"
services:
docker-registry:
container_name: docker-registry
image: registry.hub.docker.com/library/registry:2
ports:
- 5000:5000/tcp
volumes:
- ./config.yml:/etc/docker/registry/config.yml
- ${HOME}/registry:/var/lib/registry
restart: unless-stopped
Configure your Docker daemon to use the local registry. Create or modify /etc/docker/daemon.json in WSL(1):
{
"registry-mirrors" : ["<host-machine-ip>:5000"]
}
A common issue is that ARM emulation becomes disabled. The documentation states that “Enabling Arm emulation through this method is NOT persistent. After reboots, you have to run this command again to re-enable Arm emulation”(2).
Run this command to re-enable ARM emulation(2):
$ docker run --rm -it --privileged torizon/binfmt
For WSL environments, there are specific date/time synchronization issues that can affect Docker operations(3). If you’re experiencing certificate-related errors, run this in PowerShell with admin privileges(3):
$ wsl --shutdown
Based on community feedback, ensure your registry is properly accessible. The community documentation suggests checking these specific configurations(4):
The extension provides specific scripts for dependency management(5). You can manually execute the registry setup task:
run-docker-registry task from the workspace tasksvalidate-deps-running.xsh script manually to see detailed error messagesIf all else fails, try this complete reset approach:
docker stop $(docker ps -aq)docker rm $(docker ps -aq)wsl --shutdown in PowerShell (admin)The persistent registry detection issue in WSL environments often requires this combination of ARM emulation re-enablement and proper registry configuration rather than relying solely on the extension’s automatic setup.
Best regards, Toradex AI Assistant.
Did you like my answer?
If I answered your question, please tick the “Solution” checkbox.
For follow-up questions to me, please use @ToradexAI in your post.
Stop all containers: docker stop $(docker ps -aq)
Remove all containers: docker rm $(docker ps -aq)
Restart WSL: wsl --shutdown in PowerShell (admin)
Re-enable ARM emulation: Run the binfmt command above
Start fresh registry: Use the docker-compose approach
Reload VS Code: Developer: Reload Window
thank you for response i follow above step again getting that error @ToradexAI
Since the standard troubleshooting steps haven’t resolved the registry detection issue, let me provide additional diagnostic approaches based on the documentation.
The documentation emphasizes that you should only have one Docker installation - either Docker Engine or Docker Desktop, not both(1). For WSL environments, Docker Engine is specifically recommended(1):
# Verify only Docker Engine is running
$ docker --version
Since your registry is responding to curl localhost:5002/v2/_catalog, but the extension can’t detect it, there may be a port binding issue. The extension expects the registry to be accessible from the target device(2).
Test registry accessibility from different interfaces:
# Test all interfaces
$ curl http://127.0.0.1:5002/v2/
$ curl http://localhost:5002/v2/
$ curl http://0.0.0.0:5002/v2/
$ curl http://[your-wsl-ip]:5002/v2/
The community documentation indicates that WSL networking can cause registry access issues(2). The extension’s run-share-wsl-ports task should handle this(3), but you can manually verify:
# Check if registry is bound to all interfaces
$ netstat -tulpn | grep :5002
The extension uses specific scripts for dependency validation(4). You can manually run the validation script to see detailed error messages:
# Navigate to your project directory
$ cd /path/to/your/project
$ xonsh .conf/validate-deps-running.xsh
Based on the community troubleshooting guide(2), configure your registry to bind to all interfaces instead of localhost:
# Stop current registry
$ docker stop registry
# Start registry bound to all interfaces
$ docker run -d \
--restart=always \
--name registry \
-p 0.0.0.0:5002:5000 \
registry:2
Ensure Docker daemon in WSL recognizes the local registry as insecure. Create/modify /etc/docker/daemon.json(2):
{
"insecure-registries": ["localhost:5002", "127.0.0.1:5002", "0.0.0.0:5002"]
}
Then restart Docker service:
$ sudo systemctl restart docker
The extension has a specific dependency checking mechanism(3). Try running the dependency check task manually:
Ctrl+Shift+P)If port 5002 continues to have issues, try using the standard registry port 5000(5):
$ docker run -d \
--restart=always \
--name registry \
-p 5000:5000 \
registry:2
Then update your VS Code workspace settings to use port 5000 instead of 5002.
Check if the extension can reach your WSL IP from Windows. From Windows Command Prompt:
# Test connectivity to WSL registry
curl http://[your-wsl-ip]:5002/v2/
If this fails, the issue is WSL networking configuration rather than the registry itself.
Check the VS Code Output panel for detailed extension logs:
Ctrl+Shift+U)The persistent registry detection issue suggests a networking configuration problem between the extension’s validation script and your WSL registry setup, rather than the registry itself being non-functional.
Best regards, Toradex AI Assistant.
Did you like my answer?
If I answered your question, please tick the “Solution” checkbox.
For follow-up questions to me, please use @ToradexAI in your post.
[11-04 11:56:40.610] ERROR :: validate-deps-running failed with exit code 1
[11-04 12:02:01.303] ERROR :: validate-deps-running failed with exit code 1
[11-04 12:30:34.661] ERROR :: validate-deps-running failed with exit code 1
TOR Extension: toradex.apollox-vscode@3.1.1
Please make sure to reload the VS Code Window if you had initialization errors
Docker container registry is not running!
Error cause: Not configured
The terminal process “xonsh ‘.conf/validate-deps-running.xsh’” terminated with exit code: 1.
Terminal will be reused by tasks, press any key to close it.
PS C:\Windows\system32> curl http://172.29.76.240:5002/v2/
StatusCode : 200
StatusDescription : OK
Content : {}
RawContent : HTTP/1.1 200 OK
Docker-Distribution-Api-Version: registry/2.0
X-Content-Type-Options: nosniff
Content-Length: 2
Content-Type: application/json; charset=utf-8
Date: Tue, 04 Nov 2025 07:02:51 GMT
…
Forms : {}
Headers : {[Docker-Distribution-Api-Version, registry/2.0], [X-Content-Type-Options, nosniff],
[Content-Length, 2], [Content-Type, application/json; charset=utf-8]…}
Images : {}
InputFields : {}
Links : {}
ParsedHtml : mshtml.HTMLDocumentClass
RawContentLength : 2
PS C:\Windows\system32> netsh interface portproxy add v4tov4 listenport=5000 listenaddress=0.0.0.0 connectport=5000 connectaddress=172.29.26.240
PS C:\Windows\system32> curl http://172.29.76.240:5000/v2/
curl : Unable to connect to the remote server
At line:1 char:1
+ CategoryInfo : InvalidOperation: (System.Net.HttpWebRequest:HttpWebRequest) [Invoke-WebRequest], WebExc
eption
+ FullyQualifiedErrorId : WebCmdletWebResponseException,Microsoft.PowerShell.Commands.InvokeWebRequestCommand
see i did this but same issue @ToradexAI
I can see from your logs that the registry is accessible from Windows (HTTP 200 response), but the extension’s validation script is still failing. Based on the documentation, this points to a specific configuration issue.
The error “Docker container registry is not running! Error cause: Not configured” indicates that the extension’s validation script validate-deps-running.xsh(1) cannot detect your registry configuration, even though the registry itself is functional.
The Torizon IDE Extension has specific requirements for registry detection during project initialization(2). During the first load of a new project, several tasks are triggered(2):
run-torizon-binfmt: Registers foreign architecture interpretersrun-docker-registry: Runs a local Docker registryrun-share-wsl-ports (Windows-only): Makes WSL services accessible from external networks(2)Since the automatic detection is failing, try manually executing the registry setup task. The extension provides workspace tasks(1) that can be run independently:
Ctrl+Shift+P)run-docker-registryrun-share-wsl-portsvalidate-deps-runningYour registry is running on port 5002, but the extension may expect port 5000. The documentation shows registry configuration using port 5000(3). Try reconfiguring your registry:
# Stop current registry
$ docker stop registry
$ docker rm registry
# Start registry on standard port 5000
$ docker run -d \
--restart=always \
--name registry \
-p 0.0.0.0:5000:5000 \
registry:2
The run-share-wsl-ports task is critical for Windows/WSL setups(2). This task runs a PowerShell script that binds necessary ports in WSL to make them accessible from the target device, requiring administrator permissions(2).
If this task didn’t complete successfully during project initialization, manually run it:
.conf directory(1)Since the validation continues to fail, try resetting the extension’s workspace configuration:
.conf/.docok file(1) (this forces re-initialization)If the extension’s automatic setup continues to fail, you can manually configure the workspace settings to point to your working registry. The extension uses workspace structure files(1) to manage project configuration.
The persistent “Not configured” error suggests the extension’s initialization process didn’t complete successfully, rather than a registry connectivity issue. Focus on re-running the extension’s setup tasks manually rather than registry troubleshooting.
Best regards, Toradex AI Assistant.
Did you like my answer?
If I answered your question, please tick the “Solution” checkbox.
For follow-up questions to me, please use @ToradexAI in your post.
As the AI has suggested it looks like the local container registry that is used by the extension is not running when it should be. The extension should automatically try to start this, but you can manually try to start it by running the tasks suggested by the AI.
Or you could try to reinstall/restart the extension to see if that fixes it. If the issue persists then there might be something else wrong with your environment that is preventing the local registry and extension from working properly.
Best Regards,
Jeremias
After reinstalling Torizon and setting up my environment again, I was able to build, push, and pull successfully. However, when I start debugging, I get the following error:
Executing task: ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no -p 6502 torizon@192.168.225.246 cd /home/torizon/app && . /home/torizon/app/.venv/bin/activate && screen -d -m python3 -m debugpy --listen 0.0.0.0:6512 --log-to src/log --wait-for-client src/main.py
ssh: connect to host 192.168.225.246 port 6502: Connection refused
Give suggestion to solve this issue @ToradexAI
The SSH connection error you’re experiencing indicates that the debug session cannot establish a connection to your target device on port 6502. Based on the documentation, this is a common SSH connectivity issue that can be resolved through several approaches.
First, check if SSH is running on your target device. The documentation explains that SSH is configured as a service started by systemd’s socket activation method(1). Connect to your device via serial console and check the SSH service status:
# systemctl status sshd.socket
The standard SSH connection should use port 22, not 6502(1). The VS Code extension appears to be trying to use a custom port. Try establishing a basic SSH connection first:
ssh torizon@192.168.225.246
Based on the documentation, you can connect using either the IP address or hostname(1):
The documentation confirms that for Torizon OS, the default SSH user is configured as torizon with password torizon(1). The torizon user has root privileges and you can execute sudo and su just like on a regular desktop Linux distro(1).
If you’re experiencing connection issues, the documentation provides specific troubleshooting steps(1):
# Check SSH connection attempts and active connections
# systemctl status sshd.socket
# Print log messages related to the SSH server
# journalctl -u sshd*
Verify basic network connectivity to your device:
# Test basic connectivity
ping 192.168.225.246
# Check if standard SSH port is accessible
telnet 192.168.225.246 22
The error suggests the VS Code extension is trying to use port 6502 for SSH, which is non-standard. Check your VS Code launch configuration and ensure it’s using the correct SSH parameters. The extension should be configured to use:
Before debugging, ensure your device is properly connected through the Torizon extension(1):
If SSH continues to fail, you can establish connection using the serial console for debugging(2). The serial console provides direct access to your device and can help verify if the SSH service is running properly.
The core issue appears to be that the VS Code extension is attempting to connect on port 6502 instead of the standard SSH port 22. Check your debug configuration settings and ensure they align with the standard SSH connection parameters documented for Torizon devices.
Best regards, Toradex AI Assistant.
Did you like my answer?
If I answered your question, please tick the “Solution” checkbox.
For follow-up questions to me, please use @ToradexAI in your post.
I found where the issue occurs. I had set the password “toradex” to imx7 torizon, but it seems the system expects “torizon”, which is why SSH is failing.
In my settings.json, I have the following:
“torizon_login”: “torizon”,
“torizon_ip”: “192.168.225.246”,
“torizon_psswd”: “toradex”,
Should I change anything in tasks.json as well?
Here is my current SSH configuration:
“args”: [
“-o”,
“UserKnownHostsFile=/dev/null”,
“-o”,
“StrictHostKeyChecking=no”,
“-p”,
“${config:torizon_debug_ssh_port}”,
“${config:torizon_run_as}@${config:torizon_ip}”,
“pkill python3 || true”
],
Do I need to add or modify any variable here, or did I make a mistake elsewhere @ToradexAI ?
You’ve identified the exact issue! The password mismatch is causing the SSH authentication failure. Based on the documentation and your VS Code configuration, here are the corrections needed.
The documentation confirms that the default credentials for Torizon are username: torizon and password: torizon(1). Your current configuration has:
"torizon_login": "torizon",
"torizon_psswd": "toradex",
This should be changed to:
"torizon_login": "torizon",
"torizon_psswd": "torizon",
Your SSH configuration is using ${config:torizon_debug_ssh_port}, but the standard SSH connection should use port 22(1). The VS Code extension workspace structure includes settings that control these parameters(2).
In your settings.json, you need to ensure these configurations are correct:
{
"torizon_login": "torizon",
"torizon_ip": "192.168.225.246",
"torizon_psswd": "torizon",
"torizon_debug_ssh_port": "22",
"torizon_run_as": "torizon"
}
Your current tasks.json SSH configuration looks correct(2):
"args": [
"-o",
"UserKnownHostsFile=/dev/null",
"-o",
"StrictHostKeyChecking=no",
"-p",
"${config:torizon_debug_ssh_port}",
"${config:torizon_run_as}@${config:torizon_ip}",
"pkill python3 || true"
]
The variables are properly referencing the settings.json configuration. No changes should be needed in tasks.json if your settings.json is corrected.
The VS Code extension uses the .vscode/settings.json file to store project settings(2). This file is used by VS Code and the extension to configure project parameters including SSH connection details(2).
After making these changes:
ssh torizon@192.168.225.246(1)The issue was indeed the password mismatch. The extension expects the default Torizon credentials, and your manual password change to “toradex” was causing the authentication failure during the debug session setup.
Best regards, Toradex AI Assistant.
Did you like my answer?
If I answered your question, please tick the “Solution” checkbox.
For follow-up questions to me, please use @ToradexAI in your post.
Are you sure the issue is related to the password? When you add your device to the VSCode extension it prompts you for the username and password on the device. If these were incorrect the device would not have been able to connect in the first place at all.
It could be a firewall or some other network related issue that is giving you connection issues.
Best Regards,
Jeremias