Manjaro pacman报错无法升级archlinuxcn?镜像源修复指南

发布时间:2026/9/16 17:26:00
Manjaro pacman报错无法升级archlinuxcn?镜像源修复指南 前阵子帮朋友处理一台 Manjaro他说系统突然装不了软件终端里翻来覆去就这两行错误无法从 mirrors.ustc.edu.cn : 错误无法升级 archlinuxcn (下载数据库出错)我看了一眼就知道是怎么回事pacman 在刷新第三方仓库 archlinuxcn 的数据库时没能从国内的这个中科大镜像站拉到数据。Manjaro 用户对 mirrors.ustc.edu.cn 应该不陌生很多人配置软件源、装 fcitx 输入法或者各种常用软件时都会用到它这个报错几乎每个人都迟早会遇到。这篇文章我就从报错原理到实操修复把这个问题一次讲透。先说明一点这个报错和你要安装的软件本身没有任何关系问题发生在 pacman 的同步阶段。后文会分成五部分展开先拆解报错底层机制再讲怎么按顺序排查原因然后是完整的修复方案接着是日常维护中避免再踩坑的经验最后顺带聊聊 pacman 使用中的几个高频误区。1. 这个报错到底在说什么1.1 pacman 的“数据库”不是你想的那种数据库pacman 做任何安装动作之前都需要先读取一份本地的“货物清单”——也就是/var/lib/pacman/sync/目录下的一堆.db文件。你运行pacman -Sy或pacman -Syu的时候pacman 做的第一件事就是把这份清单从远程仓库重新拉一遍。这些.db文件不是传统意义上的关系型数据库它本质上是 gzip 压缩过的文件列表里面记录了某个仓库里所有软件包的名字、版本、依赖关系和下载地址。可以把它想象成外卖平台的商家菜单你打开应用想点餐应用必须先要到最新菜单如果菜单文件下载不下来界面就只会一直转圈。pacman 也一样数据库同步失败它根本不知道从哪个仓库去装你要的包于是直接抛错。所以当你看到“无法升级 archlinuxcn (下载数据库出错)”时第一反应不应该是“我是不是装错包了”而应该是“archlinuxcn 这个仓库的数据库文件没有成功下载到本地”。1.2 为什么会指向 mirrors.ustc.edu.cn注意看这个报错的来源。它写的是“无法升级 archlinuxcn”而不是“无法升级 core”或“无法升级 extra”这说明出问题的不是 Manjaro 官方仓库而是你在/etc/pacman.conf里手动添加的第三方仓库 archlinuxcn。这个仓库是 Arch Linux 社区维护的专门打包一些官方源里没有但大家又特别常用的软件比如搜狗输入法、QQ、网易云音乐等等。你或者某个装机教程在配置它的时候把Server一行指向了中科大镜像于是 pacman 每次同步这个仓库的数据库时都会去mirrors.ustc.edu.cn拉取archlinuxcn.db文件。一旦这个文件没能下载成功就会冒出标题里这样的错误。还有一点很容易被忽略archlinuxcn 仓库的 URL 路径是/archlinuxcn/不是/archlinux/。Manjaro 官方源的地址是/manjaro/Arch 官方源是/archlinux/archlinuxcn 是另一个独立路径。如果你的配置里路径写错了也会得到 404 或者数据库路径不存在的错误。1.3 常见报错变体和含义我在不同机器上见过这个报错的多种变体整理成一张表方便你对照报错片段常见原因错误无法从 mirrors.ustc.edu.cn : 操作超时本地网络到镜像站的 HTTPS 连接超时或镜像站临时宕机错误无法从 mirrors.ustc.edu.cn : 连接被拒绝镜像站端口未开放或本地防火墙拦截错误无法从 mirrors.ustc.edu.cn : 域名解析失败本地 DNS 解析异常或 hosts 文件有错误记录错误无法升级 archlinuxcn (数据库损坏)本地缓存中的.db文件残缺需要清理后重新同步错误无法验证软件包签名未安装或未更新 archlinuxcn-keyring看到这些变体先不要慌报错信息其实已经把方向指出来了。核心问题无非三类网络到不了镜像、配置里的地址有误、本地缓存出了幺蛾子。接下来按顺序排查就行。2. 动手修复前先把这几个原因搞清楚2.1 网络侧排查ping 通不代表 HTTPS 就能拉包遇到这个报错先别急着一通乱改/etc/pacman.conf。我见过太多人把源换了一遍又一遍最后发现是本地 DNS 或者网络代理的问题。正确的顺序应该是先测网络再看配置最后动缓存。很多人喜欢先在终端里ping mirrors.ustc.edu.cn看到返回正常就以为网络没问题。这其实是个误区。ping 测的是 ICMP 通不通而 pacman 走的是 HTTPS真正要验证的是 TCP 443 端口能不能建立连接、TLS 握手能不能完成。手动拉数据库文件是最直接的验证手段curl -I https://mirrors.ustc.edu.cn/archlinuxcn/x86_64/archlinuxcn.dbcurl -L -o /dev/null -w %{http_code} %{time_total}\n https://mirrors.ustc.edu.cn/archlinuxcn/x86_64/archlinuxcn.db第一条命令看 HTTP 返回头第二条命令看下载状态码和耗时。如果 curl 都拉不下来要么是镜像站暂时抽风要么是本地网络访问这个域名有问题如果 curl 秒完且返回 200那问题大概率出在 pacman 本地缓存上。另外提醒一下如果你是在虚拟机里装的 Manjaro比如 VirtualBox默认的 NAT 网络模式偶尔会导致 HTTPS 连接异常超时。遇到这种情况可以试试把网络模式切换成桥接或者换一个 DNS 服务器再测试。2.2 仓库配置排查很多人把路径搞混网络没问题的话下一步就看配置。打开/etc/pacman.conf看一眼cat /etc/pacman.conf | grep -A3 archlinuxcn重点看[archlinuxcn]这段的写法[archlinuxcn] SigLevel Optional TrustedOnly Server https://mirrors.ustc.edu.cn/archlinuxcn/$arch注意这个 URL 的路径是/archlinuxcn/不是/archlinux/。很多人把 archlinuxcn 和 Manjaro 官方仓库的地址混在一起把路径写成/archlinux/自然就会 404。另外archlinuxcn 是通过/etc/pacman.conf里的Server行固定的它不受pacman-mirrors管理。也就是说你执行sudo pacman-mirrors -c China只能更换 Manjaro 官方仓库的镜像并不会改掉 archlinuxcn 的服务器地址。搞明白这一点你就不会在换了官方源之后仍然看到mirrors.ustc.edu.cn报错而百思不得其解了。2.3 本地缓存与锁文件最容易被忽略的隐性故障pacman 拉下来的.db文件缓存在/var/lib/pacman/sync/目录下。如果某次下载因为断网、CtrlC 强行中断而留下了残缺文件下一次同步时 pacman 可能会误以为缓存已经是最新的不重新下载于是报错。这时候最直接的解决办法是把对应的缓存文件删掉再同步sudo rm -f /var/lib/pacman/sync/archlinuxcn.db /var/lib/pacman/sync/archlinuxcn.files sudo pacman -Syy这些.db文件只是远程数据库的本地副本删掉完全没有风险下次同步会重新生成。还要检查一下/var/lib/pacman/db.lck这个锁文件是否存在。如果上次 pacman 被异常终止会留下锁文件导致 pacman 报错无法继续。确认没有 pacman 进程在运行后直接删除锁文件即可sudo rm -f /var/lib/pacman/db.lck3. 完整修复流程从应急到根治3.1 应急处理先让系统能继续用如果只是临时想装一个官方源里已有的软件最快做法是先把 archlinuxcn 暂时注释掉。编辑/etc/pacman.conf在[archlinuxcn]段的Server行前加#然后运行sudo pacman -Syu。这样 pacman 会跳过这个仓库所有官方源的软件可以正常安装和更新。但请注意如果系统里已经装了来自 archlinuxcn 的包比如 fcitx5-sogou 或者 yay那么注释掉这个仓库后后续更新这些包时会报“无法满足依赖关系”或直接让某些软件停在旧版本。所以这个办法只能应急不建议长期这么做。3.2 清理缓存并重新同步数据库恢复正常使用的最短路径是这样的以 x86_64 架构为例sudo rm -f /var/lib/pacman/sync/archlinuxcn.db /var/lib/pacman/sync/archlinuxcn.files sudo pacman -Syy先删掉可能的损坏缓存再用-Syy强制刷新注意是两个y它会忽略本地缓存强制重新下载。多数情况下这一步就能解决。如果-Syy还是报错就要考虑换镜像了。3.3 更换 archlinuxcn 的国内镜像把 archlinuxcn 的Server换成其他同步节点。目前常用的国内镜像有镜像Server 行中科大https://mirrors.ustc.edu.cn/archlinuxcn/$arch清华 TUNAhttps://mirrors.tuna.tsinghua.edu.cn/archlinuxcn/$arch阿里云https://mirrors.aliyun.com/archlinuxcn/$arch修改前先备份这是个好习惯sudo cp /etc/pacman.conf /etc/pacman.conf.bak然后编辑sudo nano /etc/pacman.conf把[archlinuxcn]下的Server改成清华或阿里云的地址保存后执行sudo pacman -Syy如果换源后还是失败可以再换一家。顺便提一个原则换源不要只看速度还要看这个镜像站的同步是否及时。archlinuxcn 的镜像如果同步滞后数据可能不完整反而会导致各种奇怪问题。中科大源整体很稳但偶尔也会出现机房维护等状况这时候换到清华或阿里云往往能立刻解决问题。3.4 手动下载数据库文件塞进 pacman 信任目录还有一种少见但很实用的情况curl 能正常下载数据库文件但 pacman -Sy 却反复失败。这种时候可以手动把数据库文件放到本地同步目录绕过网络同步这一步curl -L -o ~/archlinuxcn.db https://mirrors.ustc.edu.cn/archlinuxcn/x86_64/archlinuxcn.db sudo mv /var/lib/pacman/sync/archlinuxcn.db /var/lib/pacman/sync/archlinuxcn.db.bak sudo cp ~/archlinuxcn.db /var/lib/pacman/sync/archlinuxcn.db sudo pacman -Syu注意两点第一这个办法只能作为应急手段文件权限保持 root 可读即可第二如果下载的是带签名验证的.db文件pacman 会在同步时自动重新验证不需要额外操作。如果签名验证失败那就要检查 keyring 了下一章会专门说。3.5 修完之后的验证步骤修完之后用sudo pacman -Syy或者sudo pacman -Syu看看输出里 archlinuxcn 是否还报错。如果数据库能顺利同步终端会提示数据库已更新。这时候再执行你的原始安装命令问题就消失了。也可以用这个命令确认仓库是否已经加载成功pacman -Sl archlinuxcn | head -20能列出一排软件包就说明数据库已经正常加载。4. 日常维护与进阶避坑4.1 给仓库配置多个备用镜像修复问题的同时我强烈建议给 archlinuxcn 配置多个镜像。pacman 在同步的时候如果第一行地址拉取失败会按顺序自动尝试下一行。也就是说你可以在[archlinuxcn]下同时写上中科大和清华[archlinuxcn] SigLevel Optional TrustedOnly Server https://mirrors.ustc.edu.cn/archlinuxcn/$arch Server https://mirrors.tuna.tsinghua.edu.cn/archlinuxcn/$arch Server https://mirrors.aliyun.com/archlinuxcn/$arch这样即使某一个镜像出了临时故障pacman 也会自动切到下一个而不是直接抛出一行看似很吓人的报错。我在实际使用中把这条规则推广到了所有第三方仓库效果非常明显近几年几乎没有再遇到数据库同步失败的问题。4.2 archlinuxcn-keyring 与签名信任问题archlinuxcn 仓库第一次使用时会要求你安装archlinuxcn-keyring这个包它的作用是导入和维护仓库签名密钥。如果你在数据库没同步的情况下直接去装 keyring是装不上的因为 keyring 本身也在 archlinuxcn 仓库里。这就形成了一个“先有鸡还是先有蛋”的局面。解决办法是先按上一章的办法把数据库同步好然后立即执行sudo pacman -S archlinuxcn-keyring如果装 keyring 时遇到“签名无效”或“密钥过期”的提示可以先执行sudo pacman -Syu sudo pacman-key --refresh-keys刷新密钥环之后再次安装 keyring一般都能解决。严格来说archlinuxcn 的.db文件本身即使没有签名验证也能读取但软件包本体和签名是绑定的没有正确的 keyring后续安装任何来自 archlinuxcn 的软件包都会报“无法验证软件包签名”。4.3 Manjaro 下使用 archlinuxcn 的兼容性雷区这一条是针对 Manjaro 用户的特别提醒。Manjaro 官方仓库并不是 Arch 官方仓库的同一样东西它一般会滞后几周以保证稳定性。archlinuxcn 的软件包是按照 Arch 官方仓库的状态构建的所以放到 Manjaro 上偶尔会出现依赖版本不匹配的情况。如果你完全按照 Arch 的教程去配置 Manjaro把 archlinuxcn 当成默认仓库来用时间久了很可能碰到某些库文件升级后某个 cn 源软件突然打不开。我的建议是在 Manjaro 上优先使用系统自带的 pamac 和 AURAUR 里面的很多软件也能覆盖 archlinuxcn 的职能如果确实需要 archlinuxcn尽量只用来安装少数几个软件不要把它当成万能仓库。4.4 保持数据库健康的几个日常习惯我自己整理了一个简单的检查清单分享出来给大家参考更新前先看镜像站公告很多同步异常会在公告里提前说明。更新时使用-Syu而不是单独的-Sy-Sy只刷新数据库但不同步软件包长期这样用容易造成依赖不一致。定期清理包缓存sudo paccache -r会保留最近的几个版本删掉更旧的包。每次执行pacman -Syu时留意输出里是否有archlinuxcn-keyring升级提示如果有先升级 keyring 再继续其他更新。5. 从一个小报错延伸到 pacman 的那些事5.1 中文输入法场景fcitx5、美化与 archlinuxcn 的关联很多人接触 Manjaro 的第一站就是中文输入法尤其是 fcitx5 的个性化配置。fcitx5 本身在 Manjaro 官方源里就有但 fcitx5 的输入法平台组件、搜狗拼音、某些 rime 配置等经常需要从 archlinuxcn 安装。这时候如果仓库数据库同步失败表现就是类似“无法升级 archlinuxcn”的报错然后输入法装到一半卡住。解决完镜像源问题后建议把 fcitx5 的配置也系统整理一下安装fcitx5-chinese-addons、设置 GTK/Qt 相关的环境变量再根据桌面环境做好自启动。这些工作最好在仓库健康的状态下做否则排查起来会分不清问题到底在源还是在输入法配置上。5.2 pacman 常用命令与“指定安装路径”的误解说回到 pacman 本身这个报错引出的其实是 pacman 日常使用的几个常见误区。有人认为pacman -S后面可以直接指定安装路径其实不行。pacman 的包管理方式要求所有文件按打包时的路径安装到系统目录不支持像 Windows 安装包那样选择目录。如果确实想把某个软件装到自定义位置可以用 AUR 的 PKGBUILD 自己修改参数再makepkg打包但维护成本很高不建议新手折腾。顺手整理一下高频命令pacman -Ss 关键词 # 搜索软件包 pacman -S 包名 # 安装软件包 pacman -Si 包名 # 查看软件包详细信息 pacman -Q # 列出已安装的软件包 pacman -Rns 包名 # 卸载软件包并删除配置和依赖 pacman -U /path/pkg.tar.zst # 用本地包文件安装这些命令配合镜像源配置一起看基本能覆盖日常 90% 的包管理场景。最后分享一个我自己的习惯每次遇到这种仓库报错先沉住气把网络、配置、缓存三件事按顺序排查一遍再上手改文件。改/etc/pacman.conf之前一定先备份这样就算折腾坏了也能一键还原。再就是像上文说的在配置里多写几行备用Serverpacman 会自动按顺序重试很多所谓“镜像挂了”的场景根本轮不到你手动介入。这个小习惯帮我省掉了大量重复排障时间也希望这篇内容能帮你少走一次弯路。