1. 项目缘起：为什么Ubuntu 18.04 arm64的镜像源是个“老大难”问题？
最近在折腾一台基于ARM架构的开发板，系统选的是经典的Ubuntu 18.04 LTS。本以为apt update一下是分分钟的事，结果命令行里刷出来的全是“无法连接”、“404 Not Found”。这场景，但凡在ARM平台上搞过开发的，估计都遇到过。Ubuntu 18.04 arm64的镜像源，说它是个“老大难”问题，一点不为过。这背后，其实是官方支持策略、硬件生态和网络环境多重因素交织的结果。
首先，Ubuntu 18.04 LTS（Bionic Beaver）本身在2023年4月就已经结束了标准支持期，进入了扩展安全维护阶段。对于主流的amd64架构，很多镜像站出于历史惯性或兼容性考虑，还会保留老版本的仓库。但对于arm64架构，情况就大不相同了。ARM服务器和开发板在2018年远没有今天这么普及，当时很多镜像站可能就没有同步arm64的仓库，或者同步不全。随着时间推移，维护成本增加，这些不完整的arm64仓库被清理或停止更新的概率就大大增加了。
其次，网络环境的影响被放大了。即便某个镜像站理论上还存有arm64的包，跨国网络的不稳定性也可能导致连接超时或速度极慢。这时候，一个稳定、高速且完整的国内镜像源，就成了刚需。但问题恰恰在于，很多国内镜像源对老版本、非主流架构的支持是“薛定谔”的状态——可能有，但不一定全；可能能连上，但速度不一定快。
所以，当你面对一个Ubuntu 18.04 arm64系统时，配置镜像源远不止是简单替换一个/etc/apt/sources.list文件里的网址那么简单。你需要知道哪些源是可靠的，哪些源已经失效，以及如何验证和修复因源不完整导致的各种依赖问题。这篇文章，我就结合自己最近一次在RK3588开发板上部署Ubuntu 18.04 arm64的真实经历，把镜像源配置的完整链路、踩过的坑以及验证方法，给你彻底讲清楚。
2. 核心原理：APT源的结构与arm64仓库的“特殊性”
在动手改配置之前，我们得先弄明白APT源到底是怎么工作的，以及arm64架构的仓库有什么不同。这样出了问题，你才知道从哪里下手排查，而不是盲目地尝试一堆网上搜来的命令。
APT是Debian/Ubuntu系统的包管理工具，它的源列表文件（sources.list）定义了从哪里下载软件包。一个典型的源条目长这样：
deb http://archive.ubuntu.com/ubuntu/ bionic main restricted universe multiverse我们来拆解一下：
deb: 表示这是一个二进制软件包仓库（与之相对的是deb-src，表示源代码包仓库，通常不需要）。http://archive.ubuntu.com/ubuntu/: 这是镜像站的基地址。bionic: 这是Ubuntu 18.04的代号。不同版本代号不同，比如20.04是focal，22.04是jammy。这一点绝对不能错，用错了代号就会导致找不到包。main restricted universe multiverse: 这是软件包的四个主要组件分类。简单理解，main是官方支持的开源软件，universe是社区维护的开源软件，我们大部分软件来自这里。restricted和multiverse涉及专有驱动和版权软件，通常也需要。
那么，arm64的“特殊性”体现在哪里呢？关键在于镜像站的目录结构。当你访问一个镜像站时，比如http://mirrors.ustc.edu.cn/ubuntu/，你会看到一堆以dists/开头的目录，对应各个发行版。在dists/bionic/main/目录下，你会发现binary-amd64/和binary-arm64/这样的子目录。一个镜像站是否支持arm64，就看它有没有同步binary-arm64/这个目录，以及这个目录下的内容是否完整。
很多问题就出在这里：
- 目录缺失：一些镜像站可能根本没有同步
binary-arm64/目录。你用amd64的源地址去访问，main仓库是有的，但下面只有binary-amd64，没有binary-arm64。APT在更新时，会发现这个仓库不支持你的架构，从而忽略它或报错。 - 内容不全：更常见的情况是，镜像站同步了
binary-arm64/目录，但里面的包索引文件（如Packages.gz）不完整，或者包文件本身缺失。这会导致apt update能成功，但apt install某个具体软件时，却提示“无法定位软件包”或“依赖关系无法满足”。这是因为APT根据索引文件知道了这个包应该存在，但实际下载时却找不到对应的.deb文件。
注意：判断一个镜像源是否真的支持
bionic-arm64，一个很有效的方法是直接使用浏览器或wget去访问其目录。例如，尝试访问http://mirrors.ustc.edu.cn/ubuntu/dists/bionic/main/binary-arm64/，如果返回403 Forbidden或404，基本可以断定不支持或未同步。如果能看到Packages.gz等文件列表，则说明支持。
3. 实战配置：手把手替换Ubuntu 18.04 arm64的镜像源
理论清楚了，我们开始实战。整个过程可以分为备份、选源、替换、更新、验证五个步骤。我会以国内访问速度和可靠性相对较好的几个源为例进行说明。
3.1 第一步：备份原始源列表
这是所有系统修改操作的第一步，也是安全底线。通过SSH或直接终端进入你的Ubuntu 18.04 arm64系统。
sudo cp /etc/apt/sources.list /etc/apt/sources.list.backup这条命令将系统原有的源列表文件复制一份作为备份。万一新源有问题，你可以用sudo cp /etc/apt/sources.list.backup /etc/apt/sources.list快速还原。
3.2 第二步：选择合适的国内镜像源
对于Ubuntu 18.04 arm64，经过实测，以下镜像源的完整性和可用性相对较好（截至撰写时）：
- 中国科学技术大学开源软件镜像站：速度稳定，对老版本支持较好。
- 清华大学开源软件镜像站：国内高校镜像的标杆，同步及时。
- 阿里云开源镜像站：商业镜像，速度有保障，但有时对非常老版本的归档清理比较积极。
这里有一个关键选择：是直接使用镜像站提供的bionic目录，还是使用其ubuntu-ports/目录？对于arm64和ppc64el等非x86架构，Ubuntu官方有一个专门的入口叫ports.ubuntu.com。一些镜像站会选择同步这个ubuntu-ports仓库，而不是主仓库。因此，你的源地址可能是以下两种形式之一：
- 形式一（主仓库）：
http://mirrors.ustc.edu.cn/ubuntu/ - 形式二（ports仓库）：
http://mirrors.ustc.edu.cn/ubuntu-ports/
如何选择？最稳妥的方法是直接访问镜像站首页，查看其使用帮助。例如，访问mirrors.ustc.edu.cn，找到Ubuntu的帮助页面，它会明确告诉你对于arm64架构，应该使用http://mirrors.ustc.edu.cn/ubuntu-ports/作为基地址。对于Ubuntu 18.04 arm64，我强烈建议优先尝试使用-ports地址，因为这是为这类架构设计的官方路径，同步完整性通常更高。
3.3 第三步：编辑sources.list文件
我们将使用sed命令进行全局替换，这是最快捷的方式。假设我们决定使用中国科学技术大学的ubuntu-ports镜像。
首先，查看当前源使用的官方地址是什么：
cat /etc/apt/sources.list | grep -E '^deb ' | head -1通常，默认的官方地址是http://archive.ubuntu.com/ubuntu或http://ports.ubuntu.com/ubuntu-ports。
接下来，执行替换。请务必根据你系统的实际情况，将old-mirror替换为当前文件里的实际地址。
# 如果当前源是 archive.ubuntu.com sudo sed -i 's|http://archive.ubuntu.com/ubuntu|http://mirrors.ustc.edu.cn/ubuntu-ports|g' /etc/apt/sources.list # 如果当前源是 ports.ubuntu.com (arm64系统常见) sudo sed -i 's|http://ports.ubuntu.com/ubuntu-ports|http://mirrors.ustc.edu.cn/ubuntu-ports|g' /etc/apt/sources.list # 如果使用的是https，同理替换 sudo sed -i 's|https://archive.ubuntu.com/ubuntu|http://mirrors.ustc.edu.cn/ubuntu-ports|g' /etc/apt/sources.list提示：这里我使用了
http而非https。对于国内镜像站，http完全足够，且可以避免因证书问题导致的意外错误。如果你所在环境要求https，镜像站通常也支持，只需将地址中的http改为https即可，例如https://mirrors.ustc.edu.cn/ubuntu-ports/。
替换完成后，强烈建议用cat命令检查一下文件内容：
cat /etc/apt/sources.list你应该看到所有的源地址都变成了http://mirrors.ustc.edu.cn/ubuntu-ports。同时，确保发行版代号仍然是bionic。
3.4 第四步：执行更新并处理常见错误
现在执行更新，获取新的软件包列表：
sudo apt update这是最容易出错的环节。下面我列举几种典型输出及其解决方案：
情况A：全部成功
命中:1 http://mirrors.ustc.edu.cn/ubuntu-ports bionic InRelease 获取:2 http://mirrors.ustc.edu.cn/ubuntu-ports bionic-updates InRelease [88.7 kB] ... 正在读取软件包列表... 完成恭喜你，源配置成功。可以继续sudo apt upgrade进行系统升级了。
情况B：部分仓库“忽略”或“404”
命中:1 http://mirrors.ustc.edu.cn/ubuntu-ports bionic InRelease 忽略:2 http://mirrors.ustc.edu.cn/ubuntu-ports bionic-backports InRelease 错误:3 http://mirrors.ustc.edu.cn/ubuntu-ports bionic-backports Release 404 Not Found [IP: ...] 正在读取软件包列表... 完成 E: 仓库 “http://mirrors.ustc.edu.cn/ubuntu-ports bionic-backports Release” 没有 Release 文件。这说明镜像站没有同步bionic-backports这个仓库。解决方法很简单，注释掉sources.list中关于bionic-backports的行。用sudo vim /etc/apt/sources.list或sudo nano /etc/apt/sources.list打开文件，在包含bionic-backports的行首添加#号注释掉它。保存后再次运行sudo apt update即可。
情况C：大量“无法连接”或“临时性解析错误”这通常是网络问题或镜像站临时故障。可以尝试：
- ping测试：
ping mirrors.ustc.edu.cn，看是否能通。 - 更换备用源：如果不行，换用清华或阿里云的镜像重复上述替换步骤。清华源地址为
http://mirrors.tuna.tsinghua.edu.cn/ubuntu-ports/，阿里云源地址为http://mirrors.aliyun.com/ubuntu-ports/。 - 检查DNS：如果ping不通域名但能ping通IP，可能是DNS问题。可以临时修改
/etc/resolv.conf，添加nameserver 114.114.114.114或nameserver 8.8.8.8。
3.5 第五步：验证与深度清理
更新成功后，建议安装一个软件来测试源的可用性。我们可以选一个不大不小的包，比如htop（一个进程监控工具）：
sudo apt install htop -y如果安装顺利，说明软件包下载功能正常。
但是，对于Ubuntu 18.04 arm64这种老系统，仅仅能apt update和安装个别软件还不够。你可能会在后续安装复杂软件（比如安装Docker、编译环境）时，遇到诡异的依赖问题，比如提示某个库的版本冲突，或者某个必需的-dev包找不到。这往往是因为之前的错误源或部分缺失的源，在本地APT缓存中留下了错误的或部分的索引信息。
因此，我强烈建议在执行完源更换后，进行一次深度清理：
# 清理已下载的旧版本软件包 sudo apt clean # 清理所有已下载的软件包（更彻底） sudo apt autoclean # 删除那些因为依赖关系改变而不再需要的软件包 sudo apt autoremove # 最后，再次更新并进行一次完整的升级 sudo apt update && sudo apt upgrade -y这一套“组合拳”能确保你的本地包数据库和缓存与新的镜像源完全同步，清除了历史遗留的“脏数据”，可以避免很多后续的玄学问题。
4. 进阶排查与特殊场景处理
如果你按照上面的步骤操作后，问题依旧，或者你处于一些特殊环境，那么可能需要下面这些进阶的排查手段。
4.1 使用apt-cache policy诊断具体包的问题
假设你运行sudo apt install docker.io时失败，提示无法定位软件包。你可以用以下命令诊断：
apt-cache policy docker.io这个命令会输出该软件包在所有已启用源中的版本信息。如果输出是“docker.io:”后面一片空白，或者只显示“已安装：(无)”，那就说明当前所有已配置的源里，根本没有这个包。这证实了是源的内容缺失问题，而不是你的配置语法错误。
4.2 处理“Hash Sum mismatch”错误
偶尔在apt update时，你会遇到“Hash Sum mismatch”错误。这通常是因为网络传输中数据包损坏，或者镜像站的文件正在同步中（处于不一致状态）。解决方法按顺序尝试：
- 清除APT缓存并重试：
这会删除所有本地软件包列表缓存，强制重新从服务器下载。sudo rm -rf /var/lib/apt/lists/* sudo apt update - 更换镜像源：如果步骤1无效，很可能是该镜像站该仓库的文件确实有问题。果断换另一个镜像源。
- 暂时禁用
IPv6：在一些网络环境下，IPv6解析可能导致问题。你可以临时禁用：
执行sudo sysctl -w net.ipv6.conf.all.disable_ipv6=1 sudo sysctl -w net.ipv6.conf.default.disable_ipv6=1apt update后再启用（将1改为0）。这只是诊断步骤，不建议长期禁用。
4.3 在Docker容器或离线环境中的处理
场景一：构建Docker镜像在Dockerfile中，你需要在RUN apt update之前就修改源。通常这样做：
FROM arm64v8/ubuntu:18.04 RUN sed -i 's|http://archive.ubuntu.com/ubuntu|http://mirrors.ustc.edu.cn/ubuntu-ports|g' /etc/apt/sources.list \ && sed -i 's|http://ports.ubuntu.com/ubuntu-ports|http://mirrors.ustc.edu.cn/ubuntu-ports|g' /etc/apt/sources.list RUN apt update && apt install -y your-packages注意，基础镜像arm64v8/ubuntu:18.04可能已经使用了ports.ubuntu.com作为源，所以第二条sed命令经常是必要的。
场景二：为离线环境准备本地源如果你的ARM设备完全无法连接互联网（比如某些工业环境），那么搭建一个本地镜像源是终极方案。这需要你在一台能联网的amd64机器上，使用apt-mirror或debmirror工具，将bionic的main,universe,restricted,multiverse仓库中binary-arm64部分完整地同步下来，然后通过HTTP或NFS分享给内网设备。这个过程较为复杂，但一劳永逸。核心是确保debmirror命令中正确指定了--arch=arm64参数。
4.4 关于“扩展安全维护”源
Ubuntu 18.04已进入ESM阶段。一些关键的 security 更新被移到了需要付费订阅的ESM源中。对于普通用户，如果你仍然需要安全更新，可以考虑启用Ubuntu Advantage免费个人订阅，或者依赖社区镜像。但请注意，国内镜像站通常不会同步ESM源。这意味着，即使你配置了正确的普通源，通过apt upgrade也可能不会收到所有最新的安全补丁。对于生产环境，这是一个需要评估的风险点。对于学习和开发环境，通常使用普通源即可。
5. 镜像源失效的备选方案与长期建议
即使今天可用的镜像源，未来也可能失效。因此，掌握备选方案和长期维护思路至关重要。
1. 官方源作为最后保障当所有国内镜像都失效时，官方的ports.ubuntu.com永远是最后的保障。虽然速度慢，但完整性最有保证。你可以临时切换回去下载最关键的工具（如curl,wget），或者用于验证某个软件包是否真的存在于官方仓库。
sudo sed -i 's|http://mirrors.xxx.com/ubuntu-ports|http://ports.ubuntu.com/ubuntu-ports|g' /etc/apt/sources.list sudo apt update2. 利用apt-select脚本自动测速选源虽然apt-select这个Python脚本在Ubuntu 18.04的默认源里可能没有，但你可以先通过官方源或下载.deb包安装它。安装后，运行sudo apt-select，它会自动测试全球多个镜像站的速度和延迟，并帮你生成一个最优的sources.list文件。这对于寻找可用的、速度快的非主流镜像站非常有用。
3. 考虑系统升级或迁移坦率地说，为Ubuntu 18.04 arm64寻找可用的镜像源，是一个“逆水行舟”的过程，会越来越难。最根本的解决方案是升级系统版本。如果硬件支持，强烈建议评估升级到Ubuntu 20.04 LTS或22.04 LTS的可能性。新版本不仅对arm64的支持更好，而且国内镜像源的同步也完整得多，社区活跃度也更高，你会省去无数麻烦。在决定升级前，务必在测试环境中进行，并完整备份数据。
4. 建立自己的备选源清单养成一个好习惯，维护一个属于你自己的、经过验证的镜像源列表。可以是一个文本文件，记录下不同镜像站对不同Ubuntu版本和架构的支持情况。例如：
| 镜像站 | 地址格式 | 18.04 arm64 支持情况 | 备注 |
|---|---|---|---|
| 中科大 | http://mirrors.ustc.edu.cn/ubuntu-ports/ | 良好 | 推荐，ports目录完整 |
| 清华 | http://mirrors.tuna.tsinghua.edu.cn/ubuntu-ports/ | 良好 | 推荐，同步快 |
| 阿里云 | http://mirrors.aliyun.com/ubuntu-ports/ | 一般 | 有时会清理老版本 |
| 华为云 | http://repo.huaweicloud.com/ubuntu-ports/ | 待测试 | 商业镜像，可尝试 |
当常用的源出问题时，你可以快速从这个清单里挑选下一个进行尝试，而不是盲目搜索。
折腾Ubuntu 18.04 arm64的镜像源，更像是一次对系统维护知识的深度实践。它考验的不仅仅是你修改配置文件的能力，更是你对APT工作机制、网络诊断和开源软件生态的理解。每一次“404 Not Found”的背后，都可能藏着镜像站同步策略、软件包依赖关系或者网络路由的细节。把这个问题彻底搞明白，以后遇到任何Linux系统的包管理问题，你都能做到心中有数，手中有术。最实在的建议还是那句，如果条件允许，早点规划向更新的LTS版本迁移，把时间花在更有价值的开发工作上，而不是和日渐稀少的软件包源作斗争。
