I connect in vscode to the Ubuntu host in the working directory via ssh. When I start a terminal there, the sourcing of the tcb-env-setup.sh no longer works.
Hi, I’m the Toradex AI Assistant. The Toradex Support team will follow up with you shortly!
Did you like my answer?
Based on the context provided, it seems that the issue with sourcing the tcb-env-setup.sh script in the VS Code terminal when connected via SSH to the Ubuntu host is likely due to misconfigurations in the terminal setup or the activation of the Torizon IDE extension. Here are some steps you can take to resolve the issue:
Check Terminal Settings: Ensure that the VS Code terminal is configured to use the correct shell. You may need to adjust the terminal profile settings in VS Code to ensure that it sources the tcb-env-setup.sh script upon startup.
Activate Torizon IDE Extension in Workspace: Since the Torizon IDE extension is not activated in the current workspace, activate it to ensure that all necessary tools and configurations are available. This might help in setting up the environment correctly.
Manual Sourcing: As a temporary workaround, manually source the tcb-env-setup.sh script in the terminal after connecting via SSH by executing the command source ~/Toradex/tcb/tcb-env-setup.sh. This should help in setting up the environment for the current session.
Verify SSH Configuration: Check the SSH connection settings to ensure that the terminal environment is correctly loading the necessary scripts and configurations. This might involve checking any SSH configuration files or settings that could affect the terminal environment.
By following these recommendations, you should be able to resolve the issue and ensure that the TorizonCore Builder environment is set up correctly in your VS Code terminal.
Please, also check if these links can help you solve your problem:
The information you provided here is a bit confusing. Let me try to understand here. So you said:
I connect in vscode to the Ubuntu host in the working directory via ssh.
I understand this to mean from your Windows PC you use VSCode to open a terminal via SSH to your Ubuntu PC. Is that correct?
But then you say:
looks like I’m inside an Apalis module
And looking at the information from docker info. It looks like the terminal is for one of our Apalis i.MX8 devices?
So then what machine is your terminal in VSCode connected to? Is it connected to your Ubuntu PC or a Toradex SOM?
As the error message suggests there is no arm variant of the TorizonCore Builder tool. It’s designed to run on a development machine like your Ubuntu 22.04 amd64 PC.
I use this approach: https://code.visualstudio.com/docs/remote/ssh to open a directory on an amd64 (x86_64) computer.
Here I can start a terminal in vscode. This is a ‘normal’ terminal that runs on the Ubuntu machine in the directory where my Torizon Core Builder files are located… please look at the screenshot.
In an SSH session in this directory outside of VSCode everything works fine.
The problem must be somehow in VSCode plus Docker and Torizon Extension.
I’ve had similar problems several times before. Only a complete reinstallation helped. I would now like to find a better solution.
I use the same Ubuntu computer to develop .NET Core or C console applications using the Torizon Core IDE. Perhaps the solution can be found here. The keyword here would be arm64 emulation.
Based on your info from docker info however, it would appear that at least Docker is being executed from the perspective of the Apalis i.MX8 and not your Ubuntu machine.
Maybe some of the environment variables from our IDE extension are somehow being passed to the remote SSH terminal. In particular one variable our extension sets and uses is DOCKER_HOST. This environment variable controls which Docker daemon the docker command targets.
In our IDE extension the variable can be set to target the Docker daemon running on the target Toradex SoM. Perhaps this is getting set in your remote SSH terminal environment as well. This would explain why the docker operations are being ran from the perspective of an arm64 machine. Try running printenv in your remote SSH terminal to see if this theory is correct.
If it is true, then you can try to unset DOCKER_HOST in your remote terminal environment. Or even include DOCKER_HOST= before each docker (and torizoncore-builder) related command that you run on that terminal.
…
Yes, it was a direct hit.
In a parallel TorizonCoreIDE workspace, the DOCKER_HOST variable was set to an Apalis module. You can temporarily reset this with every Docker-relevant call using DOCKER_HOST= docker ....
You can also deselect the respective device within the TorizonCoreIDE, which has the same effect, but then permanently.
