NVIDIA Jetson AGX Xavier Setup and Maintenance Guide

Initial publish: April 12, 2022
Last modified: June 3, 2022

Target systems:

• NVIDIA Jetson AGX Xavier Developer Kit
• JetPack 4.6.x
• Jetson Linux / L4T 32.6.x to 32.7.x
• Ubuntu 18.04-based Jetson root filesystem
• users with only one available host computer:
• Linux host
• Windows host
• Windows host with WSL
• macOS host

This guide covers practical setup and maintenance for the NVIDIA Jetson AGX Xavier Developer Kit. It includes flashing JetPack, first boot setup, SSH access, development tools, CUDA and TensorRT checks, power modes, thermals, Docker, camera checks, storage, backups, and remote development.

For stable AGX Xavier development, this guide uses JetPack 4.6.x as the default baseline. JetPack 4.6.1 is a production release with L4T 32.7.1, Linux kernel 4.9, Ubuntu 18.04-based root filesystem, CUDA 10.2, TensorRT 8.2.1, cuDNN 8.2.1, VPI 1.2, OpenCV 4.1.1, and VisionWorks 1.6. JetPack 4.6.2 is a minor update over JetPack 4.6.1 with L4T 32.7.2 security fixes while keeping the same general feature set. NVIDIA Developer

JetPack 5.0 Developer Preview is useful for testing the newer Ubuntu 20.04, kernel 5.10, UEFI, OP-TEE, CUDA 11.4, TensorRT 8.4, cuDNN 8.3, and VPI 2.0 stack, but it is not intended for production use. Use JetPack 5.0 or 5.0.1 Developer Preview only when the project specifically needs that newer preview stack. NVIDIA Docs

1. Recommended software baseline

Use this baseline unless the project requires another JetPack version:

JetPack: 4.6.1 or 4.6.2
Jetson Linux / L4T: 32.7.1 or 32.7.2
Root filesystem: Ubuntu 18.04-based
Kernel: Linux 4.9
CUDA: 10.2
cuDNN: 8.2.1
TensorRT: 8.2.1
OpenCV: 4.1.1
VPI: 1.2
VisionWorks: 1.6

For a fresh setup, use JetPack 4.6.2 if available. JetPack 4.6.1 is also fine when the project has already been validated on it.

Avoid mixing CUDA, TensorRT, cuDNN, OpenCV, PyTorch, and camera drivers from different JetPack releases. Jetson projects are much easier to maintain when the JetPack version is treated as part of the project specification.

2. Choose the correct host path

Use the section that matches the only host machine you have.

NVIDIA's JetPack 4.6.x SDK Manager flashing path expects an Ubuntu 16.04 or Ubuntu 18.04 x86_64 host. That means Windows, WSL, and macOS are useful for development, but they are not the cleanest direct flashing environments for JetPack 4.6.x. NVIDIA Developer

3. Hardware checklist

Prepare:

• Jetson AGX Xavier Developer Kit
• official power supply
• USB-C data cable for flashing
• HDMI or DisplayPort monitor
• USB keyboard and mouse
• Ethernet connection
• host computer from one of the supported workflows below
• NVIDIA Developer account
• at least 30 GB free disk space for downloads, flashing files, and target packages

Use a real data-capable USB-C cable. Some USB-C cables are charge-only and will not work for recovery-mode flashing.

Avoid:

USB hubs during flashing
Bad or charge-only USB-C cables
Letting the host sleep during flashing
Nearly-full host storage
Unreliable VM USB passthrough
Disconnecting power during flashing

4. Host path A: Linux host

Use this path if your only host computer is already running Ubuntu Linux.

Recommended host:

Ubuntu 18.04 x86_64

Ubuntu 16.04 can also be used for JetPack 4.6.x SDK Manager flashing, but Ubuntu 18.04 is the better practical choice for this guide.

4.1 Install SDK Manager

Download the NVIDIA SDK Manager .deb package on the Ubuntu host.

Install it:

sudo apt update
sudo apt install ./sdkmanager_*_amd64.deb

If dependencies are missing:

sudo apt -f install

Launch SDK Manager:

sdkmanager

Log in with your NVIDIA Developer account.

4.2 Connect the Jetson

Connect:

Ubuntu host USB port  ->  Jetson AGX Xavier USB-C flashing port
Jetson power supply   ->  Jetson power jack
Ethernet              ->  Jetson Ethernet port
Monitor               ->  HDMI or DisplayPort
Keyboard/mouse        ->  USB ports

4.3 Enter Force Recovery Mode

Power off the Jetson.

Then:

1. Press and hold Force Recovery.
2. Press Power.
3. Release Power.
4. Release Force Recovery.

Verify on the Linux host:

lsusb | grep -i nvidia

You may see something like:

NVIDIA Corp. APX

4.4 Flash JetPack

In SDK Manager, select:

Product Category: Jetson
Target Hardware: Jetson AGX Xavier
JetPack Version: JetPack 4.6.2, or JetPack 4.6.1 if required
Target Operating System: Jetson Linux

For development systems, install:

Jetson OS
CUDA
cuDNN
TensorRT
OpenCV
VPI
Nsight tools
Multimedia API
Samples and documentation

Use a normal user account during setup, not root.

Example:

Username: anthony
Hostname: jetson-xavier

After flashing, continue to Section 8: First boot setup.

5. Host path B: Windows host only

Use this path if your only machine is a Windows PC.

Windows is good for remote development after the Jetson is flashed, but JetPack 4.6.x flashing should be done from Ubuntu 18.04 x86_64. The most reliable Windows-only workflow is to temporarily boot Ubuntu on the same Windows PC.

5.1 Recommended Windows-only flashing method: temporary Ubuntu boot

Use the Windows PC itself as the Linux host by booting Ubuntu from:

A bootable Ubuntu 18.04 USB installer
A persistent Ubuntu USB drive
An external SSD with Ubuntu installed
A temporary dual-boot Ubuntu install

Best option:

Install or boot Ubuntu 18.04 x86_64 on the Windows PC, then follow the Linux host flashing path.

This still uses the same host computer. It just temporarily boots the OS that SDK Manager expects.

5.2 Create Ubuntu boot media from Windows

On Windows:

1. Download Ubuntu 18.04 x86_64 ISO.
2. Use Rufus, balenaEtcher, or another USB writing tool.
3. Write the ISO to a USB drive.
4. Reboot the PC.
5. Boot from the USB drive.

For a one-time flash, a live USB may work. For repeated Jetson work, use a persistent USB or external SSD install because SDK Manager downloads large packages.

5.3 Flash from the temporary Ubuntu environment

Once booted into Ubuntu:

sudo apt update
sudo apt install ./sdkmanager_*_amd64.deb
sdkmanager

Then follow:

Section 4.2 Connect the Jetson
Section 4.3 Enter Force Recovery Mode
Section 4.4 Flash JetPack

5.4 Windows VM fallback

A Windows-hosted Ubuntu VM can sometimes work, but it is not the preferred method.

Use a VM only if you cannot boot Ubuntu directly.

VM requirements:

Ubuntu 18.04 x86_64 guest
USB passthrough enabled
Enough disk space for SDK Manager
Stable USB-C cable
No USB hub
Host sleep disabled

Common VM issue:

The Jetson disconnects and reconnects during flashing, and the VM fails to recapture the USB recovery device.

If flashing fails in a VM, use temporary native Ubuntu boot instead.

5.5 Windows development after flashing

After the Jetson is flashed and booted, use Windows normally for remote development.

Recommended tools:

Windows Terminal
PowerShell
OpenSSH client
VS Code
VS Code Remote SSH
Git for Windows
WinSCP
Serial console tool if needed

SSH from PowerShell:

ssh anthony@JETSON_IP_ADDRESS

Copy a file:

scp .\app.py anthony@JETSON_IP_ADDRESS:/home/anthony/projects/app.py

Use VS Code Remote SSH to edit directly on the Jetson.

6. Host path C: Windows with WSL

Use this path if your only machine is Windows and you use WSL.

WSL is excellent for Linux-style development after the Jetson is running, but it should not be treated as the primary JetPack 4.6.x flashing environment.

6.1 Flashing recommendation with WSL available

For flashing, use the same recommendation as the Windows-only path:

Boot Ubuntu 18.04 x86_64 directly on the Windows PC using a USB drive, persistent USB, external SSD, or temporary dual-boot install.

Then flash with SDK Manager from that native Ubuntu environment.

6.2 Why not use WSL for flashing

WSL is not the ideal flashing environment because Jetson flashing depends on USB recovery-mode behavior. The Jetson may reconnect during the flashing process, and SDK Manager expects Linux-level USB access.

Use WSL for:

SSH
Git
rsync
scp
Python scripts
Local build scripts
VS Code Remote SSH workflow

Do not depend on WSL for:

Initial JetPack flashing
Recovery-mode flashing
Low-level USB recovery
SDK Manager target flashing

6.3 WSL development setup after flashing

Inside WSL:

sudo apt update
sudo apt install -y git openssh-client rsync vim tmux

SSH into the Jetson:

ssh anthony@JETSON_IP_ADDRESS

Rsync project files:

rsync -aAXH --info=progress2 ./project/ anthony@JETSON_IP_ADDRESS:/home/anthony/projects/project/

Recommended workflow:

Edit on Windows or WSL.
Run code on the Jetson.
Use SSH, rsync, Git, and VS Code Remote SSH.
Flash from native Ubuntu booted on the same PC.

7. Host path D: macOS host only

Use this path if your only machine is a Mac.

macOS is useful for remote development after the Jetson is flashed, but it is not the normal SDK Manager flashing host for JetPack 4.6.x.

7.1 Intel Mac flashing options

If you have an Intel Mac, the best same-machine options are:

Install Ubuntu 18.04 on an external drive and boot from it.
Use Boot Camp with Ubuntu/Linux if already configured.
Use an Ubuntu 18.04 VM with USB passthrough as a last resort.

Best practical option:

Boot Ubuntu 18.04 x86_64 on the Intel Mac, install SDK Manager, then follow the Linux host flashing path.

A VM may fail for the same reason as Windows VMs: the Jetson reconnects during recovery-mode flashing, and USB passthrough can break.

7.2 Apple Silicon Mac flashing options

For Apple Silicon Macs, direct SDK Manager flashing is not a good path because JetPack 4.6.x SDK Manager flashing expects an Ubuntu x86_64 host.

Practical options:

Use a pre-flashed Jetson if available.
Use an x86_64 Ubuntu machine if one can be borrowed.
Use a cloud/lab/workstation only if it provides physical USB access, which most cloud systems do not.
Use a VM only as an experimental last resort.

If the Jetson is already flashed, Apple Silicon macOS is fine for remote development over SSH.

7.3 macOS development after flashing

Install tools with Homebrew if needed:

brew install git rsync

SSH:

ssh anthony@JETSON_IP_ADDRESS

Copy files:

scp ./app.py anthony@JETSON_IP_ADDRESS:/home/anthony/projects/app.py

Rsync project:

rsync -aAXH --info=progress2 ./project/ anthony@JETSON_IP_ADDRESS:/home/anthony/projects/project/

Use VS Code Remote SSH from macOS for editing directly on the Jetson.

8. First boot setup

After flashing, the Jetson reboots into first boot setup.

Configure:

Language
Keyboard layout
Timezone
Username
Password
Hostname
Network

After logging in, check the installed Jetson version:

cat /etc/nv_tegra_release

Check Ubuntu version:

lsb_release -a

Check kernel:

uname -a

Check storage:

df -h
lsblk -f

For JetPack 4.6.x, the root filesystem should be Ubuntu 18.04-based.

9. Update the system safely

Update packages:

sudo apt update
sudo apt upgrade -y
sudo apt autoremove -y

Reboot if NVIDIA packages, kernel packages, or system libraries were updated:

sudo reboot

Do not run a normal Ubuntu distribution upgrade on Jetson.

Avoid:

sudo do-release-upgrade

Jetson Linux is tied to NVIDIA's board support package, kernel, bootloader, CUDA stack, TensorRT version, and APT repositories. Upgrading Ubuntu like a normal desktop or server install can break the Jetson software stack.

10. Set hostname and timezone

Set a clear hostname:

sudo hostnamectl set-hostname jetson-xavier

Set timezone:

sudo timedatectl set-timezone America/Los_Angeles
timedatectl

11. Verify sudo user

Check the current user:

whoami
groups
sudo whoami

Expected sudo test output:

root

If another admin user is needed:

sudo adduser anthony
sudo usermod -aG sudo anthony

12. Configure SSH on the Jetson

Install SSH server if needed:

sudo apt update
sudo apt install -y openssh-server
sudo systemctl enable --now ssh

Check SSH status:

systemctl status ssh

Find the Jetson IP address:

ip addr

From the host computer:

ssh anthony@JETSON_IP_ADDRESS

13. Configure SSH key login

On Linux, macOS, Windows PowerShell, or WSL, create an SSH key:

ssh-keygen -t ed25519 -C "hi@anth.dev"

Copy it to the Jetson from Linux, macOS, or WSL:

ssh-copy-id -i ~/.ssh/id_ed25519.pub anthony@JETSON_IP_ADDRESS

If ssh-copy-id is unavailable, manually add the public key on the Jetson:

mkdir -p ~/.ssh
chmod 700 ~/.ssh
nano ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys

For Windows PowerShell, show the public key:

type $env:USERPROFILE\.ssh\id_ed25519.pub

Paste that public key into the Jetson's ~/.ssh/authorized_keys.

After key login works, harden SSH:

sudo nano /etc/ssh/sshd_config

Recommended settings:

PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes

Validate:

sudo sshd -t

Restart SSH:

sudo systemctl restart ssh

Keep the current SSH session open and test a second login before closing anything.

14. Install baseline development tools

Install common packages:

sudo apt update
sudo apt install -y \
  build-essential \
  cmake \
  git \
  curl \
  wget \
  vim \
  htop \
  tmux \
  rsync \
  unzip \
  python3-pip \
  python3-venv \
  python3-dev \
  pkg-config \
  v4l-utils \
  i2c-tools \
  can-utils

For debugging:

sudo apt install -y \
  gdb \
  strace \
  ltrace

Use NVIDIA profiling tools for CUDA and accelerated workloads. Generic Linux profiling tools are useful, but they do not replace Nsight Systems, Nsight Compute, TensorRT profiling, or tegrastats.

15. Check CUDA

Check CUDA compiler:

nvcc --version

Check CUDA directory:

ls /usr/local/cuda

If needed, add CUDA paths:

nano ~/.bashrc

Add:

export PATH=/usr/local/cuda/bin:$PATH
export LD_LIBRARY_PATH=/usr/local/cuda/lib64:$LD_LIBRARY_PATH

Reload:

source ~/.bashrc

Test again:

nvcc --version

JetPack 4.6.1 includes CUDA 10.2. NVIDIA Developer

16. Check TensorRT, cuDNN, OpenCV, and VPI

TensorRT:

dpkg -l | grep -i tensorrt

cuDNN:

dpkg -l | grep -i cudnn

OpenCV:

python3 - <<'EOF'
import cv2
print(cv2.__version__)
EOF

VPI:

dpkg -l | grep -i vpi

JetPack 4.6.1 includes TensorRT 8.2.1, cuDNN 8.2.1, VPI 1.2, OpenCV 4.1.1, and VisionWorks 1.6. NVIDIA Developer

If a project depends on specific CUDA, TensorRT, or cuDNN versions, pin the JetPack version in project documentation.

17. Build and run CUDA sample

If CUDA samples are installed:

cd /usr/local/cuda/samples/1_Utilities/deviceQuery
sudo make
./deviceQuery

Expected result:

Result = PASS

If the samples are missing, install the full JetPack components through SDK Manager or use a CUDA sample repository compatible with the installed JetPack version.

18. Configure power mode

Check current power mode:

sudo nvpmodel -q

Set maximum performance mode:

sudo nvpmodel -m 0

Lock clocks for benchmarking:

sudo jetson_clocks

Show clocks:

sudo jetson_clocks --show

Use maximum performance mode and jetson_clocks only when cooling is adequate. For normal development, dynamic clocks are usually fine.

19. Monitor thermals and performance

Run:

tegrastats

Or with a 1-second interval:

tegrastats --interval 1000

Watch:

CPU usage
GPU usage
RAM usage
Swap usage
Temperature
Power draw
Clocks
Thermal throttling

Optional install:

sudo apt update
sudo apt install -y python3-pip
sudo pip3 install -U jetson-stats
sudo reboot

After reboot:

jtop

Use jtop for convenience, but record raw tegrastats output for serious benchmark logs.

20. Python environment setup

Use virtual environments for project packages:

mkdir -p ~/projects
cd ~/projects
python3 -m venv jetson-env
source jetson-env/bin/activate
python -m pip install --upgrade pip setuptools wheel

Install common packages:

pip install numpy scipy matplotlib

Be careful with PyTorch. Jetson uses ARM64 and NVIDIA's CUDA stack. Do not install random x86 wheels or generic CUDA wheels.

Use PyTorch wheels built for the installed JetPack version.

Document:

JetPack version
Python version
PyTorch wheel URL
CUDA version
cuDNN version
TensorRT version

21. Docker setup

Check Docker:

docker --version

Check NVIDIA container packages:

dpkg -l | grep -i nvidia-container

Test Docker:

sudo docker run --rm hello-world

Add your user to the Docker group if needed:

sudo usermod -aG docker $USER

Log out and back in.

Check group membership:

groups

Use Jetson/L4T-compatible container images. Do not use normal desktop/server CUDA containers unless they explicitly support Jetson ARM64 and the installed L4T version.

Good image families to use:

nvcr.io/nvidia/l4t-base
nvcr.io/nvidia/l4t-ml
nvcr.io/nvidia/deepstream-l4t

Match the image tag to the JetPack/L4T version whenever possible.

22. Camera checks

For USB cameras:

ls /dev/video*
v4l2-ctl --list-devices

Test a USB camera:

gst-launch-1.0 v4l2src device=/dev/video0 ! videoconvert ! autovideosink

For CSI cameras:

media-ctl -p

Common camera issues:

Wrong JetPack version for camera driver
Wrong ribbon cable orientation
Missing device tree overlay
Wrong camera connector
Vendor driver built for another L4T version
Insufficient power
Bad GStreamer pipeline

For vendor cameras, use the vendor's driver package for the exact JetPack/L4T version.

23. I2C, SPI, GPIO, and CAN tools

Install tools:

sudo apt install -y i2c-tools can-utils

List I2C buses:

i2cdetect -l

Scan a bus:

sudo i2cdetect -y 1

Be careful scanning I2C buses connected to sensitive devices. Some hardware does not tolerate probing.

For CAN:

ip link show

Bring up CAN example:

sudo ip link set can0 up type can bitrate 500000
ip -details link show can0

Listen:

candump can0

24. Network setup

Check interfaces:

ip addr
nmcli device status

Set a static Ethernet IP using NetworkManager:

nmcli con show

Example:

sudo nmcli con mod "Wired connection 1" \
  ipv4.addresses 192.168.1.50/24 \
  ipv4.gateway 192.168.1.1 \
  ipv4.dns "1.1.1.1 8.8.8.8" \
  ipv4.method manual

Restart connection:

sudo nmcli con down "Wired connection 1"
sudo nmcli con up "Wired connection 1"

For robotics, lab, camera, and benchmark work, prefer wired Ethernet over Wi-Fi.

25. Storage check and cleanup

Check storage:

df -h
lsblk -f

Clean apt cache:

sudo apt autoremove -y
sudo apt autoclean

Find large directories:

sudo du -hxd1 / | sort -h

For large projects, datasets, Docker images, and model artifacts, use external NVMe or USB storage instead of filling the internal eMMC.

26. Optional NVMe or external storage setup

Check the device name:

lsblk

Partition the disk:

sudo parted /dev/nvme0n1

Inside parted:

mklabel gpt
mkpart primary ext4 0% 100%
quit

Format:

sudo mkfs.ext4 -L jetson-data /dev/nvme0n1p1

Create mount point:

sudo mkdir -p /data

Find UUID:

sudo blkid /dev/nvme0n1p1

Edit /etc/fstab:

sudo nano /etc/fstab

Example:

UUID=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx  /data  ext4  defaults,noatime  0  2

Test:

sudo mount -a
df -h

Do not edit /etc/fstab carelessly. A bad entry can delay or break boot.

27. Git and GitHub setup

Install Git:

sudo apt install -y git

Configure identity:

git config --global user.name "Anthony Kung"
git config --global user.email "hi@anth.dev"
git config --global core.editor "vim"
git config --global init.defaultBranch main

Use SSH keys:

ssh-keygen -t ed25519 -C "hi@anth.dev"
cat ~/.ssh/id_ed25519.pub

Add the public key to GitHub.

Test:

ssh -T git@github.com

Use SSH remotes:

git remote set-url origin git@github.com:username/repository.git

Avoid caching GitHub passwords for long periods. Use SSH keys or tokens instead.

28. Git LFS

Install Git LFS:

sudo apt install -y git-lfs
git lfs install

Track large model files:

cd /path/to/repository
git lfs track "*.pt"
git lfs track "*.onnx"
git lfs track "*.engine"
git lfs track "*.zip"
git add .gitattributes
git commit -m "Configure Git LFS"

Do not commit datasets, TensorRT engine files, checkpoints, or generated binaries directly into normal Git history.

29. Backup strategy

At minimum, back up:

/home
/etc
/opt
/usr/local/bin
Project directories
Model files
Training/inference configs
Custom systemd services
Custom udev rules
Device tree or kernel changes

Simple rsync backup:

rsync -aAXH --numeric-ids --info=progress2 \
  /home/anthony/ \
  user@backup-server:/backups/jetson-xavier/home-anthony/

Backup system configuration:

sudo tar -czf jetson-etc-backup.tar.gz /etc

For research systems, also save:

JetPack version
L4T version
Python package list
Docker image tags
CUDA/TensorRT versions
Model commit hash
Benchmark command lines
Power mode
Clock mode
Thermal conditions

Record versions:

cat /etc/nv_tegra_release > jetson-version.txt
uname -a >> jetson-version.txt
nvcc --version >> jetson-version.txt
dpkg -l | grep -E "cuda|nvidia|tensorrt|cudnn" >> jetson-version.txt

30. Create a project systemd service

Create a service:

sudo nano /etc/systemd/system/jetson-app.service

Example:

[Unit]
Description=Jetson Application
After=network-online.target
Wants=network-online.target

[Service]
Type=simple
User=anthony
WorkingDirectory=/home/anthony/projects/jetson-app
ExecStart=/home/anthony/projects/jetson-app/venv/bin/python main.py
Restart=on-failure
RestartSec=5

[Install]
WantedBy=multi-user.target

Enable:

sudo systemctl daemon-reload
sudo systemctl enable --now jetson-app

Check logs:

journalctl -u jetson-app -f

31. Remote development workflow

Recommended workflow:

Use SSH for terminal access.
Use VS Code Remote SSH for editing.
Use tmux for long-running commands.
Use rsync or Git for code transfer.
Use Docker for reproducible deployment when possible.
Use wired Ethernet for flashing and benchmarking.

Install tmux:

sudo apt install -y tmux

Start session:

tmux new -s dev

Detach:

Ctrl-b then d

Reattach:

tmux attach -t dev

32. Benchmarking checklist

Before recording performance numbers:

sudo nvpmodel -q
sudo jetson_clocks --show
tegrastats
cat /etc/nv_tegra_release
uname -a

Record:

JetPack version
L4T version
Power mode
Whether jetson_clocks is enabled
Input resolution
Batch size
Precision: FP32, FP16, INT8
Framework: PyTorch, TensorRT, ONNX Runtime, DeepStream
Camera source or test file
Thermal state
Fan behavior
Average FPS
Latency
Power draw

For reproducible benchmark mode:

sudo nvpmodel -m 0
sudo jetson_clocks
tegrastats --interval 1000

Do not compare results from different power modes as if they are equivalent.

33. JetPack 5.0 Developer Preview notes

JetPack 5.0 Developer Preview adds Linux kernel 5.10, an Ubuntu 20.04-based root filesystem, UEFI bootloader, OP-TEE, CUDA 11.4, TensorRT 8.4, cuDNN 8.3, and VPI 2.0. It supports Jetson AGX Xavier series developer kits and modules, but NVIDIA marks it as a developer preview and not intended for production use. NVIDIA Docs

Use JetPack 5.0 or 5.0.1 Developer Preview only for:

Testing Ubuntu 20.04-based Jetson systems
Testing kernel 5.10 behavior
Early migration experiments
Checking compatibility with newer CUDA/TensorRT APIs
Evaluating UEFI boot behavior
Testing software intended for the newer Jetson stack

Do not use it as the default for stable AGX Xavier deployments unless the project specifically accepts preview-release risk.

34. Common problems

SDK Manager does not detect the Jetson

Check:

lsusb | grep -i nvidia

Fixes:

Use the correct USB-C port.
Use a better USB-C data cable.
Enter Force Recovery Mode again.
Use native Ubuntu instead of WSL.
Avoid unreliable VM USB passthrough.
Try another host USB port.
Avoid USB hubs.

Flashing fails partway through

Try:

Reboot the host computer.
Use a different USB cable.
Use a native Ubuntu 18.04 host.
Free more host disk space.
Disable laptop sleep.
Avoid USB hubs.
Restart SDK Manager.

Windows or macOS is the only available machine

Best options:

Boot Ubuntu 18.04 from USB or external storage on the same machine.
Use a persistent Ubuntu USB or external SSD for repeated Jetson work.
Use a VM only as a last resort.
Use Windows, WSL, or macOS for SSH development after the Jetson is flashed.

nvcc is missing

Check:

ls /usr/local/cuda
dpkg -l | grep cuda

Likely causes:

CUDA toolkit package was not installed.
Only part of JetPack was installed.
PATH was not configured.
SDK Manager component installation failed.

Poor inference performance

Check:

sudo nvpmodel -q
sudo jetson_clocks --show
tegrastats

Common causes:

Low power mode
Thermal throttling
Running FP32 instead of FP16 or INT8
Using PyTorch eager mode instead of TensorRT
Camera pipeline bottleneck
CPU preprocessing bottleneck
Slow storage
Insufficient cooling

System becomes unstable under load

Check:

Power supply
Thermals
Fan
USB devices drawing too much power
Overclocking or custom clocks
Bad external storage
Kernel module mismatch

35. Final verification checklist

System:

cat /etc/nv_tegra_release
lsb_release -a
uname -a
hostnamectl
timedatectl

Network:

ip addr
ping -c 4 google.com

Storage:

df -h
lsblk -f

NVIDIA stack:

nvcc --version
dpkg -l | grep -E "cuda|tensorrt|cudnn|nvidia"

Power and thermals:

sudo nvpmodel -q
sudo jetson_clocks --show
tegrastats

SSH:

systemctl status ssh

Git:

git --version
git config --global --list

Docker:

docker --version
dpkg -l | grep -i nvidia-container

36. Operational notes

Use JetPack 4.6.1 or 4.6.2 as the default AGX Xavier baseline unless the project specifically requires another version.

Use JetPack 4.6.2 for fresh stable setups when available because it includes L4T 32.7.2 security fixes while keeping the same general feature set as JetPack 4.6.1. NVIDIA Developer

Use JetPack 5.0 or 5.0.1 Developer Preview only for testing the newer Ubuntu 20.04 and kernel 5.10 stack.

If the only host is Linux, flash directly with SDK Manager.

If the only host is Windows, boot Ubuntu 18.04 temporarily on the same PC to flash, then use Windows for development.

If the only host is Windows with WSL, use WSL for development after flashing, but use native Ubuntu boot for flashing.

If the only host is macOS, use Ubuntu on external storage or a VM as a last resort for flashing, then use macOS for development.

Do not run normal Ubuntu release upgrades on Jetson.

Do not mix random CUDA, TensorRT, cuDNN, PyTorch, and OpenCV packages without checking JetPack compatibility.

Use nvpmodel, jetson_clocks, and tegrastats when benchmarking.

Use external NVMe or USB storage for datasets, Docker images, checkpoints, and model artifacts.

Use wired Ethernet for flashing, benchmark runs, and stable remote development.

Record JetPack version, L4T version, power mode, clocks, thermal state, and model precision for every benchmark.