Ubuntu 9.10 更新源配置避坑指南：3 个步骤搞定镜像失效难题

你是不是也遇到过这种崩溃时刻？刚把祖传的配置脚本复制过来，或者从网上搜到的镜像地址填进 sources.list，结果 sudo apt-get update 直接报错 404 或者连接超时。明明代码看起来没问题，跑不通就是不知道哪里坑，这种“复制粘贴式开发”带来的痛苦，每个运维老鸟都懂。今天这篇 Ubuntu 9.10 更新源配置的避坑指南，不玩虚的，直接拆解底层逻辑，帮你彻底搞懂为什么老版本系统换个源就难如登天。

一句话原理：HTTP 协议与索引文件的握手机制

很多人以为更新源就是一个巨大的仓库，你连上去就能下东西。其实不然，apt-get update 的核心动作，并不是下载软件包，而是下载并解析元数据。

想象一下你去图书馆借书。你不需要把整个图书馆的书搬回家，你只需要拿着图书馆的“目录索引”（InRelease, Release, Release.gpg 等文件）来看。Apt 工具做的事情，就是去你指定的镜像服务器（Mirror）目录下，抓取这些“目录索引”。如果这些索引文件里的时间戳是最新的，且数字签名校验通过，Apt 才会认为这个源是“可信”的，然后才会去下载具体的 .deb 包。

Ubuntu 9.10（代号 Jaunty Jackalope）发布于 2009 年，早已停止官方支持（EOL）。这意味着 Canonical 官方的 archive.ubuntu.com 上已经不再维护 Jaunty 的最新索引，甚至可能因为安全策略调整，部分旧目录结构被归档或迁移。这就是为什么你复制网上的“最新”源地址，在 9.10 上会报错——因为那个地址根本不提供 Jaunty 的元数据了。

类比解释：寻找“死”掉的图书馆管理员

为了让你更直观地理解，我们把 APT 的更新流程比作寻找一个已经退休的图书馆管理员。

1. 官方源（archive.ubuntu.com）：这是总馆。管理员（Canonical）说：“Jaunty 版本已经下架了，我这里没有它的最新目录，你去分馆找找。”
2. 镜像源（Mirrors）：这是各地的分馆。有些分馆（如阿里云、腾讯云、清华 TUNA）为了节省空间，只保留最近 2-3 年的活跃版本。对于 9.10 这种“古董”版本，大多数现代镜像站已经删除了相关的 dist/jaunty 目录。
3. 归档源（Old-Release）：这是专门存放“绝版书”的仓库。只有极少数专注于历史版本的镜像站（如 Ubuntu 官方归档服务器、某些高校的历史镜像）还保留着 Jaunty 的完整索引。

痛点来了：很多网上的教程，直接让你把 http://archive.ubuntu.com/ubuntu 改成 http://mirrors.aliyun.com/ubuntu。这在 20.04 或 22.04 上没问题，因为阿里镜像里有这些版本的完整目录。但在 9.10 上，阿里镜像里根本没有 jaunty 这个目录。Apt 去那里找“目录索引”，得到的结果是 404 Not Found。

这时候，如果你不懂原理，只会不断尝试不同的镜像站，直到绝望。懂原理的人知道：对于 EOL 版本，必须寻找专门保留历史数据的归档源，而不是通用的商业镜像源。

源码与配置片段：如何正确配置 Jaunty 源

下面这段配置代码，是基于 Ubuntu 官方归档仓库（Official Archive Repository）结构整理的实战配置。请注意，这里的域名和路径必须精确匹配历史版本的结构。

# /etc/apt/sources.list
# Ubuntu 9.10 (Jaunty Jackalope) - Archived Sources
# 注意：以下地址指向保留历史版本的镜像，请根据网络环境选择可达的地址# 主要组件
deb http://old-releases.ubuntu.com/ubuntu/ jaunty main restricted universe multiverse
deb http://old-releases.ubuntu.com/ubuntu/ jaunty-updates main restricted universe multiverse
deb http://old-releases.ubuntu.com/ubuntu/ jaunty-security main restricted universe multiverse# 源组件（如果需要编译软件包）
# deb-src http://old-releases.ubuntu.com/ubuntu/ jaunty main restricted universe multiverse
# deb-src http://old-releases.ubuntu.com/ubuntu/ jaunty-updates main restricted universe multiverse
# deb-src http://old-releases.ubuntu.com/ubuntu/ jaunty-security main restricted universe multiverse

逐行讲解：

1. deb http://old-releases.ubuntu.com/ubuntu/ jaunty ...：

   • deb：表示二进制包。
   • http://old-releases.ubuntu.com/ubuntu/：这是关键。Canonical 将不再维护的旧版本移至 old-releases 子域名或特定归档路径。普通的 archive.ubuntu.com 可能不再响应 Jaunty 的请求。
   • jaunty：这是 9.10 的代号（Codename）。APT 通过代号而非版本号来定位目录，这样更稳定。
   • main restricted universe multiverse：这四个组件决定了你能下载哪些软件。universe 和 multiverse 在非官方支持期后可能会因为许可证问题被移除或标记为不可用，但在归档源中通常仍保留。

2. jaunty-updates 与 jaunty-security：

   • 即使系统已 EOL，安全更新和紧急修复包在归档时通常会保留一段时间。配置这两个源可以确保你还能打上最后的安全补丁。
   • 避坑点：有些旧的教程会写成 jaunty-backports。对于 9.10 这个年代，Backports 源的存在意义不大，且很多归档站未保留，建议直接去掉，减少报错概率。

3. # deb-src ...：

   • 源码行默认注释掉。除非你需要 apt-get source 功能，否则开启源码行会增加 update 的时间，且容易因 GPG 密钥缺失导致报错。

为什么选 old-releases.ubuntu.com？ 根据 Ubuntu 官方的生命周期策略，当 LTS 版本结束支持后，会被移入归档。虽然 9.10 不是 LTS（它是普通版本，支持期更短），但其数据依然保留在 Canonical 的归档结构中。old-releases 域名是访问这些“冷冻”数据的标准入口之一。如果你在国内访问 old-releases.ubuntu.com 速度慢，可以尝试寻找国内高校或机构保留的完整历史镜像，例如清华大学 TUNA 镜像站的历史存档（需确认其是否仍保留 Jaunty 目录，因为 TUNA 也会清理过旧数据，建议先 curl 测试连通性）。

流程描述：Apt 如何验证一个“死”源

当你执行 sudo apt-get update 时，后台发生了这样一系列精密的校验流程。理解这个流程，你就能自己诊断问题：

1. 解析配置：APT 读取 /etc/apt/sources.list 和 /etc/apt/sources.list.d/ 下的所有文件，提取出 URL 和组件列表。
2. 构建请求路径：APT 根据 URL 和代号（jaunty），拼接出完整的索引文件路径，例如 http://old-releases.ubuntu.com/ubuntu/dists/jaunty/InRelease。
3. 下载元数据：HTTP GET 请求发送。
   • 情况 A（404）：服务器返回 404。说明路径不存在。可能是镜像站没保留该版本，或者代号拼写错误。
   • 情况 B（200 OK）：下载成功。
4. GPG 签名验证：
   • APT 会下载 Release.gpg 或 InRelease 中的签名块。
   • 使用 /etc/apt/trusted.gpg 或 /etc/apt/trusted.gpg.d/ 中的公钥进行验证。
   • 避坑点：对于极老版本，如果密钥库中没有对应的 Canonical 历史公钥，会报 NO_PUBKEY 错误。这时你需要手动导入旧版本的密钥环。
5. 时间戳检查：
   • APT 检查 Release 文件中的 Origin、Label 和 Codename 是否与系统期望一致。
   • 如果 Acquire-By-Hash 失败，或哈希值不匹配，会报 Hash sum mismatch。这通常意味着镜像站的数据损坏，或你混用了不同时期的源文件。
6. 更新本地数据库：验证通过后，APT 将索引信息写入 /var/lib/apt/lists/，供后续 install 命令使用。

文字流程图示：

[User] -> sudo apt-get update|v
[APT] 解析 sources.list -> 提取 URL: http://old-releases.ubuntu.com/ubuntu/|v
[Network] GET /dists/jaunty/InRelease|+---> [404 Not Found] -> Error: 404 Not Found [IP: ...]|+---> [200 OK] -> Download InRelease|v
[Crypto] Verify GPG Signature|+---> [Invalid Signature] -> Error: The following signatures were invalid|+---> [Valid] -> Check Hashes|v
[Storage] Write to /var/lib/apt/lists/|v
[Done] "Reading package lists... Done"

实战验证与进阶技巧：当老系统遇到新网络

在实际操作中，仅仅配置好源还不够。Ubuntu 9.10 运行在现代网络环境中，还会遇到 HTTPS 证书、DNS 解析等隐形坑。

1. 处理 GPG 密钥缺失

如果你看到类似这样的报错： W: GPG error: http://old-releases.ubuntu.com jaunty Release: The following signatures were invalid: NO_PUBKEY ...

这是因为 9.10 使用的签名密钥可能不在你当前的 trusted.gpg 中。解决方案是手动导入 Canonical 的历史密钥。你可以从官方源码仓库（Official Source Repository）的历史发布页面找到对应的 ubuntu-keyring 版本，或者从其他仍在使用 9.10 的环境中提取密钥。

# 示例：假设你找到了历史密钥文件 ubuntu-keyring_2009.gpg
sudo gpg --keyserver hkp://keyserver.ubuntu.com --recv-keys <KEY_ID>
sudo gpg --export <KEY_ID> | sudo apt-key add -

注：apt-key 在新版 Ubuntu 中已废弃，但在 9.10 上仍是标准做法。

2. DNS 与解析问题

老版本的 Glibc 和 DNS 解析库对现代 DNS 服务器（如 DoH, DNS over HTTPS）支持不佳。如果 update 卡在建连阶段，检查 /etc/resolv.conf，确保使用传统的 UDP/TCP 53 端口解析。避免使用需要特定协议扩展的 DNS 服务商。

3. 使用 apt-transport-https 的局限性

Ubuntu 9.10 的 apt 版本非常老，可能不支持 https 传输协议，或者对自签名证书支持很差。因此，强烈建议使用 http 而非 https。如果镜像站只支持 HTTPS，你需要确保该 HTTPS 证书链完整，且不被中间人拦截。否则，你会遇到难以排查的 SSL certificate problem。

4. 镜像站选择策略

对于 EOL 版本，选择镜像站的优先级如下：

1. 官方归档（old-releases.ubuntu.com）：最权威，但国内访问可能慢。
2. 大型高校/机构历史镜像：如清华、中科大，但需确认其是否保留 2009 年的数据。很多高校镜像只保留最近 5 年的数据。
3. 第三方归档服务：如 Internet Archive 的 Ubuntu 快照。但这需要复杂的配置，不建议生产环境使用。

实战建议： 在执行 sudo apt-get update 之前，先用 curl 或 wget 测试镜像的可达性和目录存在性。

# 测试镜像是否保留 Jaunty 目录
curl -I http://old-releases.ubuntu.com/ubuntu/dists/jaunty/Release
# 期望输出包含 HTTP/1.1 200 OK

如果返回 404，说明该镜像未保留 Jaunty 数据，换下一个源，而不是盲目修改 sources.list 然后跑 apt-get update 等待报错。

避坑总结与互动

回顾一下，配置 Ubuntu 9.10 更新源的核心不在于“找一个快的源”，而在于“找一个还活着的、保留历史数据的源”。大多数网上流传的教程都针对现役版本，直接套用到 EOL 版本上，必然失败。

关键避坑点总结：

1. 认准代号：使用 jaunty 而非 9.10。
2. 认准归档域名：优先尝试 old-releases.ubuntu.com。
3. 忽略 Backports：老版本 Backports 源容易缺失，去掉更稳妥。
4. 手动验证连通性：curl 测试先行，避免 apt 报错后盲目排查。
5. GPG 密钥：准备好处理 NO_PUBKEY 错误，这是老系统的常态。

Ubuntu 9.10 已经退役十多年，它更多出现在工控机、旧设备或特定嵌入式场景中。在这些场景中，系统的稳定性远比“新”重要。配置好更新源，确保能获取最后的安全补丁，是维护这类老系统的底线。

互动话题： 在维护这些“上古”Linux 系统时，你是更倾向于彻底断开网络，仅使用离线 ISO 进行补丁管理？还是像本文这样，配置一个可靠的归档源，定期 update 检查？或者你有其他更“硬核”的离线更新方案？你更常用哪种写法？评论区交流一下，看看谁的老系统维护技巧更绝。