DEV Community

Sattyam Jain
Sattyam Jain

Posted on

Pin your Jetson to TensorRT 10.x on purpose, not by accident

Short version: NVIDIA's TensorRT 11.x line does not support JetPack, and DLA
support ended at 10.7. If you are on a Jetson, you are on 10.x. Here is how I
turned that from a surprise into a written-down pin.

The two sentences, from the TensorRT 11.2.1 release notes:

"NVIDIA JetPack is not supported in TensorRT 11.2.1. Jetson deployments must
remain on a TensorRT 10.x release supported by their JetPack version."

"DLA is not supported in TensorRT 11.0, 11.1, or 11.2. TensorRT 10.7 was the
last release that supported DLA."

Step 1: find out what you are actually on

Do not trust your notes. Ask the board.

dpkg -l | grep -i tensorrt
cat /etc/nv_tegra_release
python3 -c "import tensorrt; print(tensorrt.__version__)"
Enter fullscreen mode Exit fullscreen mode

The third one is the number that matters at runtime. The first two tell you
which JetPack fixed it there.

Step 2: write the pin down as a decision

I keep a single file at the repo root. Not a comment buried in a Dockerfile.

# PINS.md
## tensorrt
version: 10.x (whatever JetPack ships)
reason: TensorRT 11.x does not support JetPack; DLA ended at 10.7.
source: TensorRT 11.2.1 release notes
decided: 2026-08-04
revisit: when NVIDIA publishes a JetPack that carries an 11.x runtime
owner: me
Enter fullscreen mode Exit fullscreen mode

The revisit line is the whole point. A pin with an expiry condition is a
decision. A pin without one is an accident you will rediscover mid-port.

Step 3: fail the build if the assumption breaks

Cheap guard, runs in CI or on the board:

#!/usr/bin/env bash
set -euo pipefail
ver=$(python3 -c "import tensorrt; print(tensorrt.__version__)")
major=${ver%%.*}
if [ "$major" != "10" ]; then
  echo "TensorRT major is $major, expected 10. Read PINS.md before continuing."
  exit 1
fi
echo "TensorRT $ver, pin holds."
Enter fullscreen mode Exit fullscreen mode

Now the next person who runs an unattended apt upgrade gets a sentence instead
of a linker error.

Step 4: audit your stale dependencies while you are in there

The port that started all this also made me check what else I had inherited.
nanoowl, NVIDIA's own open-vocabulary detection sample for Jetson, last shipped
a commit on 6 February 2025. That is 544 days at the time of writing. It still
works. But a dependency that has not moved since before your project started is
a dependency you maintain now, whether you signed up or not.

Quick way to see all of them at once:

for d in $(ls -d third_party/*/); do
  printf "%-30s %s\n" "$d" "$(git -C $d log -1 --format=%cs 2>/dev/null || echo 'not a repo')"
done
Enter fullscreen mode Exit fullscreen mode

Sort that output. Anything older than your project's first commit needs a
decision: vendor it and own it, or replace it.

What I am doing with mine

Pinning 10.x deliberately, moving perception off nanoowl, and measuring my own
sustained numbers before I trust anyone else's, including the ones I quoted in
the longer write-up. Every demo number in edge inference is the cold number, and
the number that decides whether your control loop holds is p99 after the
heatsink is warm.

If you are running a small VLA or a multimodal policy on Orin-class hardware, I
would like to compare notes on the sustained figures.

Top comments (0)