去年年底公司机房一批老机器到了生命周期末尾，运维那边递过来一张表：CentOS 7 已经彻底停止维护，官方源只留在 vault 目录里，再往后连 yum update 都会报 404。这批机器上跑着三套内部系统和一堆没人知道来历的定时脚本，硬盘里的东西不能直接装到新系统上，只能逐台重装。折腾了一个周末，我把这套迁移流程走了两遍，才算把 CentOS 7 到 Rocky Linux 9 这条路彻底走通。最大的感受是：真正难的不是把系统装上，而是那些「yum 时代留下的习惯」在新系统上会一个个翻车。
如果你也在准备把老旧 Linux 服务器从 CentOS 7 迁到 Rocky Linux / AlmaLinux 9，或者需要一台机器先把这个流程演练一遍再上生产，可以先看看这几家的硬件规格和技术说明再动手：akkocloud（全球云服务器）、tokyonline（公有云、私有云与混合云服务）。系统迁移最怕的是中途才发现新机器的磁盘、网络、虚拟化环境和老机器对不上，先拿一台配置接近的机器做演练，把差异摸清楚再动生产。
Rocky Linux 9 出于兼容考虑，保留了 yum 这个命令名，但背后的实现已经整体换成了 dnf 系。很多人在 CentOS 7 上养成的命令习惯，到 Rocky 9 上要么直接报错，要么行为悄悄变了。
最典型的是仓库配置。CentOS 7 的 /etc/yum.repos.d/CentOS-Base.repo 在 Rocky 9 上没有对应文件，你得自己写 Rocky-Base.repo，里面是 baseurl=http://dl.rockylinux.org/$releasever/BaseOS/$basearch/os/ 加 AppStream 两段。如果新机器上没配 fastestmirror，dnf 每次都要挨个探测镜像站，一次 dnf install 能等好几分钟，看着像卡死，其实是在 ping 全世界。
第二个变化是 Python。dnf 的命令行是 Python 写的，Rocky 9 默认给 python3，而 dnf 这个入口是 dnf-3 提供的。很多老脚本里写的是 yum install xxx && yum clean all，迁过去之后 yum clean all 这一句的输出格式都变了，如果你用正则去抓输出做判断，脚本就会莫名其妙地走错分支。
第三个变化在 dnf update 的行为上。CentOS 7 的 yum 默认不跨大版本升级，Rocky 9 的 dnf 加了 --releasever 参数后行为变得更可预期，反倒是好事，只是你要习惯显式写清楚目标版本，别让工具自己去猜。
这次迁移里最费时间的，是那些在 CentOS 7 上通过 epel 装进来的包。Rocky 9 的 AppStream 和 CodeReady 仓库拆得很细，很多在 7 上一个 yum install 就装上的包，到 9 上要么要加 --enablerep=crb，要么包已经干脆被移除，只留源码让你自己编译。
具体踩到的坑有这么几个：
第一个是 python2。CentOS 7 上一堆运维脚本、监控 agent、老版本编译出来的工具全绑在 python2.7 上，Rocky 9 的仓库里没有 python2，你只能从 Rocky 8 时代的 AppStream 找 python2 包，或者自己编译装到 /opt/python2，然后把 #!/usr/bin/env python2 的 shebang 全部改掉。我那台机器上有 14 个脚本要改，跑了一次 grep -rl "python2" /opt 才发现漏了两个藏在监控插件目录里的。
第二个是 glibc 和编译产物。老系统里用 make 编出来的 .so 只认 2.17 的符号表，装到 Rocky 9 上运行时报 GLIBC_2.28 not found。这种情况没有捷径，只能在新系统上重新编译源码，或者干脆换成容器部署，把依赖锁死在镜像里。
第三个是 EPEL 里的老包名。比如 python-mysqldb 在新版里改名成 python3-mysqlclient，redis 的老版本包名带 el7 后缀。这些在 dnf list 里能查到，但如果你脚本里写死了包名，迁移后必然报 No match for argument。
第四个是 systemd unit 文件。CentOS 7 上有些服务是用 SysV init 脚本起的，重装后 systemctl enable 会提示找不到 unit，得用 systemctl reenable 或者 systemd-sysv-generator 生成对应 unit 再启用，路径一般在 /etc/systemd/system/。
我把这次迁移的验收清单留成了 5 条，顺序不能乱：
一是 SELinux 状态。Rocky 9 默认开启 enforcing，老程序读某些目录会被直接拒绝，日志里只有一行 avc: denied，不盯着 /var/log/audit/audit.log 根本看不出来。我的做法是先 getenforce 确认状态，再决定是给程序打 semanage fcontext 标签还是临时 setenforce 0 排障，确认干净后恢复。
二是 firewalld 与安全组。CentOS 7 上用 iptables 的规则不会被自动带到 Rocky 9 的 firewalld 里，新系统默认只放行 ssh 和几个服务端口，Nginx、MySQL、自建服务的端口要一条条 firewall-cmd --add-port 补回去，漏一条就是「服务起来了但连不上」。
三是 crontab 与 systemd timer。用户的 crontab 在 /var/spool/cron/ 里会被保留，但 /etc/cron.d/ 下带用户字段的任务、还有那些放在 /etc/cron.daily 里的脚本，得单独核对。我这次就漏了一个 /etc/cron.d 里的备份任务，跑了两个月才发现备份从没成功过。
四是 配置文件和自定义服务。/etc 下的配置不会自动迁移，得一份份比对差异，尤其是 /etc/hosts、/etc/resolv.conf、/etc/sysctl.conf 和 /etc/ld.so.conf.d/。后者漏了，新装的软件就找不到自带的 .so。
五是 网络与时间。网卡配置文件在 CentOS 7 是 ifcfg-eth0，在 Rocky 9 是 ifcfg-ens192 这类预测名，命名规则变了。写死 eth0 的启动脚本会失效，可以用 net.ifnames=0 临时退回旧命名，但更好的做法是把脚本改成按 MAC 或 nmcli con 的连接名去取 IP。时间同步也要确认 chronyd 起来了，证书校验、NTP 校时、MySQL 主从全靠它。
现在回头看，整套流程里最值的不是任何一条命令，而是顺序。
第一步，先在旧机器上把 rpm -qa 的输出、监听端口、crontab、SELinux 状态、firewalld 规则、内核参数全部导出来存成一份文本。这份东西就是验收清单的来源，我把它叫做「老机器的账本」。
第二步，装新系统。装之前先确认引导模式是 UEFI 还是 BIOS、磁盘分区是 GPT 还是 MBR。我遇到过一台老机器因为没留引导分区，新系统装完重启直接进了 grub rescue。
第三步，装完不急着上业务，先把服务一个个装起来、加到开机自启、逐个验证端口能通。我给自己定的规矩是：一个服务验证通过再装下一个，不然出问题时分不清是哪个包引起的。
第四步，做数据迁移。这里我不用 rsync 直连生产目录，而是先做全量快照，再把数据同步到新机的测试路径，用一套只读的业务配置做一轮比对，确认文件数量、大小、校验值都对得上，才改指向。
第五步，切流量的同时保留旧机器 7 天不下线，出问题能立刻回滚。这一步是血泪教训换来的迁移窗口只有凌晨两小时，没人愿意在那个时间点背锅。
整套走下来，CentOS 7 到 Rocky Linux 9 真正需要动手改的，归根结底就三处：包和仓库（dnf 源、EPEL 包名、python2 依赖）、服务化方式（SysV 脚本转 systemd unit、crontab 补齐）、安全策略（SELinux 标签、firewalld 端口）。前两处是机械性的，照着账本一条条对就行；第三处最耗时间，因为它不报错，只在日志里留一行 denied。
如果你手上的机器还在 CentOS 7 上，建议现在就把 rpm -qa 和端口清单导出来存好。等哪天真的要迁的时候，你至少有账本可对，而不是对着新系统凭记忆猜。
迁移前把旧机器的包清单、监听端口、定时任务导成一份"账本"，是整个流程里性价比最高的一步。
Rocky 9 的 dnf 需要重写 /etc/yum.repos.d/ 下的源文件，AppStream 与 CodeReady 仓库的拆分也是装不上包的主因。
切流量时保留旧机器 7 天下线，迁移窗口只有两小时，谁都不想在那时候背锅。
从 CentOS 7 到 Rocky 9，机械性改动照着账本一条条对就行，最耗时间的是 SELinux 这种不报错只在 audit.log 里留一行 denied 的坑。
