【踩坑复盘】Jetson AGX Thor 折腾记：从 WSL2+SDK Manager 的“USB穿透地狱”到 U盘重装

70asunflower2026-07-21 8:23

TL;DR（摘要）

本文记录一次完整的 NVIDIA Jetson AGX Thor 开发板系统烧录与调试实录，分成两条路线：

  1. 第一阶段（失败） ：尝试在 Windows 宿主机上用 WSL2 + usbipd-win 穿透 USB、配合 SDK Manager 跨系统刷机，一路踩遍 UEFI 网络启动、开发者账号授权、UsbDk 驱动冲突，最后卡在"设备显示已 Attached，SDK Manager 却死活找不到板子"的玄学问题上。
  2. 第二阶段（救砖） ：果断放弃 Windows 跨系统刷机链路，改用 U 盘本地引导重装。结果这条路也没一帆风顺------balenaEtcher 打开 ISO 直接崩溃、官方安装脚本因板型字符串不匹配报 Unsupported board! 把安装器干崩。最终通过现场 bind mount 伪造设备树 + 重启 Subiquity 服务，零重启救砖成功。
    核心结论：不要和复杂的中间层驱动死磕；当工具链成本高于开发成本时，果断换路。

目录

  1. 预备知识：Jetson Thor 常见远程连接方式

  2. 第一阶段：WSL2 + SDK Manager 刷机链路（及其崩溃）

    • 坑一：卡在 Start HTTP boot over IPv4 无法开机
    • 坑二：SDK Manager 提示 User is not authorized
    • 坑三：Windows WSL2 下的 USB 穿透拉锯战（usbipd-win & UsbDk）
    • 坑四：终极幽灵 ------ 设备已 Attached，SDK Manager 依然找不到板子

  3. 及时止损：放弃 Windows 链路，转向 U 盘重装

  4. 第二阶段：U 盘重装实操与现场救砖

    • 坑一：balenaEtcher 打开 ISO 报错 requestMetadata is not a function
    • 坑二：U 盘引导报 Unsupported board!，安装程序崩溃（生成 unknown.crash）
    • 坑三：安装后期大量刷屏 subiquity/Meta/status_GET:

  5. 总结与给同行的建议

1. 预备知识：Jetson Thor 常见的远程连接方式

在正式刷机前，连接 Jetson Thor 主要有以下几种途径：

  • USB-C 虚拟网卡直连（最推荐） ：用 Type-C 线连接电脑与 Jetson（常规 USB-C 口），默认 IP 为 192.168.55.1，通过 ssh username@192.168.55.1 即可免网线登录。
  • 局域网 SSH / VS Code Remote ：开发板接入路由器后，通过局域网 IP 进行 SSH，结合 VS Code Remote - SSH 插件体验最佳。
  • 串口控制台（Serial Console） ：连接 Debug 专用 USB-C 口，波特率设为 115200，用于网络彻底中断或 Bootloader 阶段排查。
  • 桌面图形（NoMachine / VNC） ：推荐 NoMachine ARMv8 版本，硬件渲染性能优于传统 VNC。

2. 第一阶段：WSL2 + SDK Manager 刷机链路（及其崩溃）

为了在 Windows 宿主机上运行基于 Linux 的 SDK Manager，需要把 USB 端口从 Windows 穿透给 WSL2 虚拟机。这条路线以下面四个坑告终。

2.1 坑一：卡在 Start HTTP boot over IPv4 无法开机

开机测试时，屏幕停留在 Start HTTP boot over IPv4 或 Start PXE over IPv4 并不断超时。

原因分析 ：这是 UEFI 固件的备用引导机制。当 Jetson 无法在本地 SSD（NVMe）或 eMMC 中找到有效的引导分区（GRUB/EFI）时，就会尝试通过网线进行 PXE/HTTP 网络启动。

解决尝试：

  1. 开机狂按 ESC 进入 UEFI BIOS。
  2. 在 Boot Options 中将 NVMe 移动到第一启动项。
  3. 若 UEFI 中压根找不到 NVMe，需要重新插拔硬件，或确认 SSD 是否需要重新烧录系统。

2.2 坑二：SDK Manager 登录报错 User is not authorized

准备使用 SDK Manager 烧录时，客户端弹窗提示：User is not authorized on NVIDIA developer server。

原因分析 ：普通 NVIDIA 账号（如 GeForce / Game Ready 账号）未签署 NVIDIA Developer Program 开发者协议，或者浏览器跳转时 Token 传回失败。

解决办法：

  1. 前往 NVIDIA Developer 官网 登录并补全个人/组织信息，勾选同意开发者协议。
  2. 使用浏览器的无痕模式（Incognito）重新走 OAuth2 认证流程。

2.3 坑三：Windows WSL2 下的 USB 穿透拉锯战

为了让 SDK Manager 能识别到板子，需要用 usbipd-win 把 USB 端口穿透给 WSL2。在这个环节经历了三连扣：

usbipd-win 命令不存在

  • 解决 ：运行 winget install dorssel/usbipd-win，重启管理员终端。

There is no WSL 2 distribution running

  • 原因：WSL2 在没有活跃终端时会自动挂起。
  • 解决 ：按下 Win + R 输入 wsl 唤醒虚拟机，并保持该命令行窗口最小化。

终极拦截者：****Failed to attach device 与 UsbDk 冲突

在运行 usbipd attach --wsl --busid 1-1 --auto-attach 时，控制台疯狂输出 Failed to attach：

text 复制代码 
WSL 2026-07-16 19:46:00 Device 1-1 is available. Attempting to attach...
WSL 2026-07-16 19:46:00 Failed to attach device 1-1
  • 原因 ：系统安装了 UsbDk（如随 Wireshark 或模拟器安装的底层 USB 过滤驱动），强行霸占了 USB 控制权。
  • 解决 ：在 Windows"安装的应用"中卸载 UsbDk Runtime Libraries，彻底重启电脑后恢复正常。

2.4 坑四：终极幽灵 ------ 设备已 Attached，SDK Manager 依然"找不到板子"

解决 UsbDk 后，usbipd 终于输出了理想的成功日志：

text 复制代码 
WSL Attach command for device 1-1 succeeded.
WSL Device 1-1 is now attached.

然而，回到 SDK Manager 点击 Refresh，界面依然顽固地显示：Could not detect a board。

深层原因拆解：

  1. USB 模式错位 ：检查 usbipd list 的 Vendor:Product ID，设备停留在 0955:7045（Tegra On-Platform Operator / 串口调试模式），而 SDK Manager 要求的 Recovery 刷机模式必须是 APX 状态（如 0955:7026 / 0955:7023）。
  2. 物理接口差异：插在了 Debug / OOB 调试口，而不是 J81 / Flash 专用强刷接口。
  3. WSL2 的 USB 描述符丢失 ：即便 usbipd 完成了底层的端口映射，Windows 到 WSL2 虚拟网桥的设备描述符透传，在复杂多复合 USB 设备（USB Composite Device）上容易丢包或识别不完整。

3. 及时止损：放弃 Windows 链路，转向 U 盘重装

排查完接口、重新冷启动进 Force Recovery 模式、校验 USB ID 后，面对 Windows Host → WSL2 → SDK Manager 这条过长的调用链中难以预测的玄学问题，我决定放弃这条路径。

最终解决方案：直接放弃 Windows + WSL2 + SDK Manager 的跨环境强刷方案，改用 U 盘镜像 / 烧录盘进行本地重装引导。第一阶段先走通了"做盘 → UEFI 选 U 盘启动"的基本流程：

  1. 将系统 Boot 镜像或官方 L4T 根文件系统制作成可引导 U 盘。
  2. 插入 Jetson Thor，开机按 ESC 进入 UEFI Boot Menu，直接选择 U 盘启动。
  3. 一路顺利完成安装，成功打通系统。

⚠️ 镜像版本提示 ：NVIDIA 会持续更新 JetPack / L4T 镜像。本文写作时（2026 年 7 月）参考文章中直接提供的镜像链接已经失效或不适用，务必前往 NVIDIA 官方下载页 获取当前最新版本。

针对 NVIDIA Jetson 开发者套件（包括 Jetson Thor 和 Orin 系列），NVIDIA 目前已经采用了全新的统一 ISO 镜像机制。

以下是官方最新的下载渠道和对应网址：

1. 官方最新版本下载页面（推荐 🌟）

如果你想体验最新的系统，可以前往 JetPack 的主下载页面。目前最新的版本是 JetPack 7.2 (对应 Jetson Linux r39.2) ，它带来了更完善的 Agentic AI 支持以及更稳定的统一 ISO 引导安装：

  • 最新下载主页 ：NVIDIA JetPack SDK Downloads
  • (进入该页面后，点击 "Download JetPack ISO Image" 按钮即可直接下载最新的 .iso 统一镜像；你也可以在此页面下载最新版的 SDK Manager )

2. 历史版本归档页面（如果你需要找特定的旧版本）

如果你因为项目兼容性（例如特定版本的 CUDA、TensorRT 或驱动），需要找回你截图里正在使用的 JetPack 7.0 (对应 Jetson Linux r38.2) 或其他历史版本，可以在归档页面找到：

  • 历史归档页面 ：NVIDIA JetPack Archive
  • (点击页面中的 "JetPack 7.0" 进入专属子页面，即可找到当时版本的 ISO 镜像下载入口)

💡 避坑小贴士

  1. 建议使用 Rufus 烧录 ：由于 balenaEtcher 的 JS 解析器存在兼容性 Bug，在 Windows 环境下强烈建议直接使用 Rufus 导入你下载好的 .iso 文件并写入 U 盘。
  2. SBSA 架构变化 ：从 JetPack 7 开始，Jetson 系统引入了类似服务器的 SBSA 标准。这意味着无论是 Orin 还是 Thor，现在都使用同一个统一的 .iso 文件来进行 USB/UEFI 引导安装。只需写入 U 盘后插在开发板上，开机进入 UEFI 菜单选择 U 盘启动即可。

参考链接

4. 第二阶段：U 盘重装实操与现场救砖

硬件平台 ：NVIDIA Jetson AGX Thor Developer Kit (128GB)

镜像版本 ：jetsoninstaller-0.2.0-r38.2-arm64.iso（JetPack 7.x 统一 ISO）

宿主机环境：Windows 11

NVIDIA 在最新的 JetPack 7.x 中为 Jetson Thor 带来了类似 PC/服务器的 SBSA（服务器基准系统架构）+ 统一 ISO 引导机制。原本以为像给普通 PC 刷系统一样插上 U 盘就能搞定，结果在实际操作中接连踩中了烧录软件 Bug 和官方脚本检测逻辑的硬伤。

本阶段完整记录 U 盘刷机遇到的三个核心"坑点"及免重启救砖方案。

4.1 坑一：balenaEtcher 打开 ISO 报错 requestMetadata is not a function

故障现象 ：在 Windows 下使用 balenaEtcher 导入下载好的 .iso 镜像时，弹窗报错：

打开开源镜像时出错

错误信息：(0 , h.requestMetadata) is not a function

原因分析 ：这是 balenaEtcher 特定版本（尤其是 v1.19.x 系列）内置 JavaScript 运行库的 TypeError 。由于 balenaEtcher 基于 Electron 框架开发，其元数据解析模块（Metadata Parser）在读取 Jetson Thor 这类特殊的 ARM64 ISO 镜像头信息时调用了未定义的函数，导致前端解析崩溃。

解决方案：

  • 最佳方案 ：放弃 balenaEtcher，直接使用 Windows 原生开源轻量工具 Rufus 或 Ventoy 进行 ISO 写入。
  • 次选方案 ：将 balenaEtcher 降级至旧的稳定版本（如 v1.18.11）。

4.2 坑二：U 盘引导报 Unsupported board!，安装程序崩溃（生成 unknown.crash）

故障现象：U 盘引导进入安装阶段后，屏幕刷出大量 Shell 脚本调试日志，随后提示：

text 复制代码 
/ai/jetsoniso_setup.bash: line 233: warning: command substitution: ignored null byte in input
+ board='NVIDIA Jetson Thor Developer Kit'
+ case $board in
+ echo 'Unsupported board!'
Unsupported board!
+ exit 1
An error occurred. Press enter to start a shell
...
written to /var/crash/1751465084.628017187.unknown.crash
root@ubuntu-server:/var/snap/subiquity/6808#

随后系统直接抛出 exit 1，导致 Ubuntu 的 Subiquity 安装器生成崩溃日志，并将用户踢入紧急救援终端（Emergency Shell）。

原因分析 ：这是官方安装脚本与开发板出厂固件之间的字符串不匹配（字面量匹配）Bug：

  1. 脚本 /ai/jetsoniso_setup.bash 通过读取内核设备树 cat /sys/firmware/devicetree/base/model 获取当前板卡名称。
  2. 开发板 QSPI / UEFI 返回的字符串是：NVIDIA Jetson Thor Developer Kit。
  3. 但脚本内部的 case 分支写死了极其严格的匹配规则，只认可带有 AGX 三个字母的字符串 "NVIDIA Jetson AGX Thor Developer Kit"。
  4. 因为少了 "AGX"，脚本触发了兜底分支打印 Unsupported board!，并返回非零状态码退出，导致上层 Subiquity 服务崩溃。

救砖解决方案（免重启，现场黑客打补丁） ：既然已经落到了 root@ubuntu-server 的 Emergency Shell，完全不需要重启或重新刷盘，利用 Linux 内存文件系统（tmpfs）在终端现场修复：

步骤 1：利用 Bind Mount 伪造设备树型号

在当前 Shell 中执行以下命令，将系统设备树节点的返回值伪造成脚本期望的格式：

bash 复制代码 
# 1. 在内存 tmp 目录下生成带 AGX 的规范字符串文件
echo -n "NVIDIA Jetson AGX Thor Developer Kit" > /tmp/model_fake

# 2. 通过 bind mount 覆盖 sysfs 节点
mount --bind /tmp/model_fake /sys/firmware/devicetree/base/model

# 3. 校验伪造是否生效
cat /sys/firmware/devicetree/base/model
# 应输出：NVIDIA Jetson AGX Thor Developer Kit

步骤 2：重启 Subiquity 安装服务

查看并重启控制安装流程的 Snap 服务：

bash 复制代码 
# 重启 Subiquity 后端服务
systemctl restart snap.subiquity.subiquity-server.service

# (可选) 重新跑一次初始化预配置脚本验证
bash /ai/preseed.sh Jetsoniso

步骤 3：退出 Shell 恢复图形安装界面

在终端输入：

bash 复制代码 
exit

回车后，控制权交还给 Subiquity，系统会自动跳过卡死节点，重新加载进入正常的 Ubuntu 24.04 系统安装向导。

4.3 坑三：安装后期大量刷屏 subiquity/Meta/status_GET:

故障现象 ：在软件包解压安装阶段（屏幕显示 Installing many packages, wait for 15mins..），终端底部不断重复打印：

text 复制代码 
start: subiquity/Meta/status_GET:
start: subiquity/Meta/status_GET:

机制科普 ：无需担心，这是完全正常的状态！

Ubuntu 24.04 的 Subiquity 安装程序采用了前后端分离架构：

  • 后台（Server） ：正在默默进行几百个驱动包、L4T 内核（nvidia-l4t-kernel）和 Docker 依赖的解压与写入。
  • 前台（Client） ：为了获取安装进度，会每隔几秒向后台发送一次 HTTP GET 请求（即 status_GET 轮询）。

只要底部的进度光标在闪烁，说明安装程序正处于健康的高速解压阶段，耐心地等待 15~20 分钟即可。

5. 总结与给同行的建议

"不要和复杂的中间层驱动死磕，当工具链成本高于开发成本时，果断换路。"

第一阶段（WSL2 路线）的教训：

  1. 避免跨系统底层刷机 ：NVIDIA SDK Manager 本身对 Linux 原生环境依赖极高。在 Windows 上通过 WSL2 + usbipd-win 刷机，极易在 USB 描述符、多接口重定向（Composite Device）和自动重启重连（Auto-attach）上掉坑。如果有条件，首选双系统 Linux 或直接准备一台 Ubuntu 物理机。
  2. 硬件接口要认准：Jetson 开发套件的 Debug 口和 Flash 口有严格区分，刷新固件前务必查阅 Hardware Layout 确定 J81 / Recovery 接口位置。

第二阶段（U 盘路线）的注意事项：

  1. 重启前务必拔 U 盘 ：当看到安装完成并准备 Reboot 时，必须第一时间拔掉安装 U 盘！否则 Jetson Thor 的 UEFI 会再次优先加载 U 盘，导致重新进入安装流程（无限循环）。
  2. 离线关机与后期配置 ：安装成功进入 Ubuntu 桌面后，哪怕当前没有连接网络也可以安全关机（sudo poweroff）。因为底层驱动（BSP）已完整写入 NVMe 固态硬盘，后续等接入网络后，再从容运行 CUDA 13、TensorRT 10 及 JetPack SDK 软件栈的安装步骤（即官方文档 Step 3 之后的应用层部署）即可。
  3. 烧录工具选对 ：遇到 balenaEtcher 崩溃，直接用 Rufus / Ventoy 替代，别在烧录软件上浪费时间。
  4. 现场救砖优先零重启方案 ：官方脚本的字符串匹配 Bug 用 bind mount 伪造设备树即可绕过，无需重刷。

希望本篇踩坑记能帮助遇到相同问题的开发者快速定位并解决问题！

热门推荐
012026年7月AI圈大地震：GPT-5.6被政府限制、Claude入驻Slack、Anthropic自研芯片02GitHub 镜像站点03如何新建文件夹？ 电脑新建文件夹的4种方法04幻兽帕鲁 - 服务器管理员权限与 GM 命令完全指南05AI科技热点日报 | 2026年07月01日06国内可直接用、免费额度/永久免费的大模型API清单（含 SiliconFlow、火山、阿里、智谱、百度、Kimi、DeepSeek、DMXAPI 等）07AI 编程 IDE 全景解析 2026：Agent 全面接管开发链路08【AI前线观察】2026年国产开源大模型全面横评：从 DeepSeek V4 到 Kimi K3，谁才是开发者的最优选择？092026 年 AI 大模型 & AI 编程工具实战全总结102026 国产 AI 大模型横评：DeepSeek、通义千问、Kimi、文心一言、星火、豆包谁更能打？