CentOS 升级内核总是失败？软件源、依赖冲突、磁盘空间三个坎
“yum update 跑得好好的，偏偏到内核包这一步就报错”——有人换新机器一路顺畅，有人守着老服务器反复失败：要么提示找不到镜像，要么一屏依赖冲突，要么装到一半说磁盘满了。这个困扰从 CentOS 7 时代一直延续到今天，属于典型的"系统越老越难升级"问题。
先说成因。内核包跟普通软件包不是一个量级：它体积大，连带 kernel-devel、kernel-headers、固件包一串依赖；它默认装在独立的 /boot 分区，而早年装机习惯只给 /boot 划两三百兆，旧内核一攒就是三五个；再加上 CentOS 7/8 官方源陆续下线归档，源一失效连包都拉不到。三类故障，对三副药，报错原文就是路标，先归类再动手。
排查按这个顺序走：
- 先分类报错。“Could not resolve host"或镜像 404，是源的问题；“Error: Package conflicts"或 multilib 版本冲突，是依赖的问题；“No space left on device”，是空间的问题。三类走三条排查线，别混着试。
- 源失效的，换源再重建缓存。CentOS 7/8 官方源已迁入 vault 归档库，需要把仓库配置里的地址换成归档地址，然后执行 yum clean all 清掉旧缓存，再执行 yum makecache 重建。能正常拉出包列表，就说明源这关过了。
- 依赖冲突的，别硬装。先执行 yum check 看全局有没有坏包；内核相关的冲突常见于旧版 kernel-devel、kernel-headers 残留与新版错位，把旧版本卸干净再装新内核。跳过依赖强制去装，装出一个起不来的内核，代价更大。
- 空间不足的，先清旧内核。df -h 看 /boot 和根分区余量；旧内核用 package-cleanup –oldkernels –count=2 这类清理命令保留最近两个版本，腾出 /boot 再升级。boot 分区常年只升不清的机器，规划一次空间比每次抠着装省心。
- 至于源码编译安装内核的路线——原提问者就是在"安装模块"这一步失败的——生产环境不建议走：工具链、头文件缺一样都过不去，排错成本远高于收益，留给有特殊定制需求的场景。
升级成功后收个尾：rpm -q kernel 看已安装的内核列表，确认新版本在其中；下次重启才真正切到新内核，重启前顺手确认一下默认引导项。贵州诚鑫致达科技在给企业做系统代维时，升级动作前必过一遍"源、依赖、空间、回退"四项检查，就是为了不让一次例行升级变成一场停机事故。你在内核升级上踩过坑吗？卡在哪一步？评论区说说。这类升级前的检查，企业数据管家巡检时都会替你先过一遍。