Orin NX完整系统迁移空板实战：从dd克隆到引导适配全记录

1. 为什么会出现“完整系统迁移到空板”这种需求

说实话，接到这个需求的时候我一开始是拒绝的。手里两台 Orin NX，一台是半年前就开始搭建、已经跑在产线上的“完整系统”，上面不仅有 JetPack 底包，还有一堆编译好的 TensorRT 引擎、Python 虚拟环境、Docker 镜像，甚至还有调了小半个月的设备树补丁；另一台是完全没拆封的“空板”，模块刚从包装盒里拿出来，连系统都还没烧过。需求也很直接：把完整系统上的所有东西搬过去，让空板开机后的状态跟原来的机器一模一样。

当时办公室里有两种声音。一种说直接拿 SDK Manager 重新刷机，然后把需要的包重新装一遍就行；另一种说干脆把原系统的整块盘 dd 下来，直接写入到新板。我之所以没有第一时间站队，是因为我太清楚 Jetson 这类设备的特殊性了——它跟 x86 台式机不一样，系统里哪怕只是 JetPack 版本差一个小版本号，都会牵动 CUDA 库、L4T 内核、GPU 用户态驱动之间的一整套依赖链。重新搭建看着很“干净”，实际上是在给自己埋雷：总有几个包你在半年后根本记不清是怎么装进去的，总有几个配置是你当时手动 patch 的但没写进任何文档。

更重要的是一个容易被大家忽略的事实：如果你做的是“看起来差不多的重装”，而不是“一模一样的迁移”，那新系统一定会出现各种脏环境带来的兼容问题。比如我之前遇到过 TensorRT 推理引擎突然精度变化，查到最后发现是 cuDNN 版本被 apt 自动升级了。所以这次我们定了基调：既然源系统已经稳定运行，迁移的第一原则就是“不重装、不手动搭环境”，尽量把这块板的完整存储状态复刻到空板上。

当然，这种需求也不是凭空冒出来的。其实行业内比较常见的一个场景就是“Orin Nano 开发者套件更换 Orin NX 模块”。很多人早期买的是 Orin Nano 开发者套件，用了一段时间发现算力不够，于是单独买个 Orin NX 模块换上。由于 Nano 和 NX 的载板在许多版本上是通用的，很多人天真地以为直接把模块拔下来插上去就能开机，实际却发现系统起不来，因为 JetPack 底包里的内核和设备树不完全匹配新模块。这就逼着你去解决迁移适配问题，而不是单纯地“换块卡”。

所以说，“完整系统迁移到空板”的核心不是拷贝文件，而是把一台设备在存储层、引导层、系统环境层、外设配置层的完整状态全部搬过去。这篇记录我会按自己的实际操作路线来写，可能不如官方文档那么“规整”，但每一步都是踩过真坑走下来的，希望对同样在做 Orin 平台迁移的人有点参考价值。

2. 动手之前必须拆解 Orin NX 的存储与启动链路

迁移的第一个关键点不是“怎么拷”，而是“拷什么”。如果你对 Orin NX 的存储拓扑没搞清楚，后面即使把镜像 dd 过去了，也大概率会在启动链路上卡住。

2.1 存储介质不只有 eMMC，还有 NVMe、UFS 和 SD

Orin NX 模块本身自带了一块 eMMC，容量一般是 16GB，里面通常会有一个基础引导系统。但实际用起来，绝大多数人不会只依赖这块 eMMC，因为 16GB 装完 JetPack 6.2 的基础系统后已经所剩无几，更不要说放模型和日志。所以开发套件的标准玩法是再插一块 NVMe SSD，系统直接装到 NVMe 上，eMMC 只保留必要的引导数据。

我做迁移时第一件事就是确认源系统究竟是跑在哪块盘上的。有些板卡配置复杂，可能 eMMC 上有一个完整的 JetPack，NVMe 上也有一个 rootfs，两个都能启动，这个时候就要看你平时使用的工作流到底从哪个介质引导。我这次两台设备都用的是 NVMe 主存储方案，eMMC 只是做引导辅助存在，所以迁移的重心就落在如何把 NVMe 上的完整系统搬到新板对应的 NVMe 上。

2.2 启动链的四个关键环节

Orin NX 的启动过程跟 PC 不太一样，它不是一个 BIOS 然后读硬盘那么简单。它的启动链路大致是：首先是模块上的 QSPI NOR Flash 里存放的 BootROM 和低级引导程序，这一步在出厂时就已经固化或者可以通过烧录工具写入；接着引导程序读取 eMMC 或外部存储上的 extlinux.conf 来定位 Kernel、设备树和 initrd；最后才挂载 rootfs 拉起整个用户空间。

如果源系统和目标系统在存储介质上保持一致，那么这个链路相对稳定；但如果源系统是跑在 NVMe 上、目标板却默认只从 eMMC 引导，你就必须在启动配置里做好介质切换。很多人迁移失败，根源就在于只复制了 rootfs 内容，却没有把引导链路的指向关系一起搬过来。

2.3 别忽略设备树和模块型号信息

Orin NX 模块的 EEPROM 里会记录模块型号、内存大小、序列号、板级配置等信息。U-Boot 引导时依赖这些信息来决定要加载哪一棵设备树（dtb）。如果目标板上没有正确写入匹配的设备树，或者模块 EEPROM 中的型号“与 JetPack 内置的 dtb 不匹配”，最容易出现的现象就是系统卡在 U-Boot 阶段，或者内核起来但网口、MIPI、串口等外设全部不可用。

很多从“Orin Nano 开发者套件更换 Orin NX”的朋友翻车，恰恰就是没考虑到这层。Orin Nano 和 Orin NX 模块的管脚定义虽然基本一致，但内核的设备树文件并不完全通用，直接把原来的镜像搬到 NX 上，开机大概率会提示找不到设备或者挂在某个驱动初始化环节。

所以在做迁移前的静态检查时，我建议一定先收集以下信息：

• 源系统使用的 JetPack / L4T 版本，例如 R35.5.0 或 R36.3.0；
• 根文件系统所在设备的节点，例如/dev/nvme0n1p1还是/dev/mmcblk0p1；
• 源系统的内核版本号，以及当前生效的 dtb 文件路径；
• 目标板模块的型号和内存大小（通过读取 EEPROM 的值或官方标签获取）。

这些信息不一定都要在迁移时用到，但如果你后面遇到启动异常，它们就是你排查的第一手依据。迁移不是无脑拷贝，先把“家底”摸清楚，后面每一步才会顺。

3. 迁移路线横向对比：dd、镜像包、SDK Manager 选哪个

把需求和安全边界都摸清楚之后，接下来就是选路线。我把常见做法分成三类，做了张表对比，也给出最终选择的理由。

如果只看“能不能开机”，那 SDK Manager 肯定是最省事的选择。但这次的要求不是“能开机”，而是“和原系统保持一致”，所以我直接把第三种抹掉了。至于第二种 tar 方案，它的灵活度高，但是要考虑的细节太多，比如 fstab 里的 UUID、initramfs 的生成、extlinux.conf 里的 root 设备参数，任何一个地方错了都可能让系统在启动时进入 emergency mode，排查起来非常折腾。

最终我选的是“dd 全盘克隆 + 目标板引导适配”的组合方案。为什么选这个组合，原因有三个：

第一，dd 可以直接把原 NVMe 盘的所有内容原样搬到镜像文件里，包括分区表、GPT 头、保留区，甚至连原来的 PARTUUID 都保留下来了，这听起来很省事。但这里同时埋了一个坑：目标板的系统一旦也用了相同的 PARTUUID，两块板子如果同时出现在同一网络里，系统会分不清到底哪个是根分区，容易出现启动到一半挂载错盘的情况。这个问题我在后面专门有一节来处理，只要用 sgdisk 重新随机化 PARTUUID 就能避免。

第二，dd 出来的镜像可以直接用写盘工具压进目标板的 NVMe 中，也可以先挂载回环来检查内部的目录结构，确认分区布局没有被损坏。相比 tar 的方案，dd 能最大限度保留原有环境的“原汁原味”。

第三，dd 的兼容性问题主要集中在“目标盘和源盘容量不一致”或者“启动介质不同”这两种情况。这次我已经提前确认了两块 Orin NX 使用完全相同的 NVMe SSD 型号和容量，最大阻碍直接消失。

当然选 dd 不代表闭着眼睛跑一条命令就完事。实际操作时，我强烈建议提前准备一个临时启动介质，或者把源板接到另一台主机上做离线 dd，尽量避免对正在运行的系统盘直接 dd，因为运行中的文件系统会持续写入，镜像内部的元数据可能不一致，最终出来的系统稳定性完全没有保障。我这次的做法是：先把源业务的进程全部停掉，再通过外接 USB 启动到另一个最小系统里，然后再对 NVMe 做块级别的克隆。

4. 实操流程：抓镜像、写盘、适配引导的三段论

路线定了，剩下的就是执行。整个流程我把它拆成三个阶段：抓镜像、写盘、适配引导。下面结合实际命令来说，命令部分大部分适用于标准 L4T 环境，不同小版本之间路径可能有差异，思路是一致的。

4.1 第一阶段：把完整系统抓成镜像文件

因为要尽量保证一致性，我先把源板临时从正常的 NVMe 系统引导到了 USB 上的一个轻量 Ubuntu 系统里。这个轻量系统不需要多复杂，只要能识别 NVMe 设备、留下 dd 和 sgdisk 这两个工具就行。

登录后，我先确认设备节点的对应关系：

lsblk -o NAME,SIZE,FSTYPE,MODEL,MOUNTPOINT nvme list

执行结果里一般可以看到/dev/nvme0n1就是那块完整系统的系统盘，没有挂载点，说明没有被占用。接下来对整盘做镜像：

sudo dd if=/dev/nvme0n1 of=/mnt/usb_backup/orin_full_2025.img bs=64M conv=sync,noerror status=progress

参数说明一下：bs=64M是单次读写块大小，对于 NVMe 这种大块设备来说能显著提升 dd 速度；conv=sync,noerror的含义是如果某个块读失败就跳过但继续执行，同时用填充块保持总长度不变，避免后续分区偏移错位。如果你的原盘是健康的，这个参数纯粹是为了保险。

由于源盘是 1TB 的 NVMe，整盘 dump 出来的镜像非常大，我建议直接存到另一个同样容量甚至更大的存储上，不要中途做分区再挂载再拷贝，那样会引入额外变量。如果实在没有大容量存储，也可以用管道把 dd 和压缩串起来：

sudo dd if=/dev/nvme0n1 bs=64M status=progress | bzip2 > /mnt/usb_backup/orin_full_2025.img.bz2

但这种方法在后续写盘时需要先解压，耗时比较长，我自己更推荐直接存原始镜像，空间不够就挂一块临时硬盘。

4.2 第二阶段：把镜像写进目标空板

镜像抓完之后就轮到空板。这里有个特别容易踩的误区：有人以为直接把 NVMe 从源板拆下来插到目标板就能解决问题，或者把镜像写进一块新 NVMe 后就认为万事大吉。事实上 Orin NX 的模块如果不先具备可用的低级引导链，光有一块带系统的 NVMe 插上去是没法开机的。

所以我在写盘前的准备工作是：把目标模块先装到开发套件载板上，进入恢复模式，用 SDK Manager 做一次最基本的刷写。这一步不是要刷完整环境，而是让模块上的 QSPI 引导程序处于一个可用状态。这块“最小系统”不需要完整 JetPack，只要能够从 USB 或者 SD 卡启动到一个临时系统即可。校验目标板能正常进入恢复模式后，再执行同样的挂载操作，把镜像写入目标 NVMe：

sudo dd if=/mnt/usb_backup/orin_full_2025.img of=/dev/nvme0n1 bs=64M status=progress sync

写完之后不要急着拔盘，先确认一下写入结果的分区表是否完整：

sudo parted -l

正常情况下应该能展现出和源盘一致的分区布局。看到几个主要分区都识别出来了，就可以进入下一阶段。

4.3 第三阶段：引导适配和扩容收尾

这一步是迁移全程最需要细心的部分。由于我们做的是整盘复制，镜像里面的 PARTUUID 和原来完全一致，如果不处理，插到目标板上后大概率会出问题，尤其是在两块板同时使用同一个镜像来源的情况下，PARTUUID 冲突会让系统随机加载另一块盘的根分区，听上去很离谱，但确实是实际会发生的。

先随机化目标盘的 GPT 的 UUID 和所有分区的 PARTUUID：

sudo sgdisk --randomize /dev/nvme0n1

这一条命令会重新生成盘级 GUID 和分区 GUID，而不会动实际文件系统数据。执行完之后建议重启一次系统，因为旧系统里/etc/fstab记录的还是旧的 PARTUUID，引导时需要用 disk-by-uuid 的方式重新定位根分区。如果不更新 fstab，可能出现“系统明明写进去了，却报找不到 root device”的假故障。此时进入临时系统，挂载根分区，编辑/etc/fstab，把根分区的 UUID 字段替换为新的值：

sudo blkid /dev/nvme0n1p1 sudo mount /dev/nvme0n1p1 /mnt/target sudo nano /mnt/target/etc/fstab

如果源镜像原本就是按根分区的位置启动，而目标盘和源盘容量一致，那么只需要更新 PARTUUID 即可，不涉及扩容。但很多人的目标盘比源盘大，这时候整盘克隆只会用掉与新盘容量匹配的头部区域，剩余空间全是未分配状态。处理方法是先删除原有分区，再用 growpart 扩展最后一个分区，最后 resize2fs 扩展文件系统。这里请务必对 GPT 分区结构足够熟悉再动手，不然容易把分区删错。

sudo growpart /dev/nvme0n1 1 sudo resize2fs /dev/nvme0n1p1

镜像写盘结束后，还要顺手检查内核和设备树。如果源板和目标板的 SoM 型号完全一致，比如都是 Orin NX 16GB，这一步通常可以跳过；但如果你是从 Orin Nano 换到 Orin NX，或者从 8GB 换到 16GB，那么 boot 分区里的 extlinux.conf 可能还指向旧的内核和设备树。此时需要把 L4T 包里对应新模块的 Image、dtb 文件更新到启动分区，并确认 extlinux.conf 中的FDT路径指到了新 dtb 上。

5. 迁移后的核验清单：不等同于“能开机”

写盘完成、系统能正常进桌面或者能通过 SSH 登录，只代表“能开机”，不代表迁移成功。一个真正合格的验证流程，要覆盖设备身份、系统组件、外设状态和应用性能这几大块。

先说设备身份。因为整盘克隆会连/etc/hostname、/etc/machine-id、SSH host key 这些“身份标识”一起复制过去。如果源板和目标板以后要同时运行在同一网络里，两个系统拥有相同的 SSH host key 会导致中控端把两者识别成同一台设备，连接时会出现 fingerprint 冲突甚至被中间人攻击的报错。我的处理方式是删掉旧的 machine-id 和 SSH host key，然后重新生成：

sudo rm /etc/machine-id /var/lib/dbus/machine-id sudo systemd-machine-id-setup sudo ssh-keygen -A

这样目标板就会拥有全新的身份，不会再被误认为源板。

然后是系统组件。JetPack 平台最怕的就是 CUDA 和 L4T 内核版本对不上，迁移完建议用这几个命令快速确认：

nvcc --version cat /etc/nv_tegra_release sudo apt list --installed | grep libcudnn | head -n 5

同时检查一下当前系统加载的内核版本和 boot 分区里的 Image 是否一致。如果原系统里有自己打过补丁的内核模块，还要确认它们在新板上的加载状态，比如：

lsmod | grep nvgpu dmesg | grep -i nvpci

还有一块很容易被忽略的地方是/opt/nvidia目录下的 JetPack 工具链，比如 jetson-io 工具、nvpmodel、tegrastats 这些。迁移后最好跑一遍tegrastats确认 power state 和 CPU/GPU 频率识别正常。如果源板之前配置过自定义功耗模式，那这些配置也残留在了 rootfs 里，迁移后因为模块型号一致，通常可以直接沿用，但为了保险还是跑一次sudo nvpmodel -q看当前处于哪个模式。

外设状态方面，重点检查 Ethernet/MIPI/SPI/UART 这些接口是否在设备数树加载后被正确枚举。跑一下：

dmesg | grep -E "eqos|eth0|mip|csi|spi|uart"

如果有某个设备没有出现，优先考虑是设备树不匹配，而不是硬件坏了。

最后是性能一致性。应用层的验证很简单，拿一个固定的推理模型在源板和新板上各跑一遍，比较单次推理时间。比如一个 TensorRT 的优化引擎，如果在源板上跑 15ms，目标板跑到 30ms，那明显有问题。常见原因是持久化缓存目录（如~/.cache/tensorrt）里存了源板上编译时的设备信息，导致引擎被错误复用或者重新转换。删掉 TensorRT 缓存并重新构建引擎就能解决。

6. 踩坑复盘：这次迁移最值得记住的几个经验

前面那部分是“应该怎么做”，这部分我想聊点更实在的，就是我们在实际操作中遇到的坑。这些坑不看一次文档的话，根本不会有人提醒你。

第一个坑是关于源板“冷克隆”的必要性。我一开始为了省事，直接在生产环境上对 NVMe 做了 dd，虽然业务进程已经停了，但系统后台还有很多 daemon 在写日志，比如 systemd-journald 就一直在写/var/log/journal。结果镜像出来之后我尝试直接挂载检查，发现日志目录下的某些文件包含未刷盘的数据，整个文件系统虽然没有大碍，但既然是做迁移，就不该容忍这种不确定性。后来的做法是改用 USB 启动临时系统，彻底避免源 NVMe 被任何进程挂载，再执行 dd。这一步虽然多花半小时，但换来的是一致性和安心感。

第二个坑是 PARTUUID 冲突。说实话，我第一次做这种整盘复制时并没有太在意 UUID 的问题，想着 clonezilla 之类的工具不是也会保留 UUID 吗，结果板子一插上去，等系统起来之后能看到两块盘被识别为同一个 root，系统直接进 emergency mode。后来才反应过来，我们数据中心确实有同时挂载多块相同克隆盘的场景。解决办法就是sgdisk --randomize加上更新/etc/fstab，但这里要特别强调：sgdisk --randomize不会改文件系统内部的 UUID，只会改 GPT 分区表中的 PARTUUID，所以如果你在 fstab 里用的是PARTUUID=开头的写法，那条命令才会生效；如果是老式的UUID=写法，那你还要考虑文件系统自身的 UUID 是否需要重置。

第三个坑是从 Orin Nano 开发者套件迁移到 Orin NX 模块时的 dtb 匹配问题。如果你也是打算“板子换模块”而不是“整机迁移”，一定要提前确认模块型号对应的 dtb 是否被包含在 JetPack 底包里。有些场景下，因为载板版本不同，nVIDIA 会把若干设备树打包在一起，比如tegra234-p3737-0000+p3668-0000-a1.dtb这种型号化文件。当你的模块型号不在默认列表里，引导阶段就会因为找不到合适的 dtb 而卡在No FDT found的提示上。我的建议是不要在开机后才去查，迁移前就在 host 端的 L4T bootloader 目录里用命令确认目标模块型号对应的 dtb 文件是否存在。

find /path/to/L4T/Linux_for_Tegra/kernel/dtb -name "*p3668*"

如果不存在，就需要手动从 NVIDIA 的官方 L4T 包中获取，或者根据载板硬件修改设备树。

第四个坑是网络和 MAC 地址。Orin NX 的网卡 MAC 地址其实存储在模块 EEPROM 中，整盘克隆不会影响它，源板和目标板之间的网卡 MAC 一开始就是不同的，所以网络层面不会冲突。这一点反而比 x86 虚拟机里的00:0c:29克隆安全得多，算是一个好消息。

最后一个建议：迁移前一定要找一个独立的大容量存储做中转区，尽量别依赖网络传输镜像。网络传一个大文件，中途断一次、校验失败一次，代价远高于直接用本地外接硬盘 copy。我们这次就是通过网络 NFS 传镜像，结果第二次传输时读到了早已变化的源盘结果，导致白写了一整轮。后来老老实实用 USB 硬盘中转，效率反而高了不止一倍。

回顾这次完整迁移，我觉得最关键的经验可以总结成一句话：迁移 Orin NX 这类设备，方案的重心不在于“拷贝”，而在于“计算好拷贝后需要修补哪些设备和系统的元数据关系”。引导链、分区 UUID、设备树、主机身份，这三样东西只要处理到位，整盘克隆就是一条又稳又省事的路线；处理不到位，那就等着在一次一次的启动失败里反复折腾。希望这篇实录能帮有同样需求的人少走几步弯路。