JetPack 5 to 6 migration: what breaks and how to fix it

The JetPack 5 to JetPack 6 upgrade is a bigger jump than a version number suggests. The kernel moves from 5.10 to 5.15, the container runtime changes, and several BSP APIs that were stable in JetPack 5 are deprecated or removed. What breaks depends on how much custom BSP work your product has accumulated.

Key Insights

• JetPack 5 to 6 is a full platform jump: Ubuntu 20.04 → 22.04, CUDA 11.4 → 12.6, cuDNN 8 → 9, TensorRT 8 → 10, kernel 5.10 → 5.15
• OTA from JP5 to JP6 is not supported, reflash is required
• Everything compiled against JP5 must be rebuilt: TRT engines, camera drivers, kernel modules, Python environments
• Custom camera drivers need porting, the tegracam sensor API changed between L4T R35 and R36
• Xavier-series modules (AGX Xavier, Xavier NX) are not supported in JetPack 6, JP5.1.x is the end of the line for Xavier

JetPack 5 to 6 is a platform upgrade, not a package update

The version bump from 5 to 6 understates what changed. The full platform delta:

Component	JetPack 5 (L4T R35)	JetPack 6 (L4T R36)
OS	Ubuntu 20.04	Ubuntu 22.04
Kernel	Linux 5.10	Linux 5.15
CUDA	11.4	12.6
cuDNN	8.x	9.x
TensorRT	8.x	10.x
Python (default)	3.8	3.10
OpenCV (bundled)	4.5.4	4.8.1
GStreamer	1.16	1.22

This means OTA from JP5 to JP6 is not supported. You cannot apt upgrade your way there. Reflash is required. Teams that try OTA hit A/B slot errors or partial upgrades that leave the system unbootable.

Also worth knowing: JP6 dropped support for Xavier-series modules (AGX Xavier, Xavier NX). If you’re on Xavier, JP5.1.x is your last JetPack.

The complete break list when upgrading JetPack 5 to JetPack 6

Go through this before you start. Every item here has caused a blocked migration in the field.

1. CUDA-compiled binaries

Any binary compiled against CUDA 11.4 will not run on CUDA 12.6 without recompilation. This includes your own code and any third-party libraries you built from source. apt-installed NVIDIA libraries will update automatically, but binaries in /opt/, /usr/local/, or your home directory won’t.

Audit: grep -r "libcuda" /opt /usr/local ~/.local 2>/dev/null | grep ".so"

2. cuDNN 8 applications

JetPack 6 ships libcudnn.so.9. Any application that dynamically links libcudnn.so.8 will fail with error while loading shared libraries: libcudnn.so.8: cannot open shared object file.

Options: recompile against cuDNN 9, or install cuDNN 8 from the NVIDIA archive alongside 9 (not recommended long-term, but buys time during migration).

3. TensorRT engines

TensorRT serialized engines are not portable across TRT versions. Every engine built on JP5 (TRT 8.x) must be regenerated on JP6 (TRT 10.x). This is not optional, attempting to load a TRT 8 engine in TRT 10 will crash at deserialization.

Additionally, TRT 10 removed several deprecated APIs from TRT 8. If your code uses IPluginV2 directly or the legacy calibrator interfaces, it will fail to compile.

4. PyTorch and TorchVision

The JP5-compatible PyTorch wheels (CUDA 11.4 builds) are incompatible with JP6’s CUDA 12.6. You need the JP6-specific wheels from NVIDIA’s PyPI or the Jetson Containers project. The version numbers don’t always match what you’d install from pip on a desktop, always use the Jetson-specific builds.

5. Custom camera drivers

This is the hardest one. L4T R36 made changes to the V4L2 subdev framework and the tegracam sensor driver API. A camera driver that works perfectly on JP5 will often fail to compile on JP6, and even if it compiles, behavior differences in the capture subsystem may cause runtime failures.

Specific things that change:

• Sensor driver registration APIs in tegracam_core
• NVCSI configuration interfaces
• The mclk clock handling changed in R36

We cover this in more depth in the section below.

6. Out-of-tree kernel modules

The kernel version changed from 5.10 to 5.15. Any out-of-tree kernel module (.ko file) built for L4T R35 will fail to load on R36 with ERROR: could not insert module: Invalid module format. All kernel modules must be rebuilt against the L4T R36 kernel headers.

7. Device tree changes on custom carrier boards

L4T R36 updated the reference DTS files significantly. If you have a custom carrier board DTS that was derived from JP5 reference files, it needs an audit before JP6. Known breaking changes:

• DWC3 USB controller: ref clock became mandatory (see our DWC3 error -71 post)
• PCIe clock references changed on some Orin variants
• UART/SPI/I2C pinmux configurations may need revalidation
• ODMDATA format changes for some carrier board profiles

8. GStreamer plugin compatibility

GStreamer moved from 1.16 to 1.22. Most pipelines work without changes, but some NVIDIA-specific elements (nvv4l2decoder, nvarguscamerasrc) had interface changes. Pipelines that rely on deprecated property names or pad caps negotiation behavior from 1.16 may need updating.

9. Package names and Python environment

The Ubuntu 22.04 jump means some package names changed (python3-dev → same, but libpython3.8-dev is no longer default, etc.). virtualenvs built against Python 3.8 need to be recreated. Anything using distutils directly will break since it was removed in Python 3.12 (not relevant here) but setuptools behavior changed in 3.10.

Camera driver porting from JetPack 5 to JetPack 6

This is the part most teams underestimate. If you have a custom CSI camera driver, plan for 2–5 days of porting work depending on how much the driver deviates from the NVIDIA sensor driver template.

The main changes in L4T R36 that break JP5 camera drivers:

tegracam API changes. The tegracam_device and tegracam_ctrl_ops structures changed. Functions that were called directly in R35 are now wrapped or renamed. Drivers built against the R35 headers will hit compile errors in tegracam_core.h.

MCLK handling. The sensor mclk clock acquisition changed. In R35, many drivers called clk_get directly. R36 moved this into the framework. Drivers that manage the mclk themselves need the clock handling rewritten.

V4L2 subdev pad config API. The v4l2_subdev_pad_ops structure had members renamed in newer kernel versions included in R36. This causes compile errors that look unrelated to camera bring-up but are.

The fastest path: take the NVIDIA reference sensor driver for a similar sensor (the IMX219 or IMX477 reference drivers in the JP6 source tree), diff it against the JP5 version, and apply the same structural changes to your driver. Don’t try to patch your JP5 driver forward blindly.

For reference on the full camera bring-up process in JP6, see our CSI camera driver bring-up post.

ML stack and TensorRT migration

Rebuilding the ML stack in sequence matters. Do it in this order to avoid dependency conflicts:

1. Flash JP6 and boot clean
2. Install CUDA 12.6 + cuDNN 9 from the JP6 image (they come pre-installed)
3. Install JP6-specific PyTorch wheels (from NVIDIA’s Jetson PyPI or dusty-nv/jetson-containers)
4. Install TorchVision matching your PyTorch version (check the Jetson Containers compatibility matrix)
5. Re-export ONNX models from your training framework
6. Rebuild TensorRT engines on the target with trtexec or your engine builder

Do not try to install desktop PyTorch wheels. The pip install torch from PyPI will attempt to download CUDA 12 wheels but they are x86 builds and will fail or silently install wrong. Use dusty-nv/jetson-containers for pre-built, verified JP6-compatible PyTorch and TorchVision wheels, it’s the most reliable source for the Jetson ML stack.

NVIDIA’s official JetPack 6 release notes document the full package delta and known issues for each point release.

Step-by-step migration checklist

Use this sequence to minimize the chance of a blocked migration:

Pre-migration (on your JP5 system):

1. lsmod, record all loaded kernel modules; every .ko will need to be rebuilt
2. List all virtualenvs and their Python package requirements
3. Find all TRT engines: find / -name "*.engine" 2>/dev/null
4. Grep for hardcoded CUDA 11 paths: grep -r "cuda-11\|cuda/11" /opt /usr/local 2>/dev/null
5. Record your camera driver source location and confirm you have the source, not just the .ko
6. If you have a custom DTS, save a copy and note which JP5 reference DTS it was derived from

Post-flash (on JP6):

1. Verify CUDA 12.6: nvcc --version
2. Verify cuDNN 9: dpkg -l libcudnn9-dev
3. Rebuild all out-of-tree kernel modules against L4T R36 headers
4. Port and test camera drivers (biggest time sink, start here)
5. Recreate Python environments with Python 3.10
6. Install Jetson-specific PyTorch and TorchVision
7. Re-export ONNX models and rebuild TRT engines
8. Run your application’s full test suite before returning the device to service

What to audit before you start the migration

Area	What to check	Risk if skipped
Camera drivers	Do you have custom .c driver files?	2–5 days of porting work discovered mid-migration
TRT engines	List all .engine files in production	Runtime crashes at model load
Kernel modules	lsmod and /lib/modules/ on your JP5 system	Modules silently missing on JP6
Python environments	All virtualenvs, conda envs	Import failures in production
Hardcoded CUDA paths	Grep for /usr/local/cuda-11	Runtime errors in scripts
Carrier board DTS	Is your DTS derived from JP5 reference?	Boot failures after flash

If your JP5 system has custom camera drivers or a complex custom carrier board DTS and you need a scoped porting engagement, the Jetson BSP and camera bring-up service covers what that typically involves and how we scope the work.

For the complete camera bring-up process on JetPack 6, see GMSL2 camera bring-up on Jetson Orin. For the JetPack version compatibility table with all L4T releases, see JetPack versions and L4T compatibility.