openEuler 仓库故障排障
This content is not available in your language yet.
包管理器报错的信息量很大,按顺序读:先分清「仓库没配对」「元数据坏了」还是「签名/镜像问题」,修法完全不同。
第一步:核对与重建缓存
Section titled “第一步:核对与重建缓存”先核对可见仓库并重建本地缓存——dnf repolist 列出已启用仓库,dnf clean all 与 dnf makecache 清掉并重建元数据缓存:
dnf repolistsudo dnf clean allsudo dnf makecache一半以上的「下载失败/元数据错误」到这一步就结束了;仓库列表里缺仓库或指向了错误版本线,先改仓库配置再重试。
元数据与签名的基准
Section titled “元数据与签名的基准”everything 仓库目录含 repodata 元数据与 RPM-GPG-KEY-openEuler 公钥文件——仓库元数据与签名问题的核对都以这两项为基准:报「公钥不可用/GPG 校验失败」时核对导入的密钥与仓库官方公钥一致,不要用跳过签名的方式绕过。
官方仓库站点说明其全球镜像分布并指引通过官方镜像列表选择站点;历史版本另有 archives 站点——单个镜像故障时换一个镜像或走官方镜像列表重新就近分配,比反复重试同一个源有效。国内镜像的改法见下载与校验。
内网机器的仓库报错九成源于「镜像不同步或版本线混用」:核对本地镜像的版本目录与系统一致(不要跨版本线混搭 update 与 OS 仓库,见仓库结构),仓库树完整后以本地路径指向验证可达性。
版本线混用的典型症状
Section titled “版本线混用的典型症状”症状是「依赖冲突/找不到提供者」,根因常是仓库跨线混用或 EPOL 与基线不配套。修法是收敛仓库配置到单一版本线,再按需启用扩展层——排错顺序仍从上一节的仓库清单核对开始。