最近帮朋友收拾一块吃灰的 Jetson Nano 开发板准备拿来做边缘端的模型推理。习惯性打开 GitHub 搜系统镜像翻到一个专门给 Jetson Nano 做 Ubuntu 系统的项目README 写得挺全连烧录命令都给你配好了。正准备照着下载镜像开干突然瞥见仓库顶部挂着一条 banner已停止维护。怎么说呢这事在嵌入式圈子里太常见了但很多刚接触的朋友看到这几个字就慌了不知道这个项目到底还能不能用装出来的系统还靠不靠谱。先泼一盆冷水Jetson Nano 虽然长得像树莓派但它真不是树莓派。它用的是 NVIDIA Tegra X1 这颗 ARM 处理器引导流程、内核、驱动全都走 NVIDIA 自己的 L4TLinux 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核心组件是 L4TLinux 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.9R32.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 ifubuntu-jetson-nano.img of/dev/sdX bs4M statusprogress convfsync写入完成后不要急着拔卡执行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-smiNVIDIA 官方提供的监控工具是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社区镜像更合适。下表是我个人总结的对比可以直接参考对比项官方 JetPack / L4T社区 Ubuntu 镜像预装 CUDA/TensorRT完整预装基本不预装镜像体积大通常 8GB 以上相对较小启动速度慢一些较快适合场景AI 推理、视觉开发轻量 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 是基于 arm64aarch64的安装任何软件前先执行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 上跑起来之后日常使用中还有一些频率很高的问题。我整理成一张速查表方便真正遇到问题时按图索骥现象可能原因解决思路上电后黑屏指示灯闪一下就没电源功率不足、SD 卡烧录损坏换 5V/4A 电源重新校验并烧录一直卡在 NVIDIA 或 U-Boot 阶段镜像不匹配硬件版本、跳线帽未设置核对镜像支持的 Jetson 型号检查跳线帽开机风扇狂转速度一直下不来温度策略未适配、桌面合成器占用高用 tegrastats 看温度检查 CPU 占用配置风扇脚本WiFi 找不到Bluetooth 打不开缺少固件或者内核模块未加载安装对应 linux-firmware检查 dmesg 里的固件加载日志无线有线都连不上NetworkManager 被禁用或网卡配置异常先查systemctl status NetworkManager再用nmcli查看连接状态apt update出现 404镜像源已失效版本已 EOL改用 old-releases 源或国内镜像源对应版本目录SSD 空间不足SD 卡容量太小换更大的 SD 卡或者迁移数据到外置硬盘容器里跑 AI 模型特别慢没有挂载 GPU 资源或者缺少驱动检查/dev/nvhost-*设备确认容器内能否访问 GPU这些问题的排查路径并没有想象中那么神秘。大部分时候你只要看一个东西启动日志和系统日志。如果开机启动阶段就有问题看串口日志和 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 ofjetson-nano-backup.img bs4M statusprogress # 压缩备份减少占用 xz -T0 jetson-nano-backup.img这样做的好处是显而易见的以后无论系统被折腾成什么样哪怕内核崩了、文件系统损坏只要把这卡重新写回就能回到备份时间点的状态。这个操作的成本很低却能在关键时刻救你一次。Windows 上其实也可以用 balenaEtcher 的“保存镜像”功能把 SD 卡整体克隆为一个 img 文件操作逻辑是一样的。我自己每次给 Jetson 板卡调完环境都会把最终状态备份一份放到电脑里。一个月后想换一个玩法随时可以无缝回滚。这套思路放到任何开发板上都适用。结尾玩这种嵌入式板子我最大的体会是绝大多数所谓的刷机失败最后追根溯源都不是设备本身的问题而是跳过了验证、忽略了前提。镜像项目停止维护并不可怕可怕的是不去看它到底依赖哪个 L4T 版本不核对 SD 卡烧录的校验值上山直接插电。先花十分钟确认链路上的每一个前提再动手效果比火急火燎地换镜像强得多。最后再分享一个小习惯我把所有在 Jetson 上验证过的镜像整理成了一个清单备注好 Jetson 是 A02 还是 B01、对应的 L4T 版本、内核版本、电源配置和已知的坑。每次拿到新板子先对着清单选镜像五分钟就能完成第一个系统。等你手里的板子越来越多会回头感谢这个清单的。
Jetson Nano 刷 Ubuntu 镜像：停止维护的项目还能放心用吗？
最近帮朋友收拾一块吃灰的 Jetson Nano 开发板准备拿来做边缘端的模型推理。习惯性打开 GitHub 搜系统镜像翻到一个专门给 Jetson Nano 做 Ubuntu 系统的项目README 写得挺全连烧录命令都给你配好了。正准备照着下载镜像开干突然瞥见仓库顶部挂着一条 banner已停止维护。怎么说呢这事在嵌入式圈子里太常见了但很多刚接触的朋友看到这几个字就慌了不知道这个项目到底还能不能用装出来的系统还靠不靠谱。先泼一盆冷水Jetson Nano 虽然长得像树莓派但它真不是树莓派。它用的是 NVIDIA Tegra X1 这颗 ARM 处理器引导流程、内核、驱动全都走 NVIDIA 自己的 L4TLinux 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核心组件是 L4TLinux 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.9R32.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 ifubuntu-jetson-nano.img of/dev/sdX bs4M statusprogress convfsync写入完成后不要急着拔卡执行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-smiNVIDIA 官方提供的监控工具是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社区镜像更合适。下表是我个人总结的对比可以直接参考对比项官方 JetPack / L4T社区 Ubuntu 镜像预装 CUDA/TensorRT完整预装基本不预装镜像体积大通常 8GB 以上相对较小启动速度慢一些较快适合场景AI 推理、视觉开发轻量 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 是基于 arm64aarch64的安装任何软件前先执行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 上跑起来之后日常使用中还有一些频率很高的问题。我整理成一张速查表方便真正遇到问题时按图索骥现象可能原因解决思路上电后黑屏指示灯闪一下就没电源功率不足、SD 卡烧录损坏换 5V/4A 电源重新校验并烧录一直卡在 NVIDIA 或 U-Boot 阶段镜像不匹配硬件版本、跳线帽未设置核对镜像支持的 Jetson 型号检查跳线帽开机风扇狂转速度一直下不来温度策略未适配、桌面合成器占用高用 tegrastats 看温度检查 CPU 占用配置风扇脚本WiFi 找不到Bluetooth 打不开缺少固件或者内核模块未加载安装对应 linux-firmware检查 dmesg 里的固件加载日志无线有线都连不上NetworkManager 被禁用或网卡配置异常先查systemctl status NetworkManager再用nmcli查看连接状态apt update出现 404镜像源已失效版本已 EOL改用 old-releases 源或国内镜像源对应版本目录SSD 空间不足SD 卡容量太小换更大的 SD 卡或者迁移数据到外置硬盘容器里跑 AI 模型特别慢没有挂载 GPU 资源或者缺少驱动检查/dev/nvhost-*设备确认容器内能否访问 GPU这些问题的排查路径并没有想象中那么神秘。大部分时候你只要看一个东西启动日志和系统日志。如果开机启动阶段就有问题看串口日志和 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 ofjetson-nano-backup.img bs4M statusprogress # 压缩备份减少占用 xz -T0 jetson-nano-backup.img这样做的好处是显而易见的以后无论系统被折腾成什么样哪怕内核崩了、文件系统损坏只要把这卡重新写回就能回到备份时间点的状态。这个操作的成本很低却能在关键时刻救你一次。Windows 上其实也可以用 balenaEtcher 的“保存镜像”功能把 SD 卡整体克隆为一个 img 文件操作逻辑是一样的。我自己每次给 Jetson 板卡调完环境都会把最终状态备份一份放到电脑里。一个月后想换一个玩法随时可以无缝回滚。这套思路放到任何开发板上都适用。结尾玩这种嵌入式板子我最大的体会是绝大多数所谓的刷机失败最后追根溯源都不是设备本身的问题而是跳过了验证、忽略了前提。镜像项目停止维护并不可怕可怕的是不去看它到底依赖哪个 L4T 版本不核对 SD 卡烧录的校验值上山直接插电。先花十分钟确认链路上的每一个前提再动手效果比火急火燎地换镜像强得多。最后再分享一个小习惯我把所有在 Jetson 上验证过的镜像整理成了一个清单备注好 Jetson 是 A02 还是 B01、对应的 L4T 版本、内核版本、电源配置和已知的坑。每次拿到新板子先对着清单选镜像五分钟就能完成第一个系统。等你手里的板子越来越多会回头感谢这个清单的。