1. 报错现场这条“does not have a Release file”信息是怎么出现的如果你最近在 Ubuntu 22.04 上照着老教程安装 ROS大概率会在sudo apt update这一步撞上下面这行提示E: The repository http://mirrors.ustc.edu.cn/ros/ubuntu jammy Release does not have a Release file. N: Updating from such a repository cant be done securely, and is therefore disabled by default. N: See apt-secure(8) manpage for repository creation and user configuration details.先说结论这不是网络断了不是 USTC 镜像挂了也不是你运气差。而是你让 apt 去一个根本不包含jammy发行版的仓库里找Release文件apt 老老实实告诉你这个仓库没有对应的发布信息我不能更新。只要稍微玩过一点 Linux 软件源就会知道 apt 的仓库并不是一个单纯的下载目录。它的目录结构固定是dists/发行版代号/ReleaseRelease文件里记录了这套仓库支持哪些组件、哪些架构、哪些文件的哈希值。apt 更新索引前会先请求这个Release文件用 GPG 签名确认仓库可信再根据文件里写的Packages路径去拉软件列表。如果这个文件不存在apt 宁可报错也不去更新这是安全机制不是 bug。拿货仓来打比方就是你拿着“jammy 区”的提货单跑到 USTC 的 ROS 仓库里找货架但仓库管理员压根没有建过叫jammy的货架他只能告诉你“查无此区”。更麻烦的是很多人这时候会反复试apt update、清理缓存、换镜像源最后甚至重装系统依然解决不了——因为问题从一开始就出在“版本匹配”上。2. 根因USTC 镜像里的 ROS 仓库为什么没有 jammy这个报错的直接原因一句话就能说清楚你加的仓库地址和你要装的系统版本对不上。但“对不上”背后有好几个层次我拆开讲。2.1 ROS 1 和 ROS 2 的仓库是分开的很多人不知道http://mirrors.ustc.edu.cn/ros/ubuntu这个路径主要是给ROS 1用的。ROS 2 的仓库在 USTC 镜像上有独立的路径一般写作http://mirrors.ustc.edu.cn/ros2/ubuntu二者不能混用。你如果照着 2020 年左右的 ROS 1 Noetic 教程走它大概率会让你添加ros/ubuntu这个源。那时候 Ubuntu 20.04 是主流ROS 1 Noetic 正好支持 focal源里写的也是focal一切正常。但如果你现在用的是 Ubuntu 22.04系统代号是jammy再把ros/ubuntu后面的套件名改成jammy问题就来了ROS 1 官方仓库里根本没有为 jammy 构建过软件包镜像自然也就不会有dists/jammy/Release这个文件。2.2 版本匹配表别再闭眼选 jammy我在折腾机器人环境时最常遇到的情况就是“看教程里写什么就抄什么”完全不看自己的 Ubuntu 版本。这里建议先对照一下官方支持的版本组合ROS 发行版支持 Ubuntu 版本对应仓库路径以 USTC 为例ROS 1 Noetic20.04focalhttp://mirrors.ustc.edu.cn/ros/ubuntuROS 1 Melodic18.04bionichttp://mirrors.ustc.edu.cn/ros/ubuntuROS 2 Foxy20.04focalhttp://mirrors.ustc.edu.cn/ros2/ubuntuROS 2 Humble22.04jammyhttp://mirrors.ustc.edu.cn/ros2/ubuntuROS 2 Jazzy24.04noblehttp://mirrors.ustc.edu.cn/ros2/ubuntu注意看最后一列你要在 22.04 上装 ROS 2 Humble仓库地址应该用ros2/ubuntu而不是ros/ubuntu。如果教程里加的是ros/ubuntu套件名写的却是jammyapt 自然只能拿回一个 404最终反馈成“does not have a Release file”。2.3 镜像同步策略也会造成“目录存在但 Release 缺失”还有一类情况是仓库目录里不是完全没有相关文件而是你想访问的那个套件在同步时被过滤掉了。一些镜像为了节省磁盘只同步稳定的发行版或者不同步旧版本的Release.gpg。不过 USTC 这边更常见的是路径本身的问题。你可以尝试直接访问这个地址http://mirrors.ustc.edu.cn/ros/ubuntu/dists/你会发现里面大部分是bionic、focal这类 ROS 1 支持的发行版目录就是没有jammy。反过来如果你去看ros2/ubuntu/dists/就能看到focal、jammy、noble这些 ROS 2 使用的目录。所以下次再看到这个报错先别怀疑镜像坏了先怀疑自己“进错了楼”。3. 排查链路从系统版本到仓库地址逐层验证碰到这类报错我强烈建议不要直接去改源先把现场的真相搞清楚。排查链路其实就三步。3.1 第一步确认自己的 Ubuntu 版本代号打开终端先跑两条命令lsb_release -sc cat /etc/os-release如果输出里有jammy说明你确实是 Ubuntu 22.04。这一步是后面所有判断的地基。很多教程会默认你用的是 20.04双方沟通的第一个错位就在这里。3.2 第二步查看当前源配置再看一眼你当前的软件源里到底写了什么grep -R ros /etc/apt/sources.list /etc/apt/sources.list.d/ 2/dev/null常见的输出就是类似这样的一行deb http://mirrors.ustc.edu.cn/ros/ubuntu jammy main问题已经很明显了ros/ubuntu后面跟的是jammy。你要记住这个命令里最后面的main是组件名jammy是发行版代号两者之间用空格分开。如果你看到deb http://mirrors.ustc.edu.cn/ros/ubuntu focal main那说明源本身没问题但你的系统却是 22.04那同样要重新评估你的安装方案。3.3 第三步直接访问镜像服务器上的 Release 文件这一步最直观能够确认“不是 apt 的问题而是仓库里确实没有这个文件”。用 curl 直接探测一下curl -I http://mirrors.ustc.edu.cn/ros/ubuntu/dists/jammy/Release如果服务器返回HTTP/2 404就表示镜像上确实没有这个文件。再试一下正确的路径curl -I http://mirrors.ustc.edu.cn/ros2/ubuntu/dists/jammy/Release这时候应该能看到HTTP/2 200或者 3xx 跳转接着返回文件内容。这一对比根因就完全清楚了不是 apt 不会配置是仓库路径和发行版组合选错了。以后再遇到类似的 Release 报错我都会先做这个 curl 探测比反复apt clean有用得多。4. 按场景修复ROS 1、ROS 2、还是系统不匹配知道根因之后修复方案要看你的真实目标。我遇到的情况大致分三种对号入座即可。4.1 场景一其实你想装 ROS 1 Noetic但系统是 Ubuntu 22.04这是最坑的一种。很多教程还停留在 ROS 1 时代但你已经装好了 22.04。ROS 1 Noetic 的二进制包只在 focal 上构建官方没有为 jammy 提供包。你硬把jammy写进去不会有任何效果。这种情况下我的建议是不要硬刚如果你一定要用 ROS 1换个 Ubuntu 20.04 环境或者装个 Docker 容器跑 20.04。在容器内添加focal对应的 ROS 1 源再安装会省去非常多依赖冲突的烦恼。比如先起一个容器docker run -it --name ros-noetic ubuntu:20.04 bash然后在容器里按 ROS 1 Noetic 的标准流程配置源和安装。这样宿主机哪怕已经是 24.04也不影响里面的环境。如果项目没有历史包袱我更推荐直接迁移到 ROS 2 Humble。ROS 1 停止维护已经很久了新系统上的支持只会越来越差。4.2 场景二你要装的是 ROS 2 Humble地址用错了仓库这是目前最容易被误杀的情况。你在 Ubuntu 22.04 上想装 ROS 2但网上搜到的教程可能混着写把ros/ubuntu和jammy拼在了一起。ROS 2 Humble 实际对应的仓库应该是ros2/ubuntu套件名才是jammy。正确的源配置应该类似于echo deb [arch$(dpkg --print-architecture) signed-by/usr/share/keyrings/ros-archive-keyring.gpg] http://mirrors.ustc.edu.cn/ros2/ubuntu jammy main | sudo tee /etc/apt/sources.list.d/ros2.list /dev/null这里一定要把仓库路径改成ros2/ubuntu。改完之后再sudo apt update那个 “does not have a Release file” 就再也不会出现了。顺便提一句国内很多同学喜欢用“鱼香ROS”的一键安装脚本。这个脚本的核心价值是帮你自动配源、配密钥、装依赖但它同样要遵守版本匹配规则。它不会违背“ROS 2 Humble 配套 jammy”这个基本事实只是把繁琐步骤自动化了。所以即便用一键脚本也得大概知道自己的分发版本和 ROS 版本对应关系。4.3 场景三仓库地址写错或源文件残留还有一种情况更简单你原本是 Ubuntu 20.04或者之前配置过 ROS 1后来系统升级或换了教程导致/etc/apt/sources.list.d/里残留了多个互相冲突的源文件。我建议先看一眼目录里到底放了什么ls -l /etc/apt/sources.list.d/如果有ros-latest.list、ros2.list、ubuntu-ros.list之类多个文件且里面的仓库路径互相矛盾干脆把之前添加的都清理掉重新只保留一个正确的源。手动删除比在文件里反复注释更干净不容易出现第二个源文件又把报错“带回来”的情况。5. 修复后的完整安装流程GPG 密钥、apt update 与验证解决了 Release 文件的问题后面正式安装 ROS 的流程也会遇到不少坑这里把完整链路走一遍。5.1 清理失效源先把你刚才误加的源清理掉避免apt update再次报同样的错。清理时只删自己添加的源文件别动系统默认文件sudo rm -f /etc/apt/sources.list.d/ros-latest.list sudo rm -f /etc/apt/sources.list.d/ros2.list sudo apt update如果这里不再出现E:开头的错误说明环境已经干净了。注意你要删的文件名以自己实际添加的为准不要照抄我的文件名就把系统的其他源也删了。5.2 添加正确的源和 GPG 密钥现在以 ROS 2 Humble Ubuntu 22.04 为例重新添加源。先确保有 curl然后下载 ROS 官方 GPG 密钥sudo apt update sudo apt install -y curl sudo curl -sSL https://raw.githubusercontent.com/ros/rosdistro/master/ros.key -o /usr/share/keyrings/ros-archive-keyring.gpg再写源文件时用前面提到的ros2/ubuntu路径echo deb [arch$(dpkg --print-architecture) signed-by/usr/share/keyrings/ros-archive-keyring.gpg] http://mirrors.ustc.edu.cn/ros2/ubuntu jammy main | sudo tee /etc/apt/sources.list.d/ros2.list /dev/null这里解释一下signed-by的作用它明确指定 apt 用哪个密钥文件校验这个仓库而不是把密钥塞进系统全局的/etc/apt/trusted.gpg。后者是早年apt-key add的做法已经被官方标记为弃用在较新的 Ubuntu 上还会直接产生警告。每次配置新环境我都推荐用这种 per-source 的密钥方式以后排查密钥冲突会轻松很多。如果环境是 Ubuntu 20.04 且要装 ROS 1 Noetic只需要把路径改回ros/ubuntu套件名改成focal密钥文件是同一个echo deb [arch$(dpkg --print-architecture) signed-by/usr/share/keyrings/ros-archive-keyring.gpg] http://mirrors.ustc.edu.cn/ros/ubuntu focal main | sudo tee /etc/apt/sources.list.d/ros-latest.list /dev/null再次执行sudo apt update看到大量更新索引刷过去且末尾没有E:报错就说明源已经通了。5.3 安装 ROS 并验证环境源就位后安装本身反而简单sudo apt install -y ros-humble-desktop如果你只想先跑最小的机器人通信例子可以换成ros-humble-ros-base体积小很多。安装完成后记得把环境脚本写进 bashrc否则每次新开终端都要手动 sourceecho source /opt/ros/humble/setup.bash ~/.bashrc source ~/.bashrc最后验证一下ros2 --version能输出ros2的版本号说明整套环境已经可用了。到这一步你再回头想那个 “does not have a Release file”会发现它只是整个 ROS 安装流程里一个非常早的版本匹配提醒早发现早解决比后面所有依赖问题都省事。6. Release 文件缺失不是 ROS 专属其他常见场景与通用排查思路“does not have a Release file” 这个报错其实广泛存在于所有 apt 仓库中ROS 源只是其中一种高发场景。我这两年还在别的环境里反复碰到过类似问题这里一并说一下。6.1 本地光盘源和过期源很多人在安装 Ubuntu 时系统会自动写入一个本地/cdrom的源比如deb file:/cdrom focal main restricted当你把安装光盘或镜像卸载之后apt 再去访问这个本地路径很可能找不到对应的Release文件于是报出“不再含有 release 文件”之类的提示。处理方式很简单去/etc/apt/sources.list里把对应那行注释掉或者直接删除都行。6.2 第三方仓库不匹配当前发行版如果你添加过某个 PPA之后系统升级到了新的 Ubuntu 版本而 PPA 作者没有为这个新版本重新发布软件包apt 同样会在更新时报 “Release file” 缺失。还有的仓库只发布 amd64 架构你在 ARM 设备上强行添加也一样会出现类似问题。这种情况的通用做法是去仓库的dists/目录下看一眼确认有没有你当前系统的代号和架构不要死守着一个源地址。6.3 一个顺手的排查顺序踩过这么多次坑之后我自己总结了一套固定排查顺序用lsb_release -sc确认系统发行版代号。用grep -R deb /etc/apt/sources.list /etc/apt/sources.list.d/确认源里面写的是什么路径、什么套件名。用curl -I 仓库地址/dists/代号/Release直接探测是否存在。最后才动手删文件、换路径、补密钥。我从来没有见过哪次报错是因为 USTC 或清华的镜像“故意丢掉 Release 文件”。绝大多数情况就是仓库路径、发行版代号、ROS 版本三者之间错位。现在每配一个新环境我都会先 curl 一下 Release 文件再写进 sources.list这个习惯至少帮我省下好几轮反复apt update的折腾时间。如果你也卡在这个报错上按这个顺序排查十分钟内基本能定位到问题。