Ubuntu 18.04 arm64镜像源配置全攻略：解决APT更新404问题

1. 项目缘起为什么Ubuntu 18.04 arm64的镜像源是个“老大难”问题最近在折腾一台基于ARM架构的开发板系统选的是经典的Ubuntu 18.04 LTS。本以为apt update一下是分分钟的事结果命令行里刷出来的全是“无法连接”、“404 Not Found”。这场景但凡在ARM平台上搞过开发的估计都遇到过。Ubuntu 18.04 arm64的镜像源说它是个“老大难”问题一点不为过。这背后其实是官方支持策略、硬件生态和网络环境多重因素交织的结果。首先Ubuntu 18.04 LTSBionic 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是focal22.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_ipv61 sudo sysctl -w net.ipv6.conf.default.disable_ipv61执行apt 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命令中正确指定了--archarm64参数。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版本迁移把时间花在更有价值的开发工作上而不是和日渐稀少的软件包源作斗争。