JetPack SDK in Docker for simple and clean flashing of a Jetson TX2

The Jetson Platform is nice — the JetPack SDK, not so much…

NVIDIA has developed a very performant System-on-Module product line called Jetson (TK1, TX1, TX2, Xavier, Nano) that is being used by many robotics engineers, AI researchers and hobbyists.

While the system itself is very nice, the process of flashing and maintenance often leads to painful tries and causes frustrations. The official boards are full with installation, USB, flashing issues. These are: incompatibilities with VMs, broken host nvidia-container-runtime, serial port access, broken CUDA on host, etc.

To give some help with these issues we created a simple Dockerfile and accompanying scripts that put everything that is needed for flashing into a docker image (JetPack SDK Manager). This guide gives info on how to use the code in the repository:

https://github.com/trn84/docker-jetpack-sdk

Repository Structure

The repository basically consists of four files:

• Dockerfile
• entrypoint.sh
• build.sh
• run.sh

You will need another file from the official NVIDIA website which is the sdkmanager itself since it is only accessible after registering and logging into their website.

Let us take a look into the short Dockerfile. We have to add our current user during build time of the image into the system since the sdkmanager will not start as root (typically used with docker). It will also make the user sudo so that we can add software during run time. The rest are just some dependencies that are required and then the actual copy of the sdkmanager_1.0.1–5538_amd64.deb into the image. Be aware that the name of your file is correct. Finally, we copy the entrypoint.sh and set it as the docker entrypoint. For completeness here the Dockerfile:

FROM ubuntu:18.04
ARG USER_ID
ARG GROUP_ID
# Add user to sudoers
RUN apt-get update && apt-get install -y sudo
RUN addgroup — gid $GROUP_ID user
RUN adduser — disabled-password — gecos ‘’ — uid $USER_ID — gid $GROUP_ID user
RUN adduser user sudo
RUN echo ‘%sudo ALL=(ALL) NOPASSWD:ALL’ >> /etc/sudoers
USER user
# Install SDK deps
RUN sudo apt-get update && sudo apt-get install -y \
 libgconf-2–4 \
 libcanberra-gtk-module \
 locales \
 netcat \
 openssh-server \
 usbutils \
 libgtk-3–0 \
 libx11-xcb-dev \
 libxss-dev \
 libnss3 \
 libcanberra-gtk-module \
 libcanberra-gtk3-module \
 nodejs \
 firefox \
 npm
COPY sdkmanager_1.0.1–5538_amd64.deb /
COPY entrypoint.sh /entrypoint.sh
RUN sudo apt-get install -y /sdkmanager_1.0.1–5538_amd64.deb
ENTRYPOINT [ “/entrypoint.sh” ]

We will investigate the entrypoint.sh now. This script is automatically executed when the container is started and basically spins up the SDK manager executable. We will run the SDK manager in CLI mode since the GUI mode was not working yet (blank white screen). The parameters are set to directly install and flash a Jetson TX2 Development board:

sdkmanager \
 — cli install \
 — user your.user@email.com\
 — password your.pass\
 — logintype devzone \
 — product Jetson \
 — version 4.3 \
 — targetos Linux \
 — host \
 — target P3310 \
 — flash \
 — license accept

Do not forget to set your credentials here to log in to the devzone. These are the two important files. The build and run scripts are you standard docker commands. In the build.sh we need to provide the current user as build argument:

docker build -t jetpack-sdk \
 — build-arg USER_ID=$(id -u) \
 — build-arg GROUP_ID=$(id -g) .

And in the run.sh we have to be careful to forward everything into the container that is needed for accessing the USB controller as well as the network for completion of the installation process:

#xhost +local:$USER
docker run -it \
 — name=jetpack-sdk \
 — rm=true \
 — net=host \
 — ipc host\
 — privileged \
 — volume=”/dev/bus/usb:/dev/bus/usb” \
 — user “$(id -u):$(id -g)” \
 — env=”DISPLAY=$DISPLAY” \
 — env=”QT_X11_NO_MITSHM=1" \
 — volume=”/tmp/.X11-unix:/tmp/.X11-unix:rw” \
 jetpack-sdk /bin/bash

The xhost command in the beginning is probably not needed when the container is used on the localhost. When using a remote setup it could be helpful. Please keep in mind that the SDK manager expects a display even in CLI mode. If you want to execute this on a server maybe xvfb-run could help.

Step-by-Step Guide

To build everything you need to flash and install a Jetson TX2 Development Board follow these steps:

1. Log in and Download the sdkmanager.deb: https://developer.nvidia.com/nvidia-sdk-manager . Copy the file next to the Dockerfile.
2. Make sure to edit your credentials into the entrypoint.sh.
3. Execute the ./build.sh script.
4. If everything build correctly you can execute the ./run.sh (be sure to be the same user logged in as during the build).
5. Follow the steps in the SDK manager…Press a key to cancel the automated process.

After the last step you should see the CLI menu like in the following picture:

JetPack SDK Manager in CLI Install Mode

One advice for faster spin-up times is the removal of the rm flag in the run script and committing of the container after you have downloaded everything:

docker commit jetpack-sdk jetpack-sdk:downloaded

Now if you replace the image name in the run.sh you can directly start the flash, install, etc.

Another advice, if you do not want to automatically download, flash, install your devices you can override the entrypoint.sh in the run.sh by adding a parameter:

--entrypoint=

This will avoid auto execution since sometimes when you want to make a clone of the flash memory you need to merely execute the flash.sh individually.

Conclusion

This mini guide showed how to easily put the NVIDIA JetPack SDK Manager into a docker image so that you do not touch your host system and do not need to use sudo and install anything. The CLI parameters from the sdkmanager executable can be adjusted to either automate the complete flash process or make it manual.

Unfortunately, this does not circumvent or explain why some computers are not capable at all to flash with this tooling. In our experience only one in four systems the USB bus/controller is recognized by the SDK/Jetson. Atleast, trying out is much easier with having everything in one docker image ;-)