VS-Code Torizon Extension v2 (Apollo X) issue with starting SDK as devcontainer

Technical Support
, ,
#1

Hi, I’m running VS-Code with the Apollo X extension 0.0.66 in a native Debian Linux with Docker installed and can’t get running the SDK in a devcontainer.
The target device is a Rapberry Pi 3 with TorizonCore 6.0.0-devel installed and it is recognized under the extensions “CONNECTED DEVICES”.
I did the following steps:

  • Created a new single container project
  • Selected C++ Console Application Template
  • Tried to open the folder in a devcontainer
  • Selected the Dockerfile.sdk from the generated project with no additional features
  • Set ARG IMAGE_ARCH=arm64 in Dockerfile.sdk
  • Invoked the runner ‘apply-torizon-packages’
  • Invoked the runner ‘build-container-image-sdk-arm64’
  • In VS-Code devcontainers: Rebuild and reopen in devcontainer

Then devcontainers starts to build the image:

docker buildx build --load --build-arg BUILDKIT_INLINE_CACHE=1 -f /tmp/devcontainercli-guest/container-features/0.25.2-1673958978801/Dockerfile-with-features -t vsc-deletemeproject-11515f08f5fc5f19fcb3d133a67d144c --target dev_containers_target_stage --build-arg _DEV_CONTAINERS_BASE_IMAGE=dev_container_auto_added_stage_label /media/guest/CRYPTED/workspace/deletemeproject

But then it stops:

> [dev_container_auto_added_stage_label 2/4] RUN apt-get -q -y update &&     apt-get -q -y install     &&     apt-get clean && apt-get autoremove &&     rm -rf /var/lib/apt/lists/*:
#0 1.979 exec /bin/sh: exec format error

The idea is to use the SDK as devcontainer and later build it in the CI/CD pipeline.
How can I accomplish that ?

Thanks
Stephan

#2

Hey millerfield,

Glad to see your using Torizon on a Raspberry Pi!

For clarification:

When you are building and uploading the docker image, are you using steps as described under “Build and Release Docker Image” as found here?: GitHub - toradex/torizon-experimental-torizon-ide-v2-docs: VS Code Torizon Integrated Development Environment Documentation

And once that image is uploaded/running on the pi, are you using the windows extension Remote Development to try and reopen the deployed image?

As well: The error exec format error is usually in reference to architecture incompatibility.

-Eric

#3

Hi Eric, thanks for the fast response.
Answers to your questions:

The “Build and Release Docker Image” part is rather fine for me. This is what works:

  • It pushes the image to a private repo on Dockerhub successfully. I just couldn’t figure out how to use a local or company registry yet.
  • Debugging works with the Raspberry Pi via the Debugging extension and automatic pull from local registry.
  • Running the image on the Raspberry Pi also works by using docker-compose to pull it from Docker hub and the Docker extension to start it.

The Windows Remote Development extension you noticed includes the Devcontainer and WSL extensions. The development on my machine is running on a native Linux with a Docker instance, so there is only the Devcontainer and not the WSL extension needed to achieve the same result.
So the answer is, that we are not using the Remote Development for deploying and running the release image. We would like to run the SDK-image built by Dockerfile.sdk on the development machine with the Remote Develpoment (or more devcontainer) extension.

I think the devcontainer approach is not covered yet by the documentation, so it’s up to me to find out. This seems to be also related to the exec format error.
I hope I could clarify your questions.

Best regards
Stephan

#4

Hi @millerfield

I think this means you are trying to run ARM64 binaries on your (presumably) AMD64 desktop. From my understanding the Devcontainer is a host-side concept so I don’t think you should be changing IMAGE_ARCH in Dockerfile.sdk. Can you clarify why you are doing that?

Drew

#5

Hi Drew,

I begin to understand more and more.

Without setting the IMAGE_ARCH to arm64, devcontainer wouldn’t start. Then I noticed, that by adding the Raspi-device to the “CONNECTED DEVICES” in the Torizon Extension, the Docker context is set to the device instead of the development host. This is fine but the whole game of the SDK devcontainer is also played on the target device. And thats the problem, the SDK is an amd64 image and pull/build on an arm64 architecture fails, no matter which IMAGE_ARCH is set.

So I need to explain devcontainer to build the image on the developers Docker host machine.

By the way: How is the Dockerfile.sdk intended to be used ?

Stephan

#6

Hi @millerfield

it’s still not clear to me why you want to use Dockerfile.sdk as a devcontainer. In the current workflow this is not necessary. Dockerfile.sdk will be used by VS Code, defined on tasks.json, to cross compile the code for you only for debugging purposes. The final production image will be generated by the Dockerfile multi stage build. We do not build nothing on the target device :thinking:, only run it for debug …

Ok, but I have a guess of what is happening. Could you help reporting your:

With this data I should confirm my guess …

Thanks in advance

#7

Hi Matheus,
the idea is to generate a SDK image per CI-pipeline and push it to a companies container registry. The image contains all needed tools the developer don’t want to bother with. All the different Torizon-projects on the developers machine simply pull and run the common SDK image and the projects are opened within the SDK container. And thats where devcontainer comes into play.
But maybe my understanding is not right the way the extension implies - sorry for that.

So here the information:

  • VS-Code 1.74.3
  • VS Code Docker extension version v1.23.3
  • .vscode/tasks.json is attached

Thanks
tasks.json (50.8 KB)

#8

Hey @millerfield

no problem, ok now I got it. So yeah, as I said above the Dockerfile.sdk is not for the purpose of devcontainers. If you want to use the workflow that was designed for Torizon with our extensions, inside a devcontainer, you will have to create this dev container yourself with DIND (docker in docker) support. Check the .conf/deps.json these are the dependencies per project. In addition there are the common dependencies for the extension:

  • docker
  • docker compose plugin
  • powershell core
  • git
  • nmap
  • avahi-resolve
  • ping
  • file

A devcontainer based on the lts versions of Ubuntu or Debian, with these dependencies installed, should work.

If you want this for a easy of deliver an already set environment to developers it’s it. But if you want this to build the application in a CI/CD pipeline, then the workflow for CI/CD is in development, but you can have a glimpse of it on our development branch:

This is the file that we will use with Github Actions, this will be provided for all the templates. You can note that we are using the same VS Code tasks for execute the CI/CD tasks, so we do not need to rewrite the wheel, the developer will have the same tasks on the pipeline environment.

Let me know if I’ve answered your questions, or if you have more questions feel free to ask, I’m happy to try to clarify.

Best regards,

#9

Hi Matheus,
understood, the Dockerfile.sdk is not intended to be the devcontainer setup.
So I need to seperately setup a devcontainer environment from the deps.json and the additional components for DIND in which all the development lives although there is a multistage build.
The powershell scripts will help us to bring the build/deploy to the CI/CD pipeline.

I think that’s our plan for now. We will see if we can reduce some steps when going to the CI/CD system.

Thanks for your support!

Stephan