RHEL 8/CentOS 8 升级配置本地 YUM 源后找不到包？一个参数 module_hotfixes=1 完美解决
最近在维护一台 RHEL 8（红帽 8）服务器时，遇到了一件非常 “玄学” 的事情。由于生产环境无法连接外网，我需要离线升级系统内核。按照以往在 CentOS 7 上的老经验，我把 RPM 包下载好，传到服务器，配置了一个本地的
.repo 文件，本以为能一气呵成，结果却卡在了第一步。无论我怎么执行
yum clean all 和 yum makecache，当我使用 yum list 或者尝试安装内核时，系统始终提示 “找不到包”，甚至我的本地仓库里显示的可用包数量一直是 0。明明 RPM 包就在那里，路径也没写错，为什么 YUM 就是 “视而不见” 呢？
一、问题复盘：消失的内核包
我的操作步骤非常标准：
- 将内核 RPM 包上传到服务器的
/opt/RHEL8-update-pkg/目录。 - 在
/etc/yum.repos.d/下新建update.repo，内容如下：
[rhel8-update]
name=RHEL8 update kernel
baseurl=file:///opt/RHEL8-update-pkg/
enabled=1
gpgcheck=0- 执行缓存清理与重建：
yum clean all
yum makecache
然而，当我执行
yum list | grep kernel 时，却找不到我刚刚放进去的内核包。通过 yum repolist 查看，虽然仓库被识别了，但包的数量却显示异常。二、追根溯源：为什么 RHEL 8 会 “过滤” 你的包？
经过一番排查和查阅官方文档，我终于找到了罪魁祸首 ——RHEL 8 引入的模块化（Modularity）机制。
在 CentOS 7 时代，YUM 仓库是非模块化的，只要目录里有 RPM 包且生成了 repodata，YUM 就能识别。但在 RHEL 8 / CentOS 8 及以后的版本中，系统引入了 AppStream 仓库和模块化概念（DNF 包管理器）。
核心冲突点
RHEL 8 的 DNF 默认会启用模块化过滤（Modular Filtering）。当系统检测到一个仓库时，它会优先尝试去匹配模块流（Module Streams）。如果你创建的本地仓库只有传统的 RPM 包，而没有生成复杂的模块化元数据文件（
modules.yaml），DNF 就会认为这些包 “不符合模块化规范”，从而在依赖解析阶段自动将它们过滤掉。简单来说：系统并不是没看到你的包，而是觉得你的包 “没有模块身份证”，直接把它们隐藏了。
三、终极解决方案：module_hotfixes=1
既然知道了原因，解决起来就非常简单。我们不需要去费力生成复杂的模块化元数据，只需要告诉 DNF：“这个仓库里的包是特殊的，请忽略模块化过滤规则，直接把它们当成普通包处理。”
实现这个目的的参数就是：
module_hotfixes=1。修改后的
.repo 配置文件：[rhel8-update]
name=RHEL8 update kernel
baseurl=file:///opt/RHEL8-update-pkg/
enabled=1
gpgcheck=0
module_hotfixes=1 # 关键参数：禁用模块化过滤
参数原理解析
module_hotfixes=1 的作用是告诉 DNF 客户端，该仓库中的软件包不受模块化依赖规则的约束。启用后，DNF 会跳过对该仓库的模块流检查，直接暴露仓库中所有的传统 RPM 包，就像在旧版本的系统中一样。四、验证与生效
修改完配置文件后，再次清理并重建缓存，让新配置生效：
# 1. 清理旧缓存
yum clean all
# 2. 重建元数据缓存
yum makecache
# 3. 再次尝试查找内核包
yum list | grep kernel
这一次，你会发现熟悉的内核 RPM 包终于出现在列表里了！接下来就可以正常执行
yum update kernel 进行离线升级了。五、总结
在 RHEL 8 / CentOS 8 及以上版本配置本地 YUM 源时，如果你发现自己上传的传统 RPM 包始终无法被识别，不要怀疑人生，大概率是模块化机制在作祟。
- 现象：本地源配置正确，但
yum list找不到包，仓库包数量为 0。 - 原因：DNF 默认的模块化过滤规则隐藏了没有模块元数据的传统 RPM 包。
- 解决：在
.repo文件中添加module_hotfixes=1。
希望这篇避坑指南能帮到正在折腾 RHEL 8 离线环境的你！
阅读剩余
本站代码模板仅供学习交流使用请勿商业运营，严禁从事违法，侵权等任何非法活动，否则后果自负！
THE END
