CentOS 7离线手动升级内核全流程：从3.10到5.x的版本选型与避坑指南

最近在帮一台生产服务器做内核升级环境比较特殊CentOS 7.9.2009纯内网环境不连外网不能挂代理没有本地 yum 源一切都得手动来。折腾了一整天踩了几个坑最后顺利从 3.10 内核升到了 5.x。写这篇文章把整个离线手动升级流程、版本选型思路、依赖处理方法和坑位排查经验完整记录下来给同样被困在内网机房里的兄弟们一块垫脚石。先交代一下背景这台机器装的是 CentOS 7.9.2009也就是 7 系列最后一个版本内核停在 3.10.0-1160这是 RHEL/CentOS 7 的老传统——内核版本极度保守。为什么非升不可因为要在这台机器上跑一套新的容器调度平台3.10 内核在 cgroup v2、网络命名空间、overlayfs 的稳定性上确实有点跟不上加上新硬件的驱动也要新内核支持。所以升级内核不是赶时髦而是业务驱动。整个过程可以分成四大块版本选型与准备工作、离线安装包的获取与校验、核心升级操作含 GRUB2 调整、升级后的验证与问题排查。下面按这个顺序展开。1. 离线升级前的版本选型与准备工作1.1 为什么要先想清楚升到哪个版本很多人一上来就yum update或者随便找一个内核 rpm 就往系统里装这在离线环境下是很容易翻车的。离线环境跟在线环境最大的区别是装错了或者装到一半缺依赖你是没法临时再拉包的。每一步都得提前想清楚。内核选型主要考虑三个因素第一业务兼容性。如果你的机器是普通 web 服务器、数据库服务器不需要太激进的内核特性那选长期支持版本更稳。如果是要跑 Docker/K8s或者上新的存储方案那就得选相对新、功能全的内核分支。第二硬件驱动支持。新内核对新网卡、新 RAID 卡、NVMe 设备的支持肯定更好但反过来如果你的机器是老旧服务器某些厂商的闭源驱动跟不上新内核版本升完内核网卡反而掉线。这个一定要先在测试环境验证。第三虚拟化环境特殊要求。比如跑在云平台、虚拟化平台上的机器升级内核后必须确认虚拟化相关驱动比如 virtio 系列正常加载不然重启直接失联。以我这次为例业务上需要稳定优先同时又要支持容器特性所以我选了长期支持版本系列对应 ELRepo 的 kernel-lt而不是最新主线版本kernel-ml。主线和 LT 差异很大主线版本更新、功能激进但生命周期短可能几周就更新一个版本LT 版本更稳、维护周期长适合生产环境长期跑。注意CentOS 7 默认仓库里的内核是不升级的需要用第三方仓库如 ELRepo提供的内核包。离线环境下就先把 rpm 包准备好再说。1.2 查当前内核版本和系统发行版信息在动手之前先把底细摸清楚执行下面几条命令cat /etc/centos-release uname -r uname -m我的环境输出是CentOS Linux release 7.9.2009 (Core) 3.10.0-1160.el7.x86_64 x86_64这三个信息缺一不可系统大版本决定 rpm 包要选 el7 的当前内核版本用于升级前后对比架构确定你下载 x86_64 还是 aarch64 的包。另外建议同步检查一下/boot分区空间df -h /boot内核 rpm 安装时会往 /boot 写入 vmlinuz、initramfs 等文件每个内核大约占 30~60MB。如果 /boot 空间太小多个内核并存会直接撑爆分区这也是老 CentOS 7 机器很容易踩的雷。1.3 确认升级目标与回滚策略在离线环境下建议采用“保留旧内核、新增新内核”的策略不要先卸载旧内核再装新的。这样就算新内核启动失败重启后还能从 GRUB 菜单里选回旧内核安全兜底。我在实际操作中对 /boot 里的内核文件做了一个完整的备份清单ls -l /boot/vmlinuz-* ls -l /boot/initramfs-*并确认当前使用的内核模块目录存在ls /lib/modules/3.10.0-1160.el7.x86_64/这一步看似多余但在后面删旧内核时非常有用至少知道原始环境长什么样。2. 离线安装包的获取与完整性校验2.1 在联网机器上下载全部内核 rpm 包离线环境不是没有电脑而是服务器不能联网。我们可以找一台能联网的同架构机器比如办公电脑、跳板机先把调和好依赖的内核 rpm 包全部下载下来再拷贝到内网服务器上安装。这里推荐用 yumdownloader 的--resolve参数它会把指定包及其所有依赖一次性拉下来。命令如下在联网机器上执行# 先安装 yum-utils yum install -y yum-utils # 启用 ELRepo 源 rpm --import https://www.elrepo.org/RPM-GPG-KEY-elrepo.org rpm -Uvh https://www.elrepo.org/elrepo-release-7.0-4.el7.elrepo.noarch.rpm # 下载 kernel-lt 及其所有依赖到指定目录 mkdir -p /data/kernel-rpms cd /data/kernel-rpms yumdownloader --resolve kernel-lt kernel-lt-devel kernel-lt-headers这里有个细节kernel-lt-devel是内核头文件和开发包如果你只是单纯跑步业务其实可以不装但后面如果要编译第三方内核模块比如某个网卡驱动、安全 agent 的 kernel module就必须装。我这次装了防止后续临时要用却没有包。如果你选择主线版本把包名换成 kernel-ml 就行yumdownloader --resolve kernel-ml kernel-ml-devel kernel-ml-headers下载完成后检查目录内容ls -lh /data/kernel-rpms/正常会看到类似这样的文件kernel-lt-5.4.275-1.el7.elrepo.x86_64.rpm kernel-lt-devel-5.4.275-1.el7.elrepo.x86_64.rpm kernel-lt-headers-5.4.275-1.el7.elrepo.x86_64.rpm如果某些依赖需要单独补比如 abrt、dracut 版本太老yumdownloader 也会一并拉下来这一步不要跳过--resolve。2.2 校验包完整性与签名把 rpm 包传到内网机器之前建议至少做一次完整性校验。在联网机器上还没装包之前可以用 rpm 命令检查签名cd /data/kernel-rpms rpm -K *.rpm理论上每个包会显示digests signatures OK如果以前导入过 ELRepo 的公钥签名校验会直接通过如果显示MISSING KEY那只是没导入公钥不影响包本身完整性但建议先在联网机器上导入公钥再校验避免内网机器上缺少信任链导致后续安装异常。对于纯离线环境内网机器上一般也不会有 ELRepo 公钥那安装时加上--nogpgcheck即可rpm -Uvh --nogpgcheck kernel-lt-*.rpm这个参数在离线装内核时非常常用内部系统不要求强制验签的情况下基本都会用到。但要注意如果你们内部对 rpm 审计有强制要求还是要提前把 GPG 公钥文件一并拷贝进去统一管理不能直接跳过。2.3 上传到内网机器这一步用 U 盘、内网共享目录或者直接scp都行但要注意路径尽量简单。我放到/root/kernel-upgrade/下scp /data/kernel-rpms/*.rpm root内网机器IP:/root/kernel-upgrade/到内网机器上确认文件完整cd /root/kernel-upgrade/ ls -lh *.rpm对比一下文件大小跟联网机器上一致就说明传输没丢数据。有条件的话再跑一遍 md5sum 比对更稳妥。3. 离线安装内核与 GRUB2 调整实操3.1 安装前的最后检查内网机器上先做一次试安装检测依赖这一步非常重要。rpm 提供了--test参数可以预演安装过程而不真正写入系统cd /root/kernel-upgrade/ rpm -Uvh --test --nogpgcheck kernel-lt-*.rpm如果输出类似error: Failed dependencies: xxx is needed by kernel-lt-5.4.275-1.el7.x86_64那就说明还有依赖没补齐。这时候去联网机器上把缺失的依赖包也拉下来再传上来。这一步在离线环境下务必执行不要为了省事跳过不然装到一半报错再补包麻烦的是自己。正常情况--test会安静通过没有输出或者只显示准备信息。这时候才能开始正式安装。3.2 执行内核安装正式安装命令cd /root/kernel-upgrade/ rpm -Uvh --nogpgcheck kernel-lt-*.rpm这里用-Uupgrade而不是-iinstall因为在有旧内核的情况下-U会保留旧内核的同时安装新内核并自动生成新内核的 initramfs。观察输出关键部分是Installing: kernel-lt-5.4.275-1.el7.x86_64 ... Generating grub configuration file ... ... Installing: kernel-lt-devel-5.4.275-1.el7.x86_64 kernel-lt-headers-5.4.275-1.el7.x86_64看到 “Generating grub configuration file” 说明安装脚本已经自动执行了 grub2-mkconfig。但装完不要高兴太早还要手动确认默认引导项是否指向了新内核。安装完成后验证 /boot 目录ls -l /boot/vmlinuz-*正常情况下会同时存在老内核3.10.0-1160和新内核5.4.275两个内核文件都在说明回滚能力还保留着。3.3 调整 GRUB2 默认启动项CentOS 7 使用 GRUB2 引导默认启动项由/boot/grub2/grubenv文件控制。新内核安装后默认项未必是新内核必须手动检查设置。查看当前菜单中所有内核条目grep menuentry /boot/grub2/grub.cfg输出示例menuentry CentOS Linux (5.4.275-1.el7.x86_64) 7 (Core) --class centos ... menuentry CentOS Linux (3.10.0-1160.el7.x86_64) 7 (Core) --class centos ... menuentry CentOS Linux (0-rescue-...) 7 (Core) --class centos ...新内核的菜单条目默认会排在第一位因为 rpm 安装脚本生成 grub.cfg 时把最新的放最前但为了保险还是手动执行grub2-set-default 0 grub2-mkconfig -o /boot/grub2/grub.cfggrub2-set-default 0的意思是设置默认启动第一条菜单项。如果新内核不在第一位可以先记录菜单条目的编号从0开始数再grub2-set-default 对应编号。随后检查 grubenvcat /boot/grub2/grubenv看到saved_entry0就已经生效了。这里补充一句CentOS 7 的 grub2-mkconfig 输出信息里可能会有一行警告比如 “GRUB_DISABLE_OS_PROBER is not set”只要你不是多系统共存一般不影响。3.4 重启进入新内核重启前再做一次必要的落盘检查sync然后执行reboot重启后第一时间确认内核版本uname -r如果输出是新内核版本号如 5.4.275-1.el7.x86_64说明升级成功。如果输出还是旧内核不要慌很可能是没重启成功或者 GRUB 默认项没生效再reboot一次或者检查 grubenv。另外强烈建议重启后立刻检查负载和 dmesguptime dmesg | grep -i error至少观察几分钟确认网络、磁盘、容器服务都恢复正常再继续下一步。4. 升级后的清理、验证与常见问题速查4.1 确认新内核模块加载并清理旧内核进入新内核后执行下面几条验证命令# 查看当前加载的内核模块数量 lsmod | wc -l # 检查网络模块是否能正常加载 ip a # 检查容器相关功能 docker info 2/dev/null || systemctl status docker 2/dev/null如果网络不通大概率是新内核缺少对应网卡驱动常见场景是某些老服务器的闭源网卡驱动没有适配新内核。这时候先别急着清理旧内核用旧内核回滚再研究模块。确认一切正常后可以用 package-cleanupyum-utils 提供清理旧内核package-cleanup --oldkernels --count2这条命令会保留最近 2 个内核删除更旧的。我建议保留 2 个新内核 上一个旧内核不要直接--count1给自己留一条退路。如果没有 yum-utils也可以手动删除rpm -e kernel-3.10.0-1160.el7.x86_64手动删除要注意必须连带删掉/lib/modules/3.10.0-1160.el7.x86_64/和 /boot 下对应的 vmlinuz、initramfs并且删除后重新生成 grub.cfggrub2-mkconfig -o /boot/grub2/grub.cfg4.2 常见问题排查实录按真实踩坑概率排序整理几个高频问题问题一重启后仍进入旧内核这个我遇到过原因是 grub2-set-default 生效了但 BIOS 里默认从另一块硬盘启动或者 GRUB 菜单里 rescue 条目排在前面。处理办法重启时进入 GRUB 菜单手动选择新内核条目进入系统后重新grub2-set-default并确认 grubenv。问题二系统启动进入 dracut 紧急模式典型表现是开机卡住出现Entering emergency mode的提示。多数情况是 initramfs 没有正确包含根文件系统所在磁盘的驱动。处理办法在 dracut 模式下用旧内核启动然后重新生成 initramfsdracut -f /boot/initramfs-5.4.275-1.el7.x86_64.img 5.4.275-1.el7.x86_64-f是强制覆盖。但频繁手动重建 initramfs 不是好习惯出现这种情况一般是根分区用的文件系统模块没进 initramfs更稳妥的方式是在旧内核启动后检查/etc/dracut.conf.d/里有没有特殊配置或者确认 grub 的root内核参数是否正确。问题三升级后磁盘挂载异常CentOS 7 默认文件系统是 xfs。旧内核 3.10 对应的 xfs 特性较老新内核的 xfs 直接挂载没问题反过来就不行——如果升完级再降回去新内核写入的数据旧内核可能读不了。所以升级后如果发现挂载报错先dmesg | grep xfs再确认日志里的具体报错一般进入旧内核能解决。总之新内核稳定运行几天后就不要轻易回滚到旧内核了xfs 文件系统对新内核生成的元数据可能无法在旧内核下兼容。问题四docker/容器服务启动失败由于 cgroup v2 和 iptables 规则的变化docker 在老内核配置下能跑切到新内核可能遇到iptables -t nat报错或者 cgroup 挂载失败。这个问题我在测试环境也遇到过一般升级 docker 或者重启 docker 服务能让它重新适配新内核。离线环境下 docker 升级可能比较麻烦升级内核前先确认 docker 版本是否兼容目标内核。问题五第三方内核模块缺失最常见的就是杀毒 agent、监控 agent、某些虚拟化平台的 guest tools。这些工具在旧内核下编译的内核模块到新内核里 100% 不能加载。解决办法是先去厂商官网/内网补丁包下载区找适配新内核的版本装好 agent 再升级内核。顺序千万不能反不然新内核启动后 agent 直接拉不起来监控和安全体系同时失效。4.3 离线环境特有的坑位总结离线环境最大的特点是出了问题你不可能临时拉包、临时看文档。所以整个升级过程里我反复强调的其实就两件事备份和保留旧内核。我这次的实际操作顺序是在联网机器下载所有 rpm 包上传到内网服务器后先rpm --test验证依赖安装新内核不删除旧的修改 GRUB2 默认启动项验证新内核稳定性等稳定运行一周后清理旧内核整个过程最花时间的不是装内核本身而是依赖匹配和包传输。rpm 安装两分钟搞定传包可能花半小时找依赖包又来回折腾了一个多小时。如果你们内网有 Nginx 代理或者内部 yum 仓库可以把 rpms 放进本地仓库下次装其他机器就快多了。最后分享一个小技巧离线环境升级内核前可以先把当前内核的 modules 目录完整打包备份tar czf /root/modules-backup-3.10.tar.gz /lib/modules/3.10.0-1160.el7.x86_64/万一新内核装坏了、旧内核也出了问题这套 modules 是你最完整的底牌。我个人建议每个运维兄弟在动手前都做一次这个备份成本极低价值无限。