前两天帮客户配置一台麒麟KylinV10服务器默认的yum源下载速度慢到让人怀疑人生更麻烦的是很多常用软件在官方源里压根没有只能手动编译或者满网找rpm包。后来我把yum源从官方源整体切到第三方仓库再配了一个本地ISO源做兜底整个环境才算真正能用起来。这篇文章就是把这次换源的全过程、关键配置和踩过的坑完整记录下来给正在被KylinV10源折磨的运维、开发一个可以直接照抄的作业。1. 换源前先摸清家底系统识别与源目录结构很多朋友一上来就照着网上的文章改 /etc/yum.repos.d结果不是404就是依赖崩了根本原因在于KylinV10不是一个“标准”的CentOS它有自己的版本体系和仓库结构x86_64的源和aarch64的源完全是两套东西。动手之前先花两分钟搞清楚三件事系统版本、硬件架构、现有源长什么样。1.1 三步确认系统版本和架构先执行这几条命令cat /etc/os-release cat /etc/kylin-release 2/dev/null uname -m第一条命令输出里能看到Kylin Linux Advanced Server release V10这样的信息注意它到底属于V10的哪个修订版本SP1、SP2还是SP3不同修订版本的仓库路径会有差异。第二条命令有的机器上存在有的不存在不影响判断。第三条命令输出x86_64就是Intel/AMD架构输出aarch64就是ARM架构比如鲲鹏、飞腾的机器这个直接决定你后面baseurl里的架构路径怎么写。接着再看当前仓库状态yum repolist all把默认启用的仓库名字记下来。KylinV10的官方repo文件通常叫kylin_x86_64.repo或kylin_aarch64.repo位于/etc/yum.repos.d/目录下。打开之后能看到baseurl一般指向archive.kylinos.cn之类的官方地址。这就是你接下来要动刀的地方。为什么不厌其烦地强调版本和架构因为yum的baseurl是“协议域名路径”的组合路径里通常包含发行版代号、版本号、架构三层信息任何一个写错都直接404。你在x86机器上抄了一个aarch64的源地址yum repolist可能显示仓库是正常的但一旦真正拉取软件包全都失败。这种问题官方文档很难帮你排查只能靠经验。1.2 搞懂repo文件里每一行的含义随便打开一个repo文件看结构[ks10-adv-os] nameKylin Linux Advanced Server V10 - OS baseurlhttp://archive.kylinos.cn/yum/v10/x86_64/ enabled1 gpgcheck0[ks10-adv-os]是仓库的唯一标识yum repolist显示的就是它name只是给人看的描述信息可随意baseurl是包索引和RPM包的实际下载地址最关键的一行enabled1表示启用enabled0表示保留配置但当前不生效gpgcheck0表示跳过GPG校验1表示要求校验具体看镜像站支持。看完就明白了所谓的换源本质上就是改baseurl或者直接替换整个repo文件。但这里有个很容易被忽略的细节repo文件名的前缀顺序会影响yum的加载顺序如果同时存在多个以base命名的仓库系统会按首字母顺序解析并且同一个软件包出现在多个仓库时会根据baseurl的顺序和包的版本号决定装哪个。所以不要随手创建一堆名字相近的文件后面排查起来很痛苦。动手改之前强烈建议把整个目录完整备份。别嫌这一步多余后面配置混乱导致yum完全无法使用时这是唯一的后悔药。2. 第三方仓库怎么选镜像站对比与兼容性分析2.1 官方源的问题到底出在哪先说结论官方源不是不能用而是适用范围太窄。我实际体验下来主要有三个痛点包数量少。官方源主要覆盖系统基础组件和少量自研软件像subversion、htop、ncdu、iftop这类运维常用工具要么没有要么版本老得离谱。速度不稳定。不同时段访问官方源的延迟波动很大高峰时期几百KB/s是常态。更新节奏慢。很多安全更新和bug修复不会及时同步到仓库里对生产环境来说是个隐患。在初始阶段我其实尝试过“硬扛”结果为了装一个 subversion手动编译了大半天依赖装了一堆最后还被后续yum操作给覆盖掉。这个经历让我彻底决定换源。2.2 主流镜像站横向对比国内靠谱的第三方镜像站我实测下来主要是下面这几家镜像站地址更新频率国内访问速度备注阿里云mirrors.aliyun.com约2小时很快CentOS旧版本已迁至vault/archive清华TUNAmirrors.tuna.tsinghua.edu.cn约4小时快教育网最佳容量大稳定性好中科大USTCmirrors.ustc.edu.cn约4小时快对RHEL系兼容包维护认真网易mirrors.163.com较慢快更新频率不如前几家华为云mirrors.huaweicloud.com约2小时快有云服务器内网地址可用选型逻辑不复杂服务器在哪个云厂商就优先用哪个云厂商的镜像速度最稳如果是自有机房或IDC就选阿里云或清华中科大整体可靠性最高。网易虽然存在很多年但同步频率确实跟不上新装的软件包经常缺胳膊少腿。2.3 兼容性问题别把Kylin当成纯CentOS用这是换源最核心的坑。KylinV10的底层和RHEL 8系生态相似但软件包的依赖关系并不完全一致直接拿CentOS 8的源替换系统base源大概率会出现依赖冲突。我建议的安全做法是保留官方源作为base源不要全部干掉用第三方源补充EPEL、extras这些官方仓库缺失的内容不要同时启用两个不同的base仓库否则相同软件包会产生版本冲突。网上有些教程让你直接搬CentOS源覆盖整个/etc/yum.repos.d/这种操作在测试环境或许能跑通生产环境一旦运行yum update非常容易把关键系统包升级到不兼容的版本导致ssh或内核模块出问题。我在文章后面给出的方案是“官方源保底第三方源扩展本地源应急”三层结构适合绝大多数真实场景。3. 保姆级更换流程备份、写入、清理、验证3.1 先备份任何情况都别跳过在改动任何配置之前先把原有的repo文件归档mkdir -p /etc/yum.repos.d/backup cp -a /etc/yum.repos.d/*.repo /etc/yum.repos.d/backup/ ls -l /etc/yum.repos.d/backup/用cp -a是为了保留文件原有的属主和权限方便回滚的时候直接复制回去。这个目录备份完后续不管你怎么折腾心里都有底。3.2 添加EPEL仓库解决常用软件缺失问题KylinV10的官方源里没有EPEL而很多第三方工具都在EPEL里。先装EPEL的release包。这里要注意KylinV10是基于RHEL 8生态的所以用EPEL 8的包yum install -y https://mirrors.aliyun.com/epel/epel-release-latest-8.noarch.rpm装完确认一下rpm -qa | grep epel-release ls -l /etc/yum.repos.d/epel*.repoEPEL仓库默认启用的只有epel源epel-debuginfo和epel-source是禁用的。如果你想测试更多软件包可以把epel-testing启用但生产环境不建议因为testing仓库里的包稳定性没有保障。3.3 替换官方源里的base仓库路径官方源配置文件里的baseurl可以保留但如果你发现官方源的下载速度确实无法忍受需要把它指向镜像站那么可以选择修改官方repo文件中的baseurl而不是删除整个文件。例如把baseurl改为阿里云的CentOS 8 vault源[ks10-adv-os] nameKylin Linux Advanced Server V10 - OS baseurlhttps://mirrors.aliyun.com/centos-vault/8.5.2111/BaseOS/x86_64/os/ enabled1 gpgcheck0但是注意这个操作风险很高。CentOS 8已经停止常规维护vault里的包如果和麒麟官方源混用依赖关系可能翻车。我更推荐的方式是保留官方源不动把第三方源EPEL作为补充仓库而不是直接改baseurl。如果你确实想换baseurl建议先选一台测试机验证不要直接在线上操作。3.4 清理缓存并重建索引改完配置后执行以下命令顺序yum clean all yum makecache yum repolist allyum clean all会把/var/cache/yum下的缓存清空避免旧元数据干扰yum makecache会重新从各个源拉取元数据并建立缓存。这一步如果报了404或者GPG错误先别急着继续回到上一章排查等yum repolist all里所有源状态都是正常的再说。3.5 先装个小包验证别急着yum update换源之后最忌讳的事情就是直接yum update。正确的验证方式是先安装一个小体积、依赖少的包yum install -y htop yum info subversionhtop在EPEL源里通常有装完直接执行htop看进程列表是否正常说明源链路是通的。yum info subversion是查看subversion在仓库里的可用版本不实际安装验证元数据是否正常。如果这两条命令都成功再进行下一步操作。我的经验是一切顺利的情况下从备份到验证完大约10分钟一旦中途报错可能就是半小时起步的排障过程所以验证环节千万别省。4. 离线环境救星本地ISO源配置实操4.1 什么情况必须用本地源生产环境里经常碰到这些场景内网隔离、没有外网权限、安全等保要求禁止服务器直接访问公网镜像。这时候不管第三方源多快你都用不上唯一的办法就是本地源。本地源有两种主流形态一种是把安装ISO文件挂载到服务器上做成file协议源另一种是运维自己搭建HTTP仓库把RPM包整理好放在Web目录里。对于单机或者小规模环境ISO挂载最简单。4.2 挂载ISO镜像先把ISO文件上传到服务器比如放到/data/iso/下然后执行mkdir -p /mnt/kylin_iso mount -o loop /data/iso/Kylin-Desktop-V10-SP2-x86_64.iso /mnt/kylin_iso df -h /mnt/kylin_iso用mount -o loop是直接把ISO文件当作块设备挂载不需要额外刻盘。挂载成功后在/mnt/kylin_iso下应该能看到 packges 目录。如果ISO是服务端版本目录结构会稍有不同但核心路径都是自带Packages目录。这里有个细节有些服务器重启之后挂载会丢失所以如果想长期使用建议把它写进/etc/fstab/data/iso/Kylin-Desktop-V10-SP2-x86_64.iso /mnt/kylin_iso iso9660 loop,defaults 0 0写入fstab之前先用umount /mnt/kylin_iso取消挂载再执行mount -a看是否能自动挂载成功避免写错导致开机异常。4.3 写一个本地repo文件挂载完成后创建本地repo配置[local-kylin-iso] nameKylin V10 Local ISO baseurlfile:///mnt/kylin_iso enabled1 gpgcheck0注意baseurl用的是file://协议后面跟上挂载点绝对路径。gpgcheck0是为了省去本地ISO签名校验的麻烦如果你对安全要求高可以把官方公钥导入之后设置成1但单机环境里0更省事也不影响安装结果。写完配置后同样执行yum clean all yum makecache yum repolist all然后随便从ISO里装一个包比如yum install -y vim-enhanced确认本地源能正常工作。我实测下来ISO源在离线内网里装系统基础组件的体验最舒服速度是SSD级别的比外网源稳定得多。4.4 本地源和网络源的优先级处理如果你同时配置了本地ISO源和网络源你就会发现yum有时候会从网络源装包有时候从本地源装行为看起来“随机”。其实yum的规则是在包版本相同的情况下仓库的字母顺序优先或者说先出现的仓库优先。要想让本地源优先可以用yum-plugin-priorities插件yum install -y yum-plugin-priorities然后在repo文件里加上priority参数数字越小优先级越高[local-kylin-iso] nameKylin V10 Local ISO baseurlfile:///mnt/kylin_iso enabled1 gpgcheck0 priority1 [ks10-adv-os] nameKylin Linux Advanced Server V10 - OS baseurlhttp://archive.kylinos.cn/yum/v10/x86_64/ enabled1 gpgcheck0 priority10这样yum会优先从本地ISO源解析包本地没有的才去官方源找。这个配置在同时使用多个源的时候极其有用特别是混合源环境下能避免很多“装出来版本不对”的问题。5. 换源后的常见翻车现场与排查链路5.1 404错误路径写错是头号杀手报错特征http://mirrors.example.com/centos/8/BaseOS/x86_64/os/repodata/repomd.xml: [Errno 14] HTTP Error 404 - Not Found这个报错几乎都是baseurl路径和实际镜像目录结构不匹配造成的。排查链路很固定先手动访问一下这个URL用curl看服务器返回什么curl -I https://mirrors.aliyun.com/centos-vault/8.5.2111/BaseOS/x86_64/os/repodata/repomd.xml如果返回404说明路径里有不存在的层级。常见原因有三个版本号写错比如系统是V10 SP1却写成了SP2、架构写错x86_64当成aarch64、目录结构理解错混淆了BaseOS和AppStream。逐个核对基本能解决。5.2 GPG签名校验失败报错特征warning: rpmts_HdrFromFdno: Header V4 RSA/SHA256 Signature, key ID xxxxx: NOKEY说明repo文件里gpgcheck1但本机没有导入对应公钥。解决办法有两种导入仓库公钥rpm --import /etc/pki/rpm-gpg/RPM-GPG-KEY-XXX公钥文件一般在你下载的release包或镜像站根目录里能找到。如果只是临时测试可以把该repo文件里的gpgcheck改成0。我建议正式环境优先用方案1安全校验别随便关。5.3 元数据错误仓库显示“镜像同步中”报错特征One of the configured repositories failed (xxx) and yum doesnt have enough cached data to continue.大概率是访问的镜像站正在做文件同步或者本地缓存损坏。先把缓存清掉重建yum clean all rm -rf /var/cache/yum yum makecache如果重建之后还是同一个源报错那就换一个镜像站地址别在同一个源上死磕。有些镜像站同步窗口确实会持续比较久等半小时不如换源来得快。5.4 装subversion这类软件时的依赖告警装subversion时容易遇到EPEL源和官方源里libserf、apr版本不一致导致的依赖冲突。报错里会出现类似Package xxx requires yyy x.x, but none of the providers can be installed的提示。我的处理思路是先别急着禁用某个源先用yum deplist subversion看它到底依赖哪些库、哪个源能提供。如果依赖来自官方源就保留官方源如果依赖来自EPEL就确认EPEL启用状态正常。两条路都不通的情况下再考虑手动编译或者用低版本。比如我之前在KylinV10 SP2上装subversionEPEL里提供的1.14版本依赖libserf-1-1.so.1而官方源里对应的库版本偏老最后通过启用EPEL的Testing仓库才解决。少走弯路的办法是先查清依赖来源而不是盲目开关源。5.5 代理和防火墙导致的连接超时如果网络源装包时卡住报错为Could not resolve host或者长时间Cannot retrieve metalink for repository先自查两件事确认网络连通性curl -I https://mirrors.aliyun.com/能否正常返回如果服务器需要走代理给yum单独配代理vi /etc/yum.conf # 在文件里加 proxyhttp://proxy.example.com:8080内网环境经常会遇到“ping得通但yum连不上”的问题本质是HTTP协议被防火墙拦了走代理是常规解法。如果代理地址也需要认证就加上proxy_username和proxy_password两行。5.6 最隐蔽的一类问题同名包版本漂移有时候yum install时报错Package does not match intended download这是因为同一个软件包在两个源里的版本相同但RPM的完整版本号或构建号不一致yum拿到的元数据和实际文件对不上。处理方式是把两个源里冗余的其中一个临时禁用装完再启用yum install --disablerepoks10-adv-os --enablerepoepel subversion这条命令能绕开版本漂移的报错。这个技巧在混合源环境里非常实用算是排查这类问题最省事的手段。最后再说一个个人习惯我每次换完源都会顺手把/etc/yum.repos.d/backup/这个备份目录保留至少三个月并且把常用的 repo 文件命名整理得干净利落比如kylin-iso.repo、epel.repo、aliyun-base.repo这种一目了然的名字。运维这件事很多坑都不是技术难度大而是环境状态混乱导致排查成本飙升。源配置看起来是小事但一旦出错直接影响所有软件安装值得多花几分钟把它做规范。
麒麟V10系统yum源更换实战：从官方源到EPEL与本地ISO源配置指南
前两天帮客户配置一台麒麟KylinV10服务器默认的yum源下载速度慢到让人怀疑人生更麻烦的是很多常用软件在官方源里压根没有只能手动编译或者满网找rpm包。后来我把yum源从官方源整体切到第三方仓库再配了一个本地ISO源做兜底整个环境才算真正能用起来。这篇文章就是把这次换源的全过程、关键配置和踩过的坑完整记录下来给正在被KylinV10源折磨的运维、开发一个可以直接照抄的作业。1. 换源前先摸清家底系统识别与源目录结构很多朋友一上来就照着网上的文章改 /etc/yum.repos.d结果不是404就是依赖崩了根本原因在于KylinV10不是一个“标准”的CentOS它有自己的版本体系和仓库结构x86_64的源和aarch64的源完全是两套东西。动手之前先花两分钟搞清楚三件事系统版本、硬件架构、现有源长什么样。1.1 三步确认系统版本和架构先执行这几条命令cat /etc/os-release cat /etc/kylin-release 2/dev/null uname -m第一条命令输出里能看到Kylin Linux Advanced Server release V10这样的信息注意它到底属于V10的哪个修订版本SP1、SP2还是SP3不同修订版本的仓库路径会有差异。第二条命令有的机器上存在有的不存在不影响判断。第三条命令输出x86_64就是Intel/AMD架构输出aarch64就是ARM架构比如鲲鹏、飞腾的机器这个直接决定你后面baseurl里的架构路径怎么写。接着再看当前仓库状态yum repolist all把默认启用的仓库名字记下来。KylinV10的官方repo文件通常叫kylin_x86_64.repo或kylin_aarch64.repo位于/etc/yum.repos.d/目录下。打开之后能看到baseurl一般指向archive.kylinos.cn之类的官方地址。这就是你接下来要动刀的地方。为什么不厌其烦地强调版本和架构因为yum的baseurl是“协议域名路径”的组合路径里通常包含发行版代号、版本号、架构三层信息任何一个写错都直接404。你在x86机器上抄了一个aarch64的源地址yum repolist可能显示仓库是正常的但一旦真正拉取软件包全都失败。这种问题官方文档很难帮你排查只能靠经验。1.2 搞懂repo文件里每一行的含义随便打开一个repo文件看结构[ks10-adv-os] nameKylin Linux Advanced Server V10 - OS baseurlhttp://archive.kylinos.cn/yum/v10/x86_64/ enabled1 gpgcheck0[ks10-adv-os]是仓库的唯一标识yum repolist显示的就是它name只是给人看的描述信息可随意baseurl是包索引和RPM包的实际下载地址最关键的一行enabled1表示启用enabled0表示保留配置但当前不生效gpgcheck0表示跳过GPG校验1表示要求校验具体看镜像站支持。看完就明白了所谓的换源本质上就是改baseurl或者直接替换整个repo文件。但这里有个很容易被忽略的细节repo文件名的前缀顺序会影响yum的加载顺序如果同时存在多个以base命名的仓库系统会按首字母顺序解析并且同一个软件包出现在多个仓库时会根据baseurl的顺序和包的版本号决定装哪个。所以不要随手创建一堆名字相近的文件后面排查起来很痛苦。动手改之前强烈建议把整个目录完整备份。别嫌这一步多余后面配置混乱导致yum完全无法使用时这是唯一的后悔药。2. 第三方仓库怎么选镜像站对比与兼容性分析2.1 官方源的问题到底出在哪先说结论官方源不是不能用而是适用范围太窄。我实际体验下来主要有三个痛点包数量少。官方源主要覆盖系统基础组件和少量自研软件像subversion、htop、ncdu、iftop这类运维常用工具要么没有要么版本老得离谱。速度不稳定。不同时段访问官方源的延迟波动很大高峰时期几百KB/s是常态。更新节奏慢。很多安全更新和bug修复不会及时同步到仓库里对生产环境来说是个隐患。在初始阶段我其实尝试过“硬扛”结果为了装一个 subversion手动编译了大半天依赖装了一堆最后还被后续yum操作给覆盖掉。这个经历让我彻底决定换源。2.2 主流镜像站横向对比国内靠谱的第三方镜像站我实测下来主要是下面这几家镜像站地址更新频率国内访问速度备注阿里云mirrors.aliyun.com约2小时很快CentOS旧版本已迁至vault/archive清华TUNAmirrors.tuna.tsinghua.edu.cn约4小时快教育网最佳容量大稳定性好中科大USTCmirrors.ustc.edu.cn约4小时快对RHEL系兼容包维护认真网易mirrors.163.com较慢快更新频率不如前几家华为云mirrors.huaweicloud.com约2小时快有云服务器内网地址可用选型逻辑不复杂服务器在哪个云厂商就优先用哪个云厂商的镜像速度最稳如果是自有机房或IDC就选阿里云或清华中科大整体可靠性最高。网易虽然存在很多年但同步频率确实跟不上新装的软件包经常缺胳膊少腿。2.3 兼容性问题别把Kylin当成纯CentOS用这是换源最核心的坑。KylinV10的底层和RHEL 8系生态相似但软件包的依赖关系并不完全一致直接拿CentOS 8的源替换系统base源大概率会出现依赖冲突。我建议的安全做法是保留官方源作为base源不要全部干掉用第三方源补充EPEL、extras这些官方仓库缺失的内容不要同时启用两个不同的base仓库否则相同软件包会产生版本冲突。网上有些教程让你直接搬CentOS源覆盖整个/etc/yum.repos.d/这种操作在测试环境或许能跑通生产环境一旦运行yum update非常容易把关键系统包升级到不兼容的版本导致ssh或内核模块出问题。我在文章后面给出的方案是“官方源保底第三方源扩展本地源应急”三层结构适合绝大多数真实场景。3. 保姆级更换流程备份、写入、清理、验证3.1 先备份任何情况都别跳过在改动任何配置之前先把原有的repo文件归档mkdir -p /etc/yum.repos.d/backup cp -a /etc/yum.repos.d/*.repo /etc/yum.repos.d/backup/ ls -l /etc/yum.repos.d/backup/用cp -a是为了保留文件原有的属主和权限方便回滚的时候直接复制回去。这个目录备份完后续不管你怎么折腾心里都有底。3.2 添加EPEL仓库解决常用软件缺失问题KylinV10的官方源里没有EPEL而很多第三方工具都在EPEL里。先装EPEL的release包。这里要注意KylinV10是基于RHEL 8生态的所以用EPEL 8的包yum install -y https://mirrors.aliyun.com/epel/epel-release-latest-8.noarch.rpm装完确认一下rpm -qa | grep epel-release ls -l /etc/yum.repos.d/epel*.repoEPEL仓库默认启用的只有epel源epel-debuginfo和epel-source是禁用的。如果你想测试更多软件包可以把epel-testing启用但生产环境不建议因为testing仓库里的包稳定性没有保障。3.3 替换官方源里的base仓库路径官方源配置文件里的baseurl可以保留但如果你发现官方源的下载速度确实无法忍受需要把它指向镜像站那么可以选择修改官方repo文件中的baseurl而不是删除整个文件。例如把baseurl改为阿里云的CentOS 8 vault源[ks10-adv-os] nameKylin Linux Advanced Server V10 - OS baseurlhttps://mirrors.aliyun.com/centos-vault/8.5.2111/BaseOS/x86_64/os/ enabled1 gpgcheck0但是注意这个操作风险很高。CentOS 8已经停止常规维护vault里的包如果和麒麟官方源混用依赖关系可能翻车。我更推荐的方式是保留官方源不动把第三方源EPEL作为补充仓库而不是直接改baseurl。如果你确实想换baseurl建议先选一台测试机验证不要直接在线上操作。3.4 清理缓存并重建索引改完配置后执行以下命令顺序yum clean all yum makecache yum repolist allyum clean all会把/var/cache/yum下的缓存清空避免旧元数据干扰yum makecache会重新从各个源拉取元数据并建立缓存。这一步如果报了404或者GPG错误先别急着继续回到上一章排查等yum repolist all里所有源状态都是正常的再说。3.5 先装个小包验证别急着yum update换源之后最忌讳的事情就是直接yum update。正确的验证方式是先安装一个小体积、依赖少的包yum install -y htop yum info subversionhtop在EPEL源里通常有装完直接执行htop看进程列表是否正常说明源链路是通的。yum info subversion是查看subversion在仓库里的可用版本不实际安装验证元数据是否正常。如果这两条命令都成功再进行下一步操作。我的经验是一切顺利的情况下从备份到验证完大约10分钟一旦中途报错可能就是半小时起步的排障过程所以验证环节千万别省。4. 离线环境救星本地ISO源配置实操4.1 什么情况必须用本地源生产环境里经常碰到这些场景内网隔离、没有外网权限、安全等保要求禁止服务器直接访问公网镜像。这时候不管第三方源多快你都用不上唯一的办法就是本地源。本地源有两种主流形态一种是把安装ISO文件挂载到服务器上做成file协议源另一种是运维自己搭建HTTP仓库把RPM包整理好放在Web目录里。对于单机或者小规模环境ISO挂载最简单。4.2 挂载ISO镜像先把ISO文件上传到服务器比如放到/data/iso/下然后执行mkdir -p /mnt/kylin_iso mount -o loop /data/iso/Kylin-Desktop-V10-SP2-x86_64.iso /mnt/kylin_iso df -h /mnt/kylin_iso用mount -o loop是直接把ISO文件当作块设备挂载不需要额外刻盘。挂载成功后在/mnt/kylin_iso下应该能看到 packges 目录。如果ISO是服务端版本目录结构会稍有不同但核心路径都是自带Packages目录。这里有个细节有些服务器重启之后挂载会丢失所以如果想长期使用建议把它写进/etc/fstab/data/iso/Kylin-Desktop-V10-SP2-x86_64.iso /mnt/kylin_iso iso9660 loop,defaults 0 0写入fstab之前先用umount /mnt/kylin_iso取消挂载再执行mount -a看是否能自动挂载成功避免写错导致开机异常。4.3 写一个本地repo文件挂载完成后创建本地repo配置[local-kylin-iso] nameKylin V10 Local ISO baseurlfile:///mnt/kylin_iso enabled1 gpgcheck0注意baseurl用的是file://协议后面跟上挂载点绝对路径。gpgcheck0是为了省去本地ISO签名校验的麻烦如果你对安全要求高可以把官方公钥导入之后设置成1但单机环境里0更省事也不影响安装结果。写完配置后同样执行yum clean all yum makecache yum repolist all然后随便从ISO里装一个包比如yum install -y vim-enhanced确认本地源能正常工作。我实测下来ISO源在离线内网里装系统基础组件的体验最舒服速度是SSD级别的比外网源稳定得多。4.4 本地源和网络源的优先级处理如果你同时配置了本地ISO源和网络源你就会发现yum有时候会从网络源装包有时候从本地源装行为看起来“随机”。其实yum的规则是在包版本相同的情况下仓库的字母顺序优先或者说先出现的仓库优先。要想让本地源优先可以用yum-plugin-priorities插件yum install -y yum-plugin-priorities然后在repo文件里加上priority参数数字越小优先级越高[local-kylin-iso] nameKylin V10 Local ISO baseurlfile:///mnt/kylin_iso enabled1 gpgcheck0 priority1 [ks10-adv-os] nameKylin Linux Advanced Server V10 - OS baseurlhttp://archive.kylinos.cn/yum/v10/x86_64/ enabled1 gpgcheck0 priority10这样yum会优先从本地ISO源解析包本地没有的才去官方源找。这个配置在同时使用多个源的时候极其有用特别是混合源环境下能避免很多“装出来版本不对”的问题。5. 换源后的常见翻车现场与排查链路5.1 404错误路径写错是头号杀手报错特征http://mirrors.example.com/centos/8/BaseOS/x86_64/os/repodata/repomd.xml: [Errno 14] HTTP Error 404 - Not Found这个报错几乎都是baseurl路径和实际镜像目录结构不匹配造成的。排查链路很固定先手动访问一下这个URL用curl看服务器返回什么curl -I https://mirrors.aliyun.com/centos-vault/8.5.2111/BaseOS/x86_64/os/repodata/repomd.xml如果返回404说明路径里有不存在的层级。常见原因有三个版本号写错比如系统是V10 SP1却写成了SP2、架构写错x86_64当成aarch64、目录结构理解错混淆了BaseOS和AppStream。逐个核对基本能解决。5.2 GPG签名校验失败报错特征warning: rpmts_HdrFromFdno: Header V4 RSA/SHA256 Signature, key ID xxxxx: NOKEY说明repo文件里gpgcheck1但本机没有导入对应公钥。解决办法有两种导入仓库公钥rpm --import /etc/pki/rpm-gpg/RPM-GPG-KEY-XXX公钥文件一般在你下载的release包或镜像站根目录里能找到。如果只是临时测试可以把该repo文件里的gpgcheck改成0。我建议正式环境优先用方案1安全校验别随便关。5.3 元数据错误仓库显示“镜像同步中”报错特征One of the configured repositories failed (xxx) and yum doesnt have enough cached data to continue.大概率是访问的镜像站正在做文件同步或者本地缓存损坏。先把缓存清掉重建yum clean all rm -rf /var/cache/yum yum makecache如果重建之后还是同一个源报错那就换一个镜像站地址别在同一个源上死磕。有些镜像站同步窗口确实会持续比较久等半小时不如换源来得快。5.4 装subversion这类软件时的依赖告警装subversion时容易遇到EPEL源和官方源里libserf、apr版本不一致导致的依赖冲突。报错里会出现类似Package xxx requires yyy x.x, but none of the providers can be installed的提示。我的处理思路是先别急着禁用某个源先用yum deplist subversion看它到底依赖哪些库、哪个源能提供。如果依赖来自官方源就保留官方源如果依赖来自EPEL就确认EPEL启用状态正常。两条路都不通的情况下再考虑手动编译或者用低版本。比如我之前在KylinV10 SP2上装subversionEPEL里提供的1.14版本依赖libserf-1-1.so.1而官方源里对应的库版本偏老最后通过启用EPEL的Testing仓库才解决。少走弯路的办法是先查清依赖来源而不是盲目开关源。5.5 代理和防火墙导致的连接超时如果网络源装包时卡住报错为Could not resolve host或者长时间Cannot retrieve metalink for repository先自查两件事确认网络连通性curl -I https://mirrors.aliyun.com/能否正常返回如果服务器需要走代理给yum单独配代理vi /etc/yum.conf # 在文件里加 proxyhttp://proxy.example.com:8080内网环境经常会遇到“ping得通但yum连不上”的问题本质是HTTP协议被防火墙拦了走代理是常规解法。如果代理地址也需要认证就加上proxy_username和proxy_password两行。5.6 最隐蔽的一类问题同名包版本漂移有时候yum install时报错Package does not match intended download这是因为同一个软件包在两个源里的版本相同但RPM的完整版本号或构建号不一致yum拿到的元数据和实际文件对不上。处理方式是把两个源里冗余的其中一个临时禁用装完再启用yum install --disablerepoks10-adv-os --enablerepoepel subversion这条命令能绕开版本漂移的报错。这个技巧在混合源环境里非常实用算是排查这类问题最省事的手段。最后再说一个个人习惯我每次换完源都会顺手把/etc/yum.repos.d/backup/这个备份目录保留至少三个月并且把常用的 repo 文件命名整理得干净利落比如kylin-iso.repo、epel.repo、aliyun-base.repo这种一目了然的名字。运维这件事很多坑都不是技术难度大而是环境状态混乱导致排查成本飙升。源配置看起来是小事但一旦出错直接影响所有软件安装值得多花几分钟把它做规范。
