Jetson Nano 刷 Ubuntu 镜像：停止维护的项目还能放心用吗？

最近帮朋友收拾一块吃灰的 Jetson Nano 开发板，准备拿来做边缘端的模型推理。习惯性打开 GitHub 搜系统镜像，翻到一个专门给 Jetson Nano 做 Ubuntu 系统的项目，README 写得挺全，连烧录命令都给你配好了。正准备照着下载镜像开干，突然瞥见仓库顶部挂着一条 banner：已停止维护。怎么说呢，这事在嵌入式圈子里太常见了，但很多刚接触的朋友看到这几个字就慌了，不知道这个项目到底还能不能用，装出来的系统还靠不靠谱。

先泼一盆冷水：Jetson Nano 虽然长得像树莓派，但它真不是树莓派。它用的是 NVIDIA Tegra X1 这颗 ARM 处理器，引导流程、内核、驱动全都走 NVIDIA 自己的 L4T（Linux for Tegra）体系。你拿普通桌面版 Ubuntu 的 ISO 往 SD 卡里一写，上电后大概率卡死在启动阶段，根本进不去系统。所以“给 Jetson Nano 装 Ubuntu”这件事，本身就有门槛，不能套用 PC 上装系统的思维。

这篇文章就从一个停止维护的 GitHub 项目说起，把 Jetson Nano 装 Ubuntu 镜像这件事拆开讲透：怎么看懂一个项目到底能不能用、下载镜像时要注意什么、SD 卡烧录和首次开机的完整流程、项目停更后的替代方案，以及我实际操作中踩过的那些坑。无论你是手上已经有板子、准备刷系统的新手，还是想把手头旧板子翻新继续用的老玩家，这篇文章应该都能给你一点参考。

1. 先说清楚：Jetson Nano 的系统安装为什么这么折腾

1.1 它不是普通电脑，刷机逻辑完全不同

很多人第一次拿到 Jetson Nano，第一反应就是去 Ubuntu 官网下载一个桌面版镜像，用 Rufus 或者 balenaEtcher 写到 SD 卡里。这个思路放到 x86 PC 上是完全正确的，但放到 Jetson Nano 上就行不通。

原因在于 Jetson Nano 是一颗基于 ARMv8 架构（aarch64）的 SoC 芯片，它的启动链路不是传统的 BIOS/UEFI + 分区引导，而是 NVIDIA 的 TegraBoot 引导程序配合 U-Boot 二次引导。内核要有针对 Tegra X1 的板级补丁，设备树（DTC）要能正确识别板载的外设，根文件系统里的用户态工具也要适配 L4T 的体系。官方提供的系统叫 JetPack，核心组件是 L4T（Linux for Tegra），这是一个把定制内核、Bootloader、NVIDIA 驱动、CUDA 等 SDK 打包在一起的整体镜像。

所以社区里出现的“Jetson Nano Ubuntu image”项目，本质上做的事情是：把 L4T 的内核和驱动保留下来，但把根文件系统换成更接近原生 Ubuntu 的用户态环境，再做一些裁剪和预配置，最终打成一个可以直接写到 SD 卡里的 img 镜像文件。这比官方镜像轻量得多，不预装 CUDA、cuDNN 那堆东西，启动更快、占用更低，适合拿来跑普通 Linux 服务、轻量容器，甚至只是当一台迷你服务器用。

但问题也出在这里：这种镜像一旦停止维护，就意味着它不再跟随 Ubuntu 上游更新，不再适配新版本的 L4T 内核，也不保证能在后来新批次的硬件上正常启动。你需要自己做技术判断，而不是看到“停止维护”就直接放弃。

1.2 一个项目贴上"已停止维护"，还能不能用

GitHub 上的项目状态，其实没有一个官方的“停止维护”按钮，它通常体现在几个信号上：最近一次提交时间停留在一年甚至更早、Issue 区长期无人回复、README 顶部明确写了 “No longer maintained” 或者 “Archived”，以及 Release 区不再有新版本发布。

看到这些信号，我的判断思路是这样的：先看项目针对的是哪个硬件版本。Jetson Nano 有 A02 和 B01 两个常见硬件版本，B01 是后来量产的版本，两者的供电接口和部分启动配置有区别。如果项目明确写了支持 B01，那对绝大多数人来说就是可用的。再看它基于哪个版本的 L4T。L4T 版本和内核版本是绑定的，比如 R32.4.2 对应内核 4.9，R32.7.1 对应内核 4.9 的某个小版本，如果你只是跑普通 Linux 服务和容器，里面涉及的很多稳定性问题都已经在旧版本里被修过了，问题不大。但如果你想用新特性的内核，或者装新版的 CUDA、TensorRT，那抱歉，这个老镜像做不到。

举一个很实际的判断标准：Check 项目 README 里是否明确列出了“支持的板卡型号”和“已测试的 JetPack/L4T 版本”。如果列出了，说明作者至少在不同板子上实际跑过；如果只有一句含糊的“适用于 Jetson Nano”，那就得小心。没有明确的版本信息，烧录后能不能启动，全看运气。

另外一个值得注意的点是：停止维护不等于“里面的经验失效”。这类项目的 README 和 Issue 区往往积累了大量的排障讨论，比如“装完后无线网卡无法识别”“风扇转得飞起”“apt 源失效”等等。这些内容本身就是宝藏，后面排查问题时非常有帮助。所以我建议不要因为停止维护就绕着走，把它当作一个参考文档来读，也是值回票价的。

2. GitHub 上筛选 Ubuntu 镜像项目的实操干货

2.1 搜索关键词与项目筛选技巧

很多人直接搜 “Jetson Ubuntu”，然后盯着 star 数最高的项目点进去，发现要么是官方仓库、要么是已经停止维护的遗留项目。这里我把自己的搜索习惯分享一下。

我常用的搜索组合是：jetson nano ubuntu image、jetson nano sd card image、jetson nano l4t rootfs，在 GitHub 搜索结果里再配合语言过滤和发布时间过滤。比如限定仓库更新时间在近一年内，或者限定 Release 区里有实际镜像文件。

这里要泼一盆冷水：star 数高不代表镜像一定能用。很多高 star 项目只是被收藏的人多，真正跑通的可能就作者本人。我更看重的是 Release 区有没有成型的镜像文件。一个镜像项目如果没有 Release，只让你通过网盘链接下载，那项目的工程化程度就很存疑。反过来，如果项目在 Release 里放了多个镜像、附带了 sha256 校验文件，甚至清楚地写了“适用于 B01 开发板，请使用 R32.7.1 的 L4T 工具链”，这个项目大概率是认真做过的。

GitHub 搜索时还可以用一些内置过滤器，比如在搜索框里追加stars:>100或者pushed:>2024-01-01。前者是看项目经过了多少人认可，后者是排除掉已经很久没有活跃维护的仓库。但记住，这只是辅助判断，最终合不合格，要到 README 和 Release 里看细节。

2.2 用 Release 和校验值判断项目可靠程度

我判断一个镜像项目靠不靠谱，有一套固定的动作：打开 Release 页面，看三样东西——文件名、文件大小、校验值。

正常的 Jetosn Nano Ubuntu 镜像一般会压缩成.img.xz或者.zip格式，体积在 3GB 到 8GB 之间。解压后的.img文件则在 16GB 左右甚至更大，取决于根文件系统的预装内容。如果 Release 里只放了一个 500MB 的小文件，那个大概率不是完整系统，而是一个精简的 rootfs 包，还需要你自己手工部署，不适合没有经验的朋友。

校验值（SHA256/MD5）是必须关注的东西。一个严肃的镜像项目会在 Release 区附上.sha256文件，或者在 README 里写明最终镜像的哈希值。我下载后会用它来验证文件在传输过程中有没有损坏。很多莫名其妙的“上电后黑屏”“卡在 NVIDIA logo 不动”，最后追查到根上就是下载的文件缺了字节。GitHub Release 下载大文件偶尔会断流、超时，如果你没有做校验，根本发现不了文件已经是不完整的。

做一些必要的校验流程非常值得，具体命令后面在烧录环节我再展开。这里先记住一个结论：如果一个项目连校验值都不给，还让你从网盘拉文件，就别指望它的镜像能稳定启动。能用是惊喜，不能用才是常态。

2.3 下载阶段容易踩的网络与工具问题

国内访问 GitHub 有时不稳定，特别是下载 Release 里的大文件，速度会让人抓狂。我经常看到有人卡在“浏览器下载到一半就断”，然后反复重试，浪费时间。

针对这种情况，我一般先用命令行下载工具来处理。比如用wget -c支持断点续传，或者用aria2c -x 8 -s 8做多线程拉取，速度通常比浏览器稳很多。如果网络确实困难，也可以借助 GitHub 的镜像加速站点来中转公开的 Release 文件，比如常见的ghproxy这类前缀代理服务。这里我想强调一个安全习惯：使用代理镜像时，依然要对下载结果做 sha256 校验，因为你无法保证代理服务器没有动过文件。校验通过，这个文件才能进入烧录环节。

大文件下载完成后，别急着解压和写入。先把压缩包和官方提供的 sha256 值放在同一目录下，执行一次校验命令，通过了再继续下一步。这个习惯养成了，能帮你省下大量反复烧录排障的时间。因为烧录阶段出了问题，你往往会在硬件、电源、跳线帽这些地方来回折腾，最后才发现是镜像本身有问题，那真的是最冤枉的排查路线。

3. 实操过程与核心环节实现

3.1 准备阶段：硬件、连接线与工具清单先行确认

正式开始之前，先把清单核对一遍。Jetson Nano 的系统安装，最怕的就是“所有条件都以为没问题，结果有一个细节不满足”，烧录完上电才发现，来回折腾两小时。

硬件方面，你需要确认手头板子的版本。Jetson Nano 有两种型号，A02 是早期开发套件，B01 是后期量产板。两者在供电方式上不一样：A02 是 micro USB 供电，B01 既有 micro USB 口，也有 DC barrel 接口，分别对应不同电流档位。官方的要求是使用 5V/4A 电源，DC 输入比 micro USB 更稳，强烈建议有条件就直接上 DC 电源。

SD 卡是另一个关键点。不要用小于 16GB 的卡，不然系统装完就满了；速度上建议 UHS-I A1/A2 规格，Class 10 以上。劣质 SD 卡会导致读写慢得离谱，还会在系统负载高时出现 IO timeout，表现为随机卡死、启动失败。我在项目里经常看到有人报“系统跑一会儿就死机”，最后换一张正经卡就好了。

其他配件：读卡器是必须的，最好支持 UHS-I；显示器和 HDMI 线可以让你首次调试时直接看到桌面；键鼠一套；网线一根，或者通过串口线连接调试。如果你打算无头使用（Headless），网线和 SSH 就够了，但首次开机阶段我还是建议先接显示器，因为很多异常在屏幕上能直接看到。

对了，跳线帽也得提前准备好。B01 板卡上有一个J48两个引脚的排针，把它用跳线帽短接，才能强制让板子从 SD 卡启动，而不是 eMMC。A02 板上也有一个类似的跳线。这个细节在官方文档里有，但很多人第一次玩会忽略，导致怎么刷都从自带系统启动。

3.2 烧录 SD 卡并验证镜像完整性

镜像下载并校验通过之后，下一步就是把系统写进 SD 卡。Windows 上我推荐直接用 balenaEtcher，它在烧录完成后会自动做一次卸载，对新手最友好。Linux 下我更习惯直接用dd命令，可控性更高。

先从校验开始。如果镜像文件是.img.xz压缩包，先解压再写入，也可以直接喂给支持解压的工具，但为了清晰起见，我习惯先解压。

# 进入镜像所在目录，运行 sha256 校验 sha256sum ubuntu-jetson-nano.img.xz # 与项目提供的 sha256 值比对，一致则继续 # 解压得到 img 文件 unxz ubuntu-jetson-nano.img.xz

写入前务必要确认 SD 卡的设备路径。Linux 下插入读卡器后，先用lsblk查看，确认是/dev/sdb还是/dev/sdc，别写错了盘。这是一个老生长谈但仍然不断有人翻车的环节，写错盘能把一块好硬盘变成一块废盘。

# 把镜像写入 SD 卡，bs 设置块大小，status 显示进度 sudo dd if=ubuntu-jetson-nano.img of=/dev/sdX bs=4M status=progress conv=fsync

写入完成后不要急着拔卡，执行sync并安全弹出设备。闪烁的写入指示灯停了，再拔出，插入到 Jetson Nano 上电。macOS 环境下流程类似，只是设备路径变成了/dev/diskX，写入前用diskutil list找到对应磁盘，最好先卸载它的分区挂载点再执行dd。

整个烧录过程，我建议全程盯着 log 结尾的进度百分数和字节数，确保和镜像大小一致。如果你发现写入中途报错，很大概率是 SD 卡质量有问题或者读卡器供电不足，换一个读卡器和卡再试，不要硬撑。

3.3 首次开机：从 SD 卡启动到进入桌面/SSH

烧录完成，进入最激动也最容易翻车的首次开机环节。先把跳线帽按板卡说明书短接好，插入 SD 卡，接上 HDMI、键鼠和电源线。插电之前，最后一次确认电源适配器输出是 5V/4A，电源功率不够会在高负载时电压跌落，表现就是刚开机的几秒内反复重启。

插电后，指示灯亮起，屏幕通常会在一分钟左右出现 NVIDIA 的 Logo，然后是内核日志滚动，最终进入桌面或者登录终端。如果等了超过五分钟屏幕还是黑的，多半是 SD 卡没被正确识别，或者镜像与板卡版本不匹配。这时候先别怀疑硬件坏了，重新检查供电、跳线帽和 SD 卡接触。

第一次正常进入系统后，先不要急着去折腾桌面美化。我建议先跑一遍基础验证：确认网络连接、SSH 能用、磁盘空间充足、系统时间正确。有很多 B01 板卡的镜像默认没有装 openssh-server，需要在系统设置里手动开启。如果你是无头使用，在终端执行:

# 启动并设置 SSH 服务开机自启 sudo systemctl enable --now ssh

然后安装必要的工具，比如htop、vim、git，以及用于查看 GPU 和温度状态的tegrastats。Jetson 平台上没有nvidia-smi，NVIDIA 官方提供的监控工具是tegrastats，在 L4T 里默认自带，直接在终端运行即可看到 CPU/GPU 频率、温度、内存占用等信息。

这里特别提醒一个大坑：进入系统后，不要手欠直接跑sudo apt upgrade。社区镜像的内核和驱动往往打包自特定版本的 L4T，如果你贸然把用户态和内核头文件一起升级，有可能把内核、驱动和启动组件搞得不兼容，运气差一点，下次重启就进不了系统了。我的习惯是先做sudo apt update，升级软件源列表，然后只升级应用层面的包，内核相关的包严格保持不动。后面我会专门展开讲这个问题。

4. 项目停止维护后的替代方案与自救办法

4.1 官方 JetPack 与社区镜像怎么选

如果你的最终目标是要跑 CUDA、TensorRT 或者 PyTorch 这类 GPU 加速推理任务，那么社区的精简 Ubuntu 镜像基本帮不上忙。因为它没有预装 NVIDIA 的 CUDA 运行时和 cuDNN 库，你后续要手动装一大堆东西，而且老内核版本对新的 CUDA 版本兼容性很差，很容易掉进依赖地狱。这种场景下，老老实实回到官方 JetPack 才是最省心的路。

JetPack 是 NVIDIA 提供的一整套刷写工具和 SDK 集合，通过官方sdkm工具或者balenaEtcher写入官方的 L4T 系统镜像。它的优点是所有驱动、CUDA、cuDNN、TensorRT 都是官方验证过的，你拿到手就能进入 AI 开发；缺点是镜像是完整 SDK，体积大、启动后预装的软件多，如果你想把它当成一台干净的小服务器用，还需要自己去裁剪。

社区镜像的值，恰恰在于它只保留一个干净的 Ubuntu 根文件系统，外加最基本的 L4T 内核和驱动。你可以自由安装自己的运行环境，不被 NVIDIA 那套预设绑架。所以选型的核心判断点是：你在这块板子上最终要干什么？如果是做深度学习推理，选官方 JetPack；如果是跑 Docker 服务、文件同步、局域网服务器，甚至只是玩玩 Linux，社区镜像更合适。

下表是我个人总结的对比，可以直接参考：

4.2 装好系统后最常见的三类报错与排查

社区镜像装完后，最容易遇到三类问题，我按出现频率说一下排查思路。

第一类是 apt 源失效。旧镜像默认的软件源地址往往是 Ubuntu 旧版本的 archive 或 ports 地址，对于 EOL（生命周期结束）的版本，官方源会被移走，导致apt update返回 404。解决办法是把/etc/apt/sources.list和/etc/apt/sources.list.d/下的地址改成官方的 old-releases 源，或者换成国内 Ubuntu 镜像源中对应的版本目录。改完执行sudo apt update验证再继续安装软件。

第二类是内核模块缺失或驱动不一致。这类问题的典型现象是：WiFi 找不到、蓝牙无法启用、GPIO 对应的设备节点不存在。排查路径是先确认当前内核版本和 L4T 版本是否匹配，执行uname -r以及查看/etc/nv_tegra_release文件，再去对照镜像项目 README 里声明的支持版本。常见解决思路是安装对应的 linux-headers 包，并把外设固件文件放到/lib/firmware下。

第三类是软件包架构不匹配。如果你在 aarch64 系统上尝试安装某个只提供 x86_64 版本的 deb 包，或者从 x86 的 PP Alinux 源里拉包，会直接报架构错误。Jetson Nano 上的 Ubuntu 是基于 arm64（aarch64）的，安装任何软件前，先执行dpkg --print-architecture确认，安装包也只能选 arm64 架构的版本。这个问题对于初接触 ARM 开发板的朋友很典型。

这几类报错的共性是：先确认“系统的根基是否匹配”，再看软件层。如果你一开始就把锅甩给“镜像不好用”，很容易白白浪费时间重刷系统。很多问题重刷也解决不了，因为你没抓到真正的矛盾点。

4.3 如果镜像项目真的用不了，我的后备方案

如果手头的镜像项目已经完全无法在新板子上启动，或者文件下载不下来，我的建议是分三条路走。

第一条路，找活跃维护的 fork。GitHub 上很多停止维护的项目会有其他人 fork 过去继续修 bug、补驱动、更新到新的 Ubuntu 版本。我在 Release 区或者网络搜索结果里找 fork 时，会重点看 fork 仓库最近有没有新的提交，以及它们的 README 是否标注了“基于原项目修复了 XXX”。这种方式的好处是，继承原项目的文档和经验，新作者往往只针对有限的几个点做修补，风险相对可控。

第二条路，退回官方 Jetson 的刷写流程。用sdkm工具按官方流程安装对应版本的 JetPack，然后在系统里去预装组件。虽然体积大一点，但胜在可靠。如果你的核心诉求是“系统稳稳运行”，这个方案最稳妥。

第三条路，是自己从 Ubuntu Core 或 Debian arm64 官方镜像构建系统，再手动适配 L4T 内核和驱动。这条路技术要求非常高，需要手动调整根文件系统、内核模块、Bootloader，一般不建议新手尝试。我见过老玩家用 chroot 手工组合 rootfs，效果挺好，但中间任何一步出错都很难排查，没有足够经验就先别碰。我自己只在极个别板卡上这么玩过，最近的经验就是：能走现成镜像，绝不自己硬造。

5. 常见问题与排查技巧实录

5.1 常见问题速查表

社区镜像在 Jetson Nano 上跑起来之后，日常使用中还有一些频率很高的问题。我整理成一张速查表，方便真正遇到问题时按图索骥：

这些问题的排查路径，并没有想象中那么神秘。大部分时候你只要看一个东西：启动日志和系统日志。如果开机启动阶段就有问题，看串口日志和 U-Boot 输出；如果是进系统后的问题，看dmesg和journalctl -b的输出，绝大多数线索都藏在里面。

5.2 排查思路：一步步定位问题在哪一层

我遇到疑似系统问题时，从来不会上来就重刷。先按照“硬件层 → Bootloader 层 → 内核层 → 用户态”这个顺序去定位。

硬件层是最容易被忽略的。电源有没有供上、SD 卡是不是好的、跳线帽有没有接，这几点就差不到哪去。如果你手边有万用表，量一下供电电压是否稳定，很多“抽风”问题其实都是电压不稳造成的。没有万用表也没关系，换一个高质量的电源试试，是最快的排除法。

然后是 Bootloader 层。把串口线接好，打开终端看日志，如果串口有输出、但卡在某个 U-Boot 命令，那通常是镜像的启动配置不匹配你的板卡。这种问题靠换镜像解决最直接。如果串口完全没有输出，主板可能压根没供电，或者 SD 卡没被引导。

进入内核层后，看内核版本和设备树。很多镜像项目在 README 里会写“适用于 L4T R32.7.1”，如果你强行把它刷到别的 L4T 版本，内核可能不识别板载外设。这时dmesg | grep error通常会给出线索。

到了用户态，问题范围就广了。SSH 起不来、桌面黑屏、依赖缺失、软件源失效，都用服务状态和日志去查。记住一个原则：定位到具体日志再动手，不要凭感觉乱敲命令。很多朋友一急就apt upgrade、重启、重刷，最后把原本能修的问题搞成常态。

5.3 一个非常实用的预防性操作：整卡备份

等到系统终于配好、各种依赖装完、SSH 也能连上了，千万别觉得这就完了。我在玩 Jetson 系列板子时，最想推荐给大家的一个习惯是：给“调好的系统”做一次性备份，然后把备份镜像压缩存档。

这个操作在 Linux 下其实就是一条dd命令加一步压缩，我再配合xz把镜像压起来，能省很多存储空间。

# 先卸载 SD 卡对应的分区，再整卡读出来 # 假设 SD 卡是 /dev/sdb，注意目标文件路径要预留足够空间 sudo dd if=/dev/sdb of=jetson-nano-backup.img bs=4M status=progress # 压缩备份，减少占用 xz -T0 jetson-nano-backup.img

这样做的好处是显而易见的：以后无论系统被折腾成什么样，哪怕内核崩了、文件系统损坏，只要把这卡重新写回，就能回到备份时间点的状态。这个操作的成本很低，却能在关键时刻救你一次。Windows 上其实也可以用 balenaEtcher 的“保存镜像”功能，把 SD 卡整体克隆为一个 img 文件，操作逻辑是一样的。

我自己每次给 Jetson 板卡调完环境，都会把最终状态备份一份放到电脑里。一个月后想换一个玩法，随时可以无缝回滚。这套思路放到任何开发板上都适用。

结尾

玩这种嵌入式板子，我最大的体会是：绝大多数所谓的刷机失败，最后追根溯源都不是设备本身的问题，而是跳过了验证、忽略了前提。镜像项目停止维护并不可怕，可怕的是不去看它到底依赖哪个 L4T 版本，不核对 SD 卡烧录的校验值，上山直接插电。先花十分钟确认链路上的每一个前提，再动手，效果比火急火燎地换镜像强得多。

最后再分享一个小习惯：我把所有在 Jetson 上验证过的镜像整理成了一个清单，备注好 Jetson 是 A02 还是 B01、对应的 L4T 版本、内核版本、电源配置和已知的坑。每次拿到新板子，先对着清单选镜像，五分钟就能完成第一个系统。等你手里的板子越来越多，会回头感谢这个清单的。