如果你手里有一块 Jetson AGX Orin 或者 Orin NX/Orin Nano出厂预装的是 JetPack 6.x也就是 Ubuntu 22.04而你真正要跑的机器人软件栈是 ROS-noetic那你大概率已经体会过那种“新系统和旧版 ROS 互相拉扯”的痛苦。ROS-noetic 是 ROS1 的最后一个版本官方只承诺 Ubuntu 20.04Focal上开箱即用到了 22.04很多包要么装不上要么编译到一半报奇奇怪怪的错误。更麻烦的是Jetson 上的 Ubuntu 并不是普通桌面版 Ubuntu它深度绑定在 NVIDIA 的 L4TLinux for Tegra体系里你不能用 apt 或者 do-release-upgrade 把 22.04 原地“降级”成 20.04唯一干净的路子是重刷整个系统镜像。这篇文章就把我从 Ubuntu 22.04JetPack 6.x回退到 Ubuntu 20.04JetPack 5.x的完整过程整理出来包括刷机前怎么备份、Recovery 模式怎么进、SDK Manager 和命令行两种烧录方式的具体操作、刷完之后的环境重建以及 ROS-noetic 在 Arm64 上的安装和加速适配。文章偏实操命令可以直接复制适合需要在 Jetson Orin 上跑 ROS1 的开发者也适合那些被“新版系统搞坏老工程”的嵌入式工程师参考。1. 为什么必须重刷而不是原地降级ROS-noetic与L4T的绑定逻辑1.1 ROS-noetic 的官方支持范围ROS-noetic全名 Noetic Ninjemys是 2020 年 5 月发布的最后一个 ROS1 发行版官方支持的操作系统只有 Ubuntu 20.04 Focal另外一个官方版本是 Debian Bullseye。也就是说如果你要用的是 ROS1 生态里的老包比如 navigation、gmapping、MoveIt 的旧版本、以及各种为 Noetic 开发的相机驱动和激光雷达驱动它们默认的前提几乎都是 “Ubuntu 20.04 Python 3.8”。放到 Ubuntu 22.04 上虽然有些包能硬装但问题往往藏在依赖链里某个库要求libpython3.8某个编译脚本写死了python3.8路径某个 apt 包在 Jammy 源里根本没有对应版本。就算你把 ROS-noetic 从源码强行编译过了后续每次遇到一个老项目都可能要重新打补丁成本非常高。1.2 Jetson 上的 Ubuntu 不能按常规思路“降级”Jetson 系列的系统镜像不是 NVIDIA 随便做的一个 Ubuntu 皮肤它由三部分组成定制内核、BootloaderU-Boot 和 QSPI 固件、以及一套带有大量nvidia-l4t-*软件包的根文件系统。这套东西叫 L4TLinux for TegraJetPack 则是 NVIDIA 给开发者打包好的 SDK 套件组合。正因为 L4T 的根文件系统和内核、Bootloader 是强绑定的你不能像普通 PC 那样“关掉更新源然后降级内核”。如果在 22.04 上执行do-release-upgrade或者手动换源降级最常见的结局是apt 把关键驱动包拆了一部分内核模块和用户态库的版本对不上开机直接卡在核心里连 SSH 都进不去。所以“从 22.04 回退到 20.04”这件事在 Jetson 上的正确含义就是重新烧写一份基于 Ubuntu 20.04 的 JetPack 5.x 系统。1.3 JetPack 版本与 Ubuntu 底座对应关系JetPack 版本对应 L4T 版本Ubuntu 底座默认内核CUDA 主版本JetPack 6.xR36.xUbuntu 22.04 LTSKernel 5.15CUDA 12.xJetPack 5.1.3R35.5.0Ubuntu 20.04.6 LTSKernel 5.10CUDA 11.4JetPack 5.1.2R35.4.1Ubuntu 20.04.6 LTSKernel 5.10CUDA 11.4JetPack 5.0.2R35.1.0Ubuntu 20.04.5 LTSKernel 5.10CUDA 11.4所以你的目标很明确烧一个R35.xJetPack 5.x镜像系统自动变成 Ubuntu 20.04ROS-noetic 的官方支持就落到了实处。1.4 判断你到底是必须回退还是可以绕开不是所有人都需要做这个回退操作。我建议先按下面的标准筛一遍明确需要回退你的核心代码是用 ROS1 写的且依赖 MoveIt 1.x、navigation、gmapping、cartographer 等 Noetic 时代的库或者你手上有厂家只提供 Ubuntu 20.04 二进制包的相机、雷达 SDK又或者你的神经网络模型是用 JetPack 5 时代的 TensorRT/PyTorch 流程做的重新适配到 JetPack 6 的成本太高。不需要回退你只用 ROS2 Humble那 22.04 反而是官方推荐环境或者你的 ROS1 应用非常轻量只订阅小话题、不碰底层驱动那可以用 Docker 在 22.04 里跑一个 Noetic 容器物理机还是用 JetPack 6。需要谨慎判断摄像头驱动、CUDA 加速库、实时内核补丁这三类东西对 L4T 版本非常敏感。容器能隔离用户态依赖却隔离不了内核模块和/dev设备节点。所以调度特别紧张的项目别指望容器能救所有问题。2. 回退前先做决策板卡型号、存储介质与烧录路线2.1 先确认你手上是哪一款 OrinJetson Orin 家族型号不少不同型号对应的烧录配置名不一样搞错的话轻则刷完起不来重则把整块 eMMC 或者 NVMe 分区结构弄乱。刷机前先在当前系统里执行cat /proc/device-tree/model cat /proc/device-tree/nvidia,dtsfilename正常输出会告诉你这是什么型号的开发套件比如NVIDIA Jetson AGX Orin Developer Kit。常见的烧录配置名如下AGX Orin Developer Kitjetson-agx-orin-devkitOrin NX 16GB Developer Kit配套载板jetson-orin-nx-devkitOrin Nano Developer Kitjetson-orin-nano-devkit我遇到过有人拿着 Orin NX 模组配非官方载板这时候flash.sh的板级配置名可能要按载板厂商的资料写比如jetson-agx-orin-devkit是官方载板第三方载板往往需要指定-p参数或者使用厂商提供的烧录脚本这个务必提前问客服或者翻产品说明。2.2 备份优先级清单无论你用的是 SDK Manager 还是命令行刷机烧录动作都会把根文件系统整个清掉。不要抱侥幸心理我见过太多人刷完才想起来有个目录没拷出来。备份时按优先级来代码仓库catkin_ws/src、~/git、~/work下所有工程最好直接推送到远程仓库或者打 tar 包拷到另一台机器。Docker 镜像如果之前用 Docker 封装过环境执行docker save导出为.tar文件docker save myimage:v1 -o myimage_v1.tar系统配置文件/etc里你改过的文件比如hostname、hosts、netplan、wpa_supplicant.conf、ROS 环境变量、~/.bashrc、~/.profile。数据和校准文件rosbag、标定结果、相机内参外参、自训练模型权重、数据库文件。已装软件清单执行apt list --installed installed_packages.txt刷完系统后可以对照这个文件把常用工具装回来。备份位置建议放在外部磁盘或者 x86 工作站上别放在同一块会被刷掉的盘上。2.3 烧录路线选型SDK Manager 还是命令行回退 Jetson 系统主要有两条路线。我在不同场景下都用过给你一个直观的对比对比项SDK Manager命令行 flash.sh宿主主机要求仅支持 x86_64 的 Ubuntu 18.04/20.04/22.04而且需要图形桌面Linux 命令行环境即可有没有桌面无所谓是否需要 NVIDIA 账号需要工具启动后要登录不需要只要能从官网下载镜像包操作难度低全图形化向导中需要理解几个关键参数对批量烧录的支持差每次都要点界面好可以写脚本反复调用组件安装可以顺带安装 CUDA/cuDNN/TensorRT 等 SDK 组件需要自己用 apt 或用脚本装 SDK 组件如果你手头正好有一台 x86_64 的 Ubuntu 电脑无脑选 SDK Manager 是最省事的。如果你平时用 Windows 或者 macOS 开发不想专门为刷机开一台 Ubuntu 虚拟机那命令行烧录反而更干净——随便找台 Linux 机器或者开个 CI 任务都能把烧录这步跑掉。3. 实操Recovery模式与JetPack 5.x刷机全流程3.1 进入 Recovery 模式的标准动作Jetson 的刷机入口不是系统里设置的而是硬件级 Recovery 模式。进入方法在不同型号上几乎一致流程如下把 DC 电源接好先别开机或者先把设备完全关机。用 USB-C 线把 Orin 的调试口连接到主机AGX Orin 开发套件和 Orin Nano/Orin NX 开发套件都有专门的 USB-C 口具体位置看快速入门卡。按住板上的Recovery 按钮不放然后短按一下Reset 按钮继续保持 Recovery 按钮 2 秒左右再松开。回到主机终端执行lsusb如果看到类似0955:7023 NVIDIA Corp. APX的输出说明设备已经被主机识别为烧录设备。这一步最常见的坑是 USB-C 线质量问题。有些线只有充电能力没有数据通路主机上lsusb什么都看不到。建议换一根能传数据的线多试几个主板上的 USB 口。还有一个可能是设备没有完全断电Recovery 模式下 APX 设备也不出现这时先把电源拔掉重来一次。3.2 SDK Manager 图形化烧录我在 PC 环境允许的情况下一般推荐先用 SDK Manager 把基础系统烧出来省去手动拼接 rootfs 的环节。具体步骤在 x86_64 Ubuntu 主机上下载 SDK Manager 安装包例如sdkmanager_2.x.x-XXXX_amd64.deb。安装后启动sudo apt install ./sdkmanager_2.x.x-XXXX_amd64.deb sdkmanager登录 NVIDIA Developer 账号首次使用会让你接受协议。在界面左侧选择Jetson右侧勾选开发套件型号。关键一步在 JetPack 版本下拉框里选JetPack 5.1.3或5.1.2不要选 6.x。点击 ContinueSDK Manager 会进入烧录向导。确认设备已经在 Recovery 模式后点刷新工具会自动检测到设备。随后会弹出一个Manual Setup步骤这里设置的是刷完系统后的 Ubuntu 登录用户名、主机名和密码。这个账号就是以后 SSH 登录 Jetson 用的系统账号密码千万别忘。点击 Flash 开始烧录整个过程大概 10-20 分钟取决于主机磁盘速度和设备存储介质。中途不要拔线。烧录完成后 SDK Manager 会询问是否安装 SDK Components比如 CUDA、cuDNN、TensorRT 等。如果你希望之后用 apt 自己控制版本这里可以直接跳过不影响系统落地。3.3 命令行烧录如果你没有 x86_64 Ubuntu 桌面环境或者想脚本化命令行方式同样可靠。先去 NVIDIA 官网下载 JetPack 5.x 对应的两个包以 JetPack 5.1.3 为例需要的是Jetson_Linux_R35.5.0_aarch64.tbz2Tegra_Linux_Sample-Root-Filesystem_R35.5.0_aarch64.tbz2下载后放到同一个目录执行mkdir -p ~/l4t_r3550 cd ~/l4t_r3550 # 假设两个 tbz2 已下载到当前目录 tar xf Jetson_Linux_R35.5.0_aarch64.tbz2 cd Linux_for_Tegra/rootfs sudo tar xf ../../Tegra_Linux_Sample-Root-Filesystem_R35.5.0_aarch64.tbz2 cd .. sudo tools/l4t_flash_prerequisites.sh sudo ./apply_binaries.sh这里解释一下两个脚本l4t_flash_prerequisites.sh会安装主机烧录时需要的依赖和 USB 权限规则apply_binaries.sh会把 NVIDIA 的内核模块和用户态库拼接到 rootfs 里。执行完这两步后关键的命令是sudo ./flash.sh jetson-agx-orin-devkit mmcblk0p1参数jetson-agx-orin-devkit是板级配置名mmcblk0p1表示把系统写到模块的 eMMC 存储介质上。如果你想把系统写到 NVMe SSD 上把目标参数改成nvme0n1p1例如sudo ./flash.sh jetson-agx-orin-devkit nvme0n1p1我的建议是如果你不是对存储有明确需求优先烧 eMMC。原因很简单eMMC 的烧录流程是 NVIDIA 验证覆盖最广的路径NVMe 方式要考虑分区表、U-Boot 启动索引和散热腔设计出问题的概率高不少。机器人类项目如果数据量大系统留在 eMMC、数据盘用 NVMe是更合理的结构。命令行刷机过程中终端会打印大量信息看到*** The target t186ref has been flashed successfully. ***之类的提示才算成功。失败时常见错误是线材问题、权限不够、板级配置名写错。3.4 烧录后的第一次启动检查设备刷完会自动重启。第一次启动会比平时慢因为要对新 rootfs 做初始化。登录后建议立刻确认环境lsb_release -a uname -m cat /etc/nv_tegra_release dpkg -l | grep nvidia-l4t-core正常情况下lsb_release应该显示Ubuntu 20.04.6 LTSuname -m显示aarch64/etc/nv_tegra_release里能看到R35 (release)字样dpkg列出的nvidia-l4t-core版本也是 R35.x。这三项全部符合说明回退成功。4. 刷机后的系统重建软件源、CUDA栈与Python生态4.1 软件源检查与基础工具安装刷完系统后第一件事不是急着装 ROS而是先把系统软件源理顺。JetPack 5.x 的 apt 源里有两个关键来源一个是我们熟悉的 Ubuntu Focal 官方源另一个是 NVIDIA 自己的nvidia-l4t-apt-source后者提供nvidia-l4t-*驱动包。先看当前源配置cat /etc/apt/sources.list cat /etc/apt/sources.list.d/nvidia-l4t-apt-source.list如果官方源下载速度不理想可以把sources.list换成常见的镜像站。注意只换 Ubuntu 官方源部分不要动 NVIDIA 源否则apt update后驱动包路径对不上升级时容易出问题。然后做一次基础环境安装sudo apt update sudo apt upgrade -y sudo apt install -y ssh curl git vim net-tools htop tree cmake g这里有个重要提醒刷完系统后做apt upgrade是安全的因为 NVIDIA 的 apt 源里有配套的驱动包系统会按 R35.5.0 的版本锁定关系来升级。但千万不要执行do-release-upgrade或者把 sources 改成 Ubuntu 22.04 来升级大版本那是把 Jetson 系统搞坏的最快途径。4.2 CUDA、cuDNN、TensorRT 版本确认与补装如果你是让 SDK Manager 帮你安装了 SDK Components可以直接跳过这一步如果跳过了或者用的是命令行烧录可以用 apt 一次性补齐sudo apt install nvidia-jetpack这个元包会把 CUDA、cuDNN、TensorRT、VPI、VisionWorks 等组件按 JetPack 5.x 的正确版本关系装好。装完验证/usr/local/cuda/bin/nvcc -V dpkg -l | grep TensorRT | head -5以 JetPack 5.1.3 为例你会看到 CUDA 11.4、cuDNN 8.6、TensorRT 8.5 左右。这里必须记得如果回退前你在 JetPack 6 上编译过 CUDA 项目回退后那些二进制基本作废需要重新编译。CUDA 11.4 和 CUDA 12.x 的工具链本质不兼容。另外有一个很多人忽略的点Jetson 是arm64/aarch64架构和 x86_64 环境的差别不只是 apt 包名连很多 pip 包也需要寻找 aarch64 专用 wheel。装依赖的时候不要把 x86 机器上requirements.txt的结果无脑搬过来。检查架构用uname -m dpkg --print-architecture4.3 Python 3.8 环境重建与依赖兼容Ubuntu 20.04 自带的 Python 是 3.8.10这是很多 ROS-noetic 包的默认解释器。如果你之前在 22.04 上创建过 venv 或者 conda 环境那些环境在系统重装后不能直接复用需要全部重建。我的建议是在 Jetson 上装一个 Miniconda用独立环境管理 Python 版本和包版本。原因不复杂ROS-noetic 的系统包使用/usr/bin/python3而你的深度学习代码经常需要更高版本的 Python 或者特定版本的 numpy、torch。两者混在系统 Python 里很容易翻车分开最省心。装依赖时特别注意 numpy 的版本。Jetson 上的很多预编译包比如 OpenCV、TensorRT 的 Python 绑定对 numpy 版本有隐式要求python 包源码编译在 arm64 上又慢又容易失败所以不要盲目追求最新版。我见过numpy 2.2.5在 Ubuntu 20.04 的 arm64 下没有预编译 wheel源码编译几个小时还经常因为 BLAS 配置失败。稳妥做法是安装时把版本往下约束pip install numpy25. ROS-noetic安装与Jetson端的适配实践5.1 安装 ROS-noetic 的两种方式ROS-noetic 在 Ubuntu 20.04 上有完善的 apt 二进制包这也是我在 Jetson 上推荐的方式原因只有一个省时间。源码编译 Noetic 动辄几个小时而且可能因为 arm64 平台的小差异就要打补丁完全没有必要。添加 ROS 源并安装sudo sh -c echo deb http://packages.ros.org/ros/ubuntu $(lsb_release -sc) main /etc/apt/sources.list.d/ros-latest.list curl -sSL https://raw.githubusercontent.com/ros/rosdistro/master/ros.asc | sudo apt-key add - sudo apt update sudo apt install -y ros-noetic-desktop-full安装完成后初始化环境sudo apt install -y python3-rosdep python3-rosinstall python3-catkin-tools sudo rosdep init rosdep update echo source /opt/ros/noetic/setup.bash ~/.bashrc source ~/.bashrc这里有一个 Jetson 特有的大坑需要提前说。JetPack 5.x 预装了一套 NVIDIA 编译的 OpenCV带 CUDA 加速而ros-noetic-desktop-full在 Ubuntu 20.04 上依赖的是系统 OpenCV 4.2 生态。在某些安装组合下apt 会提示“以下软件包将会被移除”一类的冲突甚至想删掉 NVIDIA 的 python3-opencv。我建议在安装之前先干跑一次sudo apt install --dry-run ros-noetic-desktop-full如果看到会移除python3-opencv或者libopencv-dev你得决定是保留 NVIDIA OpenCV 做 CUDA 加速还是接受系统 OpenCV 保证 ROS 兼容性。我的经验是如果项目里重感知保留 NVIDIA OpenCV然后 ROS 相关的视觉包尽量从源码编如果项目重导航接受系统 OpenCV 问题不大反正导航栈不怎么用 GPU。5.2 CSI/USB 摄像头在 ROS 节点里的接入回退到 Ubuntu 20.04 JetPack 5 后摄像头驱动的适配方式也会变。这里分两种情况。USB 摄像头最简单直接用现成包sudo apt install ros-noetic-v4l2-camera rosrun v4l2_camera v4l2_camera_nodeCSI 摄像头在 Jetson 上要走 NVIDIA 的 GStreamer 插件不是普通/dev/video0那套。先验证硬件链路通不通gst-launch-1.0 nvarguscamerasrc ! video/x-raw(memory:NVMM),width1280,height720,framerate30/1 ! nvvidconv ! video/x-raw,formatBGRx ! videoconvert ! video/x-raw,formatBGR ! fakesink这条命令如果正常跑起来说明 ISP 驱动和摄像头标定都在工作。接下来可以在 ROS 里用gscam包把这条 GStreamer pipeline 包装成图像话题sudo apt install ros-noetic-gscamgscam 的配置文件里填gscam_config: nvarguscamerasrc ! video/x-raw(memory:NVMM),width1280,height720,framerate30/1 ! nvvidconv ! video/x-raw,formatBGRx ! videoconvert ! video/x-raw,formatBGR ! appsink跑起来之后用rostopic hz /camera/image_raw看帧率。如果帧率上不去优先检查nvarguscamerasrc的分辨率和 sensor 输出的匹配关系CSI 摄像头对格式非常敏感不匹配的时候会黑屏或者报格式错误。5.3 CUDA 与 TensorRT 在 ROS 感知链路中的接入ROS-noetic 本身不负责算力调度但它承载的感知节点通常需要 GPU。JetPack 5 里最实际的三板斧是OpenCV CUDA、TensorRT、以及 PyTorch 的 arm64 版本。先确认当前 Python OpenCV 是否启用 CUDApython3 -c import cv2; print(cv2.getBuildInformation())JetPack 预装的 OpenCV 4.x 通常已经带 CUDA编译信息里能看到CUDA: YES。如果有人在系统里又 pip 安装了一个不带 CUDA 的 OpenCV会导致之前 GPU 加速的图像处理全部失效这属于环境管理问题不是平台问题。部署深度学习模型时TensorRT 是 Jetson 上绕不开的性能担当。你可以把 PyTorch 或 ONNX 模型离线转成 engine 文件/usr/lib/aarch64-linux-gnu/nvidia/tensorrt/bin/trtexec --onnxmodel.onnx --saveEnginemodel.engine --fp16然后在 ROS 节点里加载 engine 做推理。需要注意两点第一Jetson Orin 的 GPU 架构是Ampere算力代号 SM 8.7。如果你自己编译 CUDA 代码编译参数要强制指定nvcc -archsm_87 mycode.cu或者用 CMakecmake -DCMAKE_CUDA_ARCHITECTURES87 ..第二JetPack 5 系列“没有 nvidia-smi”这点和你熟悉的服务器环境不一样。监控 GPU 状态的方式是sudo tegrastats sudo jtopjtop是 jetson-stats 工具带的比tegrastats直观很多能看 CPU、GPU、内存、功耗、温度占用率。5.4 分布式联调Orin 与 x86 工作站的 ROS Master 配置机器人项目里 Orin 通常不单独工作它可能负责感知x86 工作站负责导航或者人机界面。这种情况下要配好 ROS 主从机通信。在 Orin 上把主机名和 IP 记下来然后两边机器的/etc/hosts里都要有对方的解析192.168.1.100 orin 192.168.1.101 desktop假设把 x86 工作站当 ROS Master在 Orin 的~/.bashrc里写export ROS_MASTER_URIhttp://192.168.1.101:11311 export ROS_IP192.168.1.100注意ROS_IP要用 Orin 自己网卡上的实际地址不能用127.0.0.1否则 x86 那边订阅不到话题。如果两边都在同一个局域网一般不需要额外开防火墙如果rostopic list能跑但拿不到数据先ping测延迟再检查是不是有防火墙把 11311 端口挡了。ROS 消息在 x86 和 arm64 机器之间传递没有架构差异同一个sensor_msgs/Image在两边序列化结果是完全一致的所以不用担心 aarch64 和 amd64 平台的兼容问题。6. 回退后的性能调优与排坑记录6.1 功耗模式、锁频与散热Jetson Orin 默认情况下的 CPU/GPU 频率是由功耗模式控制的并不是一直跑在最高点上。回退系统后性能上限和 JetPack 6 时代可能不一样建议按实际场景调整。查看当前功耗模式sudo nvpmodel --queryAGX Orin 开发套件允许选择 MAXN 或不同瓦数档位需要最高性能时切换到 MAXNsudo nvpmodel -m 0如果跑 robot 任务时希望频率稳定避免调度抖动可以锁频sudo jetson_clocks但要明白jetson_clocks是把 CPU/GPU 频率拉满并且锁定这会显著增加功耗和温度。Orin 开发套件有风扇且系统会自动控制自行设计散热方案的第三方载板必须提前确认温度不然锁频状态跑到过热降频表现反而比不锁差。6.2 把工作负载容器化的注意事项JetPack 5 自带 Docker 和容器 GPU runtime这是把 ROS 环境打包部署的一条好路子。刷完系统后直接跑一个带 CUDA 的镜像做个验证docker run --rm --runtime nvidia --network host \ nvcr.io/nvidia/l4t-pytorch:r35.4.1-pth1.13-py3 \ python3 -c import torch;print(torch.cuda.is_available())如果输出True说明容器内可以访问 GPU。对于 ROS-noetic 任务我个人的做法是系统层面只装桌面-full 和必要驱动剩下和算法相关的依赖全部做进 Docker 镜像里。好处是回退、升级、换机器都能快速复现环境。不过也要提一句容器解决不了内核模块的问题。CSI 摄像头、某些工业相机、实时网卡的驱动都是跟内核强相关的容器里不能装内核模块。这类设备相关的能力最好还是直接放在物理系统里最省心。6.3 高频报错与处理对照回退过程中我积累了一些高频错误的处理方法整理成表方便你对照现象常见原因处理建议Recovery 模式下lsusb看不到0955:7023USB-C 线没数据能力或板卡没完全断电换数据线重新拔插拔掉电源后重进 Recovery刷机时报No such file or directory板级配置名写错用./flash.sh -l列出支持的板级名称apt 源里找不到 ros-* 包没有添加 packages.ros.org 源或用了错误的发行版代号按 5.1 步骤重新加源检查lsb_release -sc输出是 focal安装 desktop-full 提示移除 python3-opencvJetson 预编 OpenCV 与 ROS 依赖冲突先apt install --dry-run预判按项目侧重点取舍nvcc 报Unsupported gpu architecture compute_86编译目标没有覆盖 SM 8.7加-archsm_87或-DCMAKE_CUDA_ARCHITECTURES87CUDA 运行时报no kernel image is available二进制库和当前驱动版本不匹配使用 JetPack 5 配套的 CUDA/TensorRT 重新编译误执行 do-release-upgrade 后无法开机Jetson 不可常规跨大版本升级只能重新进入 Recovery 模式再刷机6.4 一点个人经验这段不是官方指导纯粹是个人习惯。我在反复刷 Jetson Orin 之后最大的体会是刷机本身不难难的是刷完之后的“环境复现”。所以哪怕当时只在这块板子上跑一个很小的 demo我也建议你把软件源、常用工具、ROS 版本、以及每一个需要手工下载的二进制包的地址全部写成安装脚本。否则每次回退系统都要手动点半天。另外如果你同时要维护多个 Orin 设备别用 SDK Manager 一台一台地刷那是灾难。把命令行烧录脚本固定到一个持续集成环境里新增一台设备只需要让它进入 Recovery 模式、跑一条命令剩下就是等。前期的脚本成本不高回报却非常大。最后再分享一个小技巧回退之后别急着把 JetPack 6 时期写好的/etc/apt/sources.list备份直接覆盖回去先对照一下 NVIDIA 源的地址是不是指向 focal里面一旦混入 jammy 路径后面每次apt update都会给自己埋雷。写完这篇文章的时候我手里的 AGX Orin 就是跑在 Ubuntu 20.04 JetPack 5.1.3 ROS-noetic 上的整套栈从导航到感知都工作正常虽然回退过程折腾了一点但对 ROS1 项目来说这确实是最省心的选择。