企业官网建设流程全解析

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 can't 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/<发行版代号>/Release，Release文件里记录了这套仓库支持哪些组件、哪些架构、哪些文件的哈希值。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 版本。这里建议先对照一下官方支持的版本组合：

注意看最后一列：你要在 22.04 上装 ROS 2 Humble，仓库地址应该用ros2/ubuntu，而不是ros/ubuntu。如果教程里加的是ros/ubuntu，套件名写的却是jammy，apt 自然只能拿回一个 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，否则每次新开终端都要手动 source：

echo "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的折腾时间。如果你也卡在这个报错上，按这个顺序排查，十分钟内基本能定位到问题。