3、镜像制作基础：理解系统镜像的概念、类型（SD卡镜像、QSPI镜像、容器镜像）以及制作镜像前的系统清理和优化
在Jetson平台的项目交付中，镜像（Image）是软件交付的核心载体。无论是将开发完成的系统移植到多台设备，还是为客户提供可复现的部署包，镜像制作都是决定交付效率与质量的关键环节。本章将系统梳理系统镜像的基本概念、三种主流镜像类型（SD卡镜像、QSPI镜像、容器镜像）的适用场景与制作要点，并重点讲解制作镜像前的系统清理与优化流程——这是确保镜像体积精简、启动稳定、无冗余数据的关键前置步骤。
3.1 系统镜像的核心概念与分类逻辑
系统镜像本质上是文件系统、引导程序、内核、设备树（DTB）以及用户应用在特定时刻的“快照”。在Jetson平台上，镜像不仅包含操作系统本身，还涉及NVIDIA特有的底层固件（如TegraBoot、MB1、MB2）、内核模块、CUDA/OpenCV等加速库的版本匹配关系。理解镜像类型，首先要明确它们各自所处的系统层级：QSPI镜像位于芯片内部或板载SPI Flash中，负责最底层的引导；SD卡镜像承载完整的根文件系统与用户数据；容器镜像则运行在宿主机操作系统之上，封装应用及其依赖环境。
| 镜像类型 | 存储位置 | 包含内容 | 典型大小 | 更新频率 | 适用场景 |
|---|---|---|---|---|---|
| SD卡镜像 | MicroSD / eMMC | 完整根文件系统、内核、模块、用户数据 | 8GB ~ 64GB | 低（版本迭代） | 批量生产、现场恢复、开发备份 |
| QSPI镜像 | 板载SPI Flash | Bootloader、内核、DTB、启动参数 | 16MB ~ 64MB | 极低（固件升级） | 引导修复、安全启动、硬件初始化 |
| 容器镜像 | 宿主机磁盘（Docker层） | 应用代码、运行时库、依赖包 | 数百MB ~ 数GB | 高（应用迭代） | 应用分发、多环境隔离、快速回滚 |
从工程实践角度看，三种镜像并非互斥关系。一个完整的Jetson交付物通常包含：QSPI镜像（确保设备能正常引导）+ SD卡镜像（提供可运行的系统环境）+ 容器镜像（承载具体业务应用）。例如，在工业质检项目中，QSPI镜像保证设备上电后能加载内核，SD卡镜像提供Ubuntu 20.04 + JetPack 5.1.2的运行环境，而容器镜像则封装了基于TensorRT的推理服务。这种分层设计使得底层系统保持稳定，而上层应用可以独立迭代。
3.2 SD卡镜像：制作方法与完整流程
SD卡镜像是项目交付中最常用的镜像形式。其制作原理是将整个SD卡（包括分区表、引导分区、根文件系统）逐位复制为一个.img文件。在Jetson平台上，SD卡通常包含两个分区：一个FAT32格式的引导分区（存放内核、DTB、initrd），一个ext4格式的根文件系统分区。
制作SD卡镜像的标准流程如下：
- 准备干净的系统环境：在目标Jetson设备上安装好JetPack SDK，完成所有驱动验证（摄像头、GPU、网络接口）。
- 执行系统清理（详见3.4节）：删除缓存、日志、临时文件，移除开发工具链。
- 卸载所有外部挂载：确保没有外部存储设备（U盘、移动硬盘）被挂载到系统中。
- 使用dd命令进行镜像导出：在宿主机（Linux PC）上通过读卡器读取SD卡，执行以下命令：
# 查看SD卡设备名（通常是 /dev/sdb 或 /dev/mmcblk0）
sudo fdisk -l
# 卸载所有分区
sudo umount /dev/sdb*
# 创建完整镜像（块大小为4MB，压缩存储）
sudo dd if=/dev/sdb of=jetson_image_$(date +%Y%m%d).img bs=4M status=progress
# 压缩镜像以节省存储空间
gzip -9 jetson_image_$(date +%Y%m%d).img在实际项目中，直接使用dd命令生成的镜像体积往往与SD卡容量相同（例如64GB的卡会生成64GB的镜像文件），即使实际数据只有10GB。为解决这个问题，推荐使用pishrink.sh脚本或gparted工具先缩小根文件系统分区，再进行镜像导出。经过缩容处理的镜像可以减小到实际数据量的1.2~1.5倍，极大方便了传输和存储。
balenaEtcher 或 Raspberry Pi Imager 进行镜像烧录。这些工具支持镜像校验（SHA256），能有效避免因烧录错误导致的设备启动失败。同时，烧录完成后务必进行“首次启动验证”，确认主机名、网络配置、序列号等已正确重置。
3.3 QSPI镜像与容器镜像：差异化制作要点
QSPI镜像的制作用于解决Jetson设备的底层引导问题。在Orin系列中，QSPI Flash存储了TegraBoot引导链、U-Boot、内核以及设备树。当SD卡损坏或需要更新Bootloader时，QSPI镜像成为恢复的关键。制作QSPI镜像通常使用NVIDIA SDK Manager的“Recovery Mode”功能，或通过命令行工具flash.sh生成：
# 在JetPack安装目录下执行（以Orin Nano为例）
cd ~/nvidia/nvidia_sdk/JetPack_5.1.2_Linux_JETSON_ORIN_NANO_TARGETS/Linux_for_Tegra
# 生成QSPI镜像（仅烧录引导部分）
sudo ./flash.sh -r -k APP -c bootloader/generic/cfg/flash_l4t_t234_qspi.xml jetson-orin-nano-devkitQSPI镜像的验证需要特别注意：烧录后必须检查串口日志，确认U-Boot能正确加载内核，且设备树与硬件匹配。如果QSPI镜像与SD卡镜像中的内核版本不一致，可能导致启动过程中断或外设初始化失败。
容器镜像的制作则更加灵活。在Jetson平台上，NVIDIA官方提供了基于L4T（Linux for Tegra）的基础容器镜像，用户可以在其上叠加自己的应用层。制作容器镜像的核心是编写高效的Dockerfile，并注意以下几点：
- 基础镜像选择：优先使用
nvcr.io/nvidia/l4t-base:r35.2.1等官方镜像，确保CUDA、cuDNN、TensorRT版本与宿主机内核驱动兼容。 - 层数优化：合并RUN命令，减少镜像层数，避免产生大量中间层导致镜像膨胀。
- 架构匹配：Jetson设备为ARM64架构，所有依赖包必须使用arm64版本，不能直接使用x86_64的预编译包。
- 运行时权限：容器需要访问GPU、摄像头等设备时，必须添加
--runtime=nvidia和--device参数。
# 示例Dockerfile（Jetson Orin平台）
FROM nvcr.io/nvidia/l4t-base:r35.2.1
# 安装Python和推理依赖
RUN apt-get update && apt-get install -y \
python3-pip \
libgomp1 \
&& pip3 install --no-cache-dir \
numpy==1.21.5 \
opencv-python==4.8.0.74
# 复制应用代码
COPY ./app /opt/app
WORKDIR /opt/app
# 设置容器入口
CMD ["python3", "inference_server.py"]3.4 制作镜像前的系统清理与优化
系统清理是镜像制作中最容易被忽视却至关重要的环节。一个未经清理的系统镜像可能包含大量无用数据：APT缓存、旧日志、用户历史记录、SSH主机密钥、临时文件等。这些冗余不仅增大镜像体积，更严重的是可能泄露敏感信息（如SSH密钥、历史命令中的密码）。
以下是经过验证的系统清理清单，建议在制作镜像前逐项执行：
| 清理类别 | 具体操作 | 命令/路径 | 预期效果 |
|---|---|---|---|
| APT缓存 | 清除下载的deb包 | sudo apt clean |
释放约500MB~1GB |
| 系统日志 | 清空journal日志 | sudo journalctl --vacuum-size=10M |
释放数百MB |
| 临时文件 | 删除/tmp和/var/tmp | sudo rm -rf /tmp/* /var/tmp/* |
释放少量空间 |
| 开发工具 | 移除编译工具链 | sudo apt remove build-essential cmake |
减小镜像体积 |
| SSH密钥 | 删除主机密钥 | sudo rm -f /etc/ssh/ssh_host_* |
防止密钥泄露 |
| 网络配置 | 重置DHCP租约 | sudo rm -f /var/lib/dhcp/* |
避免IP冲突 |
| 用户历史 | 清空bash历史 | history -c && rm -f ~/.bash_history |
保护隐私 |
| CUDA缓存 | 清除JIT缓存 | rm -rf ~/.nv/ComputeCache |
释放空间 |
除了清理，还需要进行系统优化以确保镜像的通用性和稳定性：
- 设置固定主机名：将主机名改为通用名称（如
jetson-device），避免镜像部署后出现主机名冲突。 - 禁用自动更新：关闭 unattended-upgrades 服务，防止设备在交付后自动更新导致系统不稳定。
- 重置用户密码：将默认用户的密码重置为出厂设置，或配置首次启动强制修改密码。
- 清理Docker残留：如果系统中使用过Docker，执行
docker system prune -a删除所有停止的容器和悬空镜像。 - 检查磁盘空间：使用
df -h确认根文件系统使用率低于70%，为首次启动预留足够空间。
du -sh /path 查看目录大小，确认是否为预期数据。特别是 /usr/local/cuda 下的文件，部分项目可能依赖特定版本的CUDA库，盲目清理会导致应用无法运行。建议在清理前创建系统快照（如使用 timeshift），以便出现问题时快速回滚。
3.5 实战案例：从开发环境到交付镜像的完整闭环
以下是一个真实的Jetson Orin NX项目交付案例，展示了镜像制作的全过程。
项目背景：某智慧零售方案商需要交付30台基于Jetson Orin NX的边缘计算设备，用于实时客流统计。每台设备需要预装Ubuntu 20.04、JetPack 5.1.2、TensorRT 8.5.3、自研的客流检测算法（Python + ONNX Runtime），以及远程管理代理（SSH + MQTT）。
初始状态与约束：开发环境在实验室中已完成算法验证，但系统中有大量开发残留：编译中间文件（约3.2GB）、PyTorch训练环境（约4.5GB）、多版本Python包冲突、SSH密钥已配置为开发者的个人密钥。交付时间紧迫，要求镜像制作在2天内完成，且镜像体积控制在16GB以内（便于使用32GB SD卡批量烧录）。
操作过程：
- 环境评估：使用
ncdu扫描磁盘，发现/home/user/.cache占用4.8GB（主要是pip缓存和HuggingFace模型缓存），/usr/local/cuda-11.4与/usr/local/cuda-12.0并存，占用额外3.1GB。 - 系统清理：卸载PyTorch及CUDA 11.4（保留CUDA 12.0），清除pip缓存，删除编译中间文件，清理journal日志至50MB。
- 应用优化：将ONNX模型转换为TensorRT引擎（FP16精度），推理速度提升40%，同时删除原始ONNX模型（减小镜像体积约200MB）。
- 网络配置重置：删除
/etc/NetworkManager/system-connections/下的所有连接配置，设置主机名为retail-edge-01。 - 安全加固：删除SSH主机密钥，禁用root远程登录，设置默认用户
jetson的密码为出厂密码。 - 镜像导出：使用
pishrink.sh将根文件系统从32GB缩小至11.8GB，然后使用dd命令生成镜像，最终压缩为9.6GB的.img.gz文件。 - 验证测试：在3台测试设备上烧录镜像，验证以下项目：首次启动时间（<90秒）、摄像头识别（CSI接口）、TensorRT推理延迟（<15ms）、MQTT连接稳定性（24小时不掉线）。
结果与复盘：最终交付的镜像在30台设备上全部一次通过验收。复盘发现，前期清理阶段花费了约4小时，但为后续批量烧录节省了大量时间（每台设备烧录时间从25分钟缩短至12分钟）。关键经验是：清理工作必须在应用优化之前完成，否则重新生成的TensorRT引擎文件会被误删。此外，建议在镜像制作完成后，使用 sha256sum 生成校验文件，并随镜像一同交付给客户。
3.6 常见误区与总结复盘
在镜像制作过程中，工程师常犯以下错误，需要特别注意规避：
- 误区一：忽略系统清理直接制作镜像。这会导致镜像体积膨胀30%~50%，且可能包含开发者的SSH私钥、数据库密码等敏感信息。正确做法是建立标准化的清理脚本，每次制作镜像前自动执行。
- 误区二：镜像制作后不进行完整验证。仅验证系统能启动是不够的，必须验证所有外设（摄像头、GPIO、CAN总线）、网络服务、AI推理性能是否达到交付标准。建议制作一份《镜像验收清单》，逐项打勾确认。
- 误区三：混淆QSPI镜像与SD卡镜像的更新机制。部分工程师试图通过更新SD卡镜像来修复Bootloader问题，这是无效的。Bootloader必须通过QSPI烧录或恢复模式更新。
- 误区四：容器镜像与宿主机环境强耦合。在Dockerfile中直接使用宿主机路径或依赖宿主机安装的库，会导致容器在其他设备上无法运行。应确保容器自包含所有依赖。
- 误区五：忽略镜像版本管理。没有为镜像文件命名包含版本号、日期、硬件型号等信息，导致后期追溯困难。建议采用
jetson-orin-nx_retail_v1.2.0_20250615.img.gz的命名格式。