JetPack and VPI version mismatch on a GMSL camera: align the L4T

You launch the Argus camera node for a GMSL camera on a Jetson, and the container stops before the first frame: the log reports a VPI library, version 2_3, as missing, then GXF errors about libgxf_argus.so. Meanwhile the v4l2 capture tool still delivers frames, so the camera, the serializer and the link are healthy. The failure sits one layer up, in a version triangle between three artifacts that each pin to one L4T release: the camera vendor's GMSL driver, the Isaac ROS Argus camera nodes and the VPI runtime. Below you map the error to its three version sets, compute the one L4T release every side supports, and run the flash-driver-feed sequence that closes the gap. The worked example follows a real Jetson Orin case on the JetPack 5.1 line that ended with every component on L4T 35.4.1.

What the error actually says

The launch line ros2 launch isaac_ros_argus_camera isaac_ros_argus_camera_mono.launch.py brings up nodes that load userspace libraries at start. The first message means a node asked for the VPI 2.3 build and could not find that version tag among the installed libraries. VPI releases ship inside each JetPack feed, so the tag encodes which JetPack the library was built for.

The reflexive fix, hand-downloading cupva-2.3-l4t_2.3.0_arm64.deb, libnvvpi2_2.3.9_arm64.deb and vpi2-dev_2.3.9_arm64.deb from a repository that was not built for the flashed release, moves the error instead of removing it. The next launch dies inside GXF with dlopen failing to open libgxf_argus.so. A library from the wrong release either misses the requested version tag or loads and cannot resolve the symbols it was compiled against; either way the break appears in the GXF layer, above any camera code.

The kernel side never enters this. That is why v4l2 capture keeps working while the Argus path fails, and the split is the strongest diagnostic on the bench: bring-up problems kill both paths, version mismatches kill only the userspace stack. The same class of breakage, mixed shared-library generations, shows up in other camera stacks as a segfault instead of a clean version error; Segfault when the camera opens: fix mismatched shared libraries walks that variant.

The three version sets that must agree

Three artifacts on a GMSL rig each commit to an exact L4T build. Read all three before installing anything:

On the JetPack 5.1 line the mapping is fixed: 5.1 is L4T 35.2.1, 5.1.1 is 35.3.1 and 5.1.2 is 35.4.1. A driver file whose name ends in 35.4.1 was built against the 35.4.1 kernel, not roughly that release. Multi-camera GMSL rigs that feed stereo rectification stacks inherit all three constraints at once, which is why the intersection below has to be exact.

Likely causes, in order of probability

1. VPI packages from the wrong feed. The error appears right after hand-installing debs, which is the cause announcing itself. Test: list the installed libnvvpi2, vpi2-dev and cupva packages with their source; any file placed by hand instead of pulled through the flashed release's feed is the problem.
2. Container image built for another L4T. Jetson containers draw their GPU userspace from the host, so an image tagged for a different release produces exactly this load failure. Test: compare the image's base tag with the host release string. The choice is per-release, as this L4T container image selection guide for JetPack 6.x walks through.
3. Host moved to a release the vendor driver does not support. An upgrade across a 35.x point release leaves the vendor's kernel modules and device tree out of step. Test: v4l2 capture works while the Argus sample tool argus_camera does not; then read the driver package's stated release against the flashed one. The MIPI-side twin of this coupling is covered in MIPI camera driver install fails on a third-party carrier board.
4. Isaac ROS branch older or newer than the board. Each release of the nodes declares a JetPack requirement. Test: read the setup document of the branch you cloned, not a README from a search result; mid-2023 the Argus camera requirement was 5.1.1, and later branches moved on.

The version intersection for an Orin GMSL camera on JetPack 5.1

Inputs, each with its source:

• Flashed release: L4T 35.2.1 (JetPack 5.1) — the board state in the failure report.
• Vendor driver, first package: supports L4T 35.2.1 — the camera captured through both v4l2 and the Argus sample tool on it.
• Isaac ROS Argus camera requirement: JetPack 5.1.1 (L4T 35.3.1) — stated by the node maintainers in mid-2023.
• Hand-installed VPI set: libnvvpi2 2.3.9, vpi2-dev 2.3.9, cupva 2.3 — pulled from a feed not built for 35.2.1.
• Vendor driver, later package: supports L4T 35.4.1 — published for JetPack 5.1.2, file name ending in 35.4.1.

Rule in words: write down the set of L4T releases each side supports; the flashed release must sit inside the intersection of all three sets. An empty intersection cannot be repaired with packages, because the missing piece is a kernel module and device tree that exist only for releases the vendor has published.

Arithmetic, set by set:

• Driver set 1 against the Argus requirement: {35.2.1} ∩ {35.3.1} = ∅. The board as flashed cannot satisfy the nodes; this is structural, not a missing file.
• Driver set 2 against the Argus line: {35.4.1} ∩ {releases the 5.1.x stack accepts} = {35.4.1}. Exactly one release satisfies both sides.

Result: flash 35.4.1, install the driver package whose name ends in 35.4.1, install VPI from the 5.1.2 feed so libnvvpi2, vpi2-dev and cupva arrive as one matched set, and run containers built on the 5.1.2 base image. In the referenced case this ended both errors; v4l2 capture and the Argus path came up together.

Decision and threshold: an empty intersection means stop installing packages — either reflash to the newest release all three sides publish for, or change the camera interface. A non-empty intersection means flash exactly that one release and take every component from its feed. Until the 35.4.1 driver file existed, no deb could have fixed the 35.2.1 board: the fix was a release, not a file.

The fix: pin one L4T release end to end

1. Read the flashed release string from the board and write it down; every later check compares against it.
2. Read the JetPack requirement in the setup document of the Isaac ROS branch you clone.
3. Read the vendor driver's release from its file name and release note.
4. Compute the intersection as in the worked example. Empty: pick the newest release all three sides publish for and accept the reflash.
5. Flash that release with the JetPack tooling, then configure the camera connector and deserializer before the first capture; the per-camera access steps are in this Orin NX GMSL and FPD-Link III camera access guide.
6. Install the vendor driver built for exactly that release and reboot, so the new modules and overlay are live.
7. Install VPI only through the package feed of the flashed release, so the three packages arrive as one matched set; never place a hand-downloaded deb.
8. Re-pull or rebuild the Isaac ROS containers tagged for that release; the container draws GPU userspace from the host, so the tag must equal the host release.
9. Verify in order: v4l2 capture, the Argus sample tool argus_camera, then ros2 launch isaac_ros_argus_camera isaac_ros_argus_camera_mono.launch.py. When all three pass without the 2_3 error, the triangle is closed.

Write the triangle down before you touch the board

Keep one text file per bench board with four lines: flashed L4T string, vendor driver package name, Isaac ROS branch, container image tags. When any one moves, recompute the intersection before installing anything. The build-side version of this discipline is Docker build SDK version mismatch: pin one library version everywhere, and Edge inference device crashes: fix with SDK version pinning is what drift costs at run time. More version-alignment cases live on the systems troubleshooting hub.

Two neighbouring symptoms have different roots and different fixes. If the LOCK LED stays dark while I2C answers, the link itself never came up; work through GMSL LOCK LED not lighting: I2C works but no video arrives before touching packages. If frames arrive but come out green, or capture times out, the interface is dropping data; that class is covered in these Orin NX GMSL camera VI timeout and green screen fixes.

When the right answer is a different interface

GMSL earns its keep for what it carries: several sensors over thin coax, long runs, hardware triggering. The price is a vendor driver welded to one L4T release, and the triangle above is that price paid at every JetPack refresh. If the run is short and the camera count small, a standard interface removes the entire failure class: a USB3 or GigE board-level camera enumerates as an ordinary device, with no vendor kernel module and no device tree to keep in step.

GigE buys cable length; USB3 buys frame rate. Two catalog cameras show the pattern:

The MV-CB016-10GM-M-W puts a 1.6 MP IMX296 global-shutter sensor behind an M12 mount on GigE. The host treats it as a network device, so the Jetson needs no camera-vendor module and the Argus stack never enters the picture.

For a link inside a meter where the loop rate rules, the USB3 option:

The LS-BCM-0003 reads 3.1 MP at 120 fps over USB3, also global shutter. Nothing on the Jetson side changes at a JetPack refresh, because there is no driver in the triangle at all.

So the decision splits cleanly. If your intersection is non-empty, run the flash-driver-feed sequence and keep one release per board. If it stays empty and the vendor shows no sign of publishing for a release your stack accepts, count cameras, cable runs and bandwidth, then weigh the interface change with the same rigour you gave the version math. If the interface change wins, start from the range:

Pre-flight checklist

Run this before the next flash or the next camera order:

• Ask the camera vendor for the exact L4T of their current driver package and its release date; the file-name tail is the contract.
• Read the JetPack requirement of the Isaac ROS branch you plan to clone, before you clone it.
• Compute the intersection; order hardware or book the reflash only when it is non-empty.
• After flashing, confirm the release string matches the driver package name before installing anything else.
• After the driver install, prove v4l2 capture before starting any ROS node.
• Before the first launch, check that every container tag equals the host release.

Everything above assumes the versions are the problem; the checklist catches the cases where they are not. If the interface change looks likely, the camera finder and the camera-side configurator are the fast paths, and contact us when the build is GMSL-first and you want the version math checked before hardware is ordered.