CLOUD云枢结论：CentOS 7.9 迁移到 Rocky Linux 无法通过“一键升级脚本”直接完成，且官方不支持直接原地升级（In-place Upgrade）。
CentOS 7 和 Rocky Linux 虽然都基于 RHEL 生态，但它们的软件包来源、仓库配置以及底层元数据存在差异。试图运行一个脚本来“自动升级”不仅风险极高，而且极易导致系统崩溃或陷入无法启动的状态。
以下是详细的分析、推荐方案及操作建议：
1. 为什么不能“一键升级”？
- 架构与源不同：CentOS 7 的 yum/dnf 源指向 CentOS 镜像，而 Rocky Linux 指向 Rocky 镜像。直接修改
repos文件并运行yum update会尝试将 CentOS 的软件包替换为 Rocky 的软件包，这会导致依赖关系混乱（Dependency Hell），因为两个发行版的包版本号和构建时间不完全一致。 - 核心组件差异：Rocky Linux 7.x 是作为独立的发行版发布的，其内核、glibc 等基础库的版本可能与 CentOS 7 的最终补丁版本略有不同。强行混合可能导致系统核心组件损坏。
- 官方立场：Red Hat 及其衍生版（包括 Rocky）官方均不提供从 CentOS 7 到 Rocky 7/8/9 的原地升级工具。CentOS 7 的官方迁移指南也明确建议使用“重新安装”或“转换工具”策略，而非简单的脚本升级。
2. 推荐的迁移方案
根据你对数据保留、停机时间和技术能力的要求，有三种主流方案：
方案 A：全新安装 + 数据迁移（最推荐，最稳定）
这是官方和运维社区最推荐的方式，能确保系统纯净、无残留垃圾文件。
- 备份数据：使用
rsync、tar或快照工具备份所有关键数据（/etc,/var/www,/home, 数据库等）。 - 创建新实例：在目标服务器（或虚拟机）上全新安装 Rocky Linux（建议选择 Rocky 8 或 9，除非业务强制要求 7）。
- 迁移配置与数据：
- 将旧系统的配置文件复制到新系统对应位置。
- 恢复数据。
- 调整新系统的网络配置（IP、DNS）。
- 测试与切换：验证服务正常后，更换 IP 或 DNS 指向新服务器。
方案 B：使用 migrate2rocky 工具（半自动化，需谨慎）
如果你必须保留现有系统环境（如复杂的自定义配置），可以使用由 Rocky 社区提供的转换脚本。但这不是简单的“一键升级”，而是需要手动干预的转换过程。
- 工具名称：
migrate2rocky(通常集成在centos-release-rocks或相关社区脚本中，但更常用的是手动步骤)。 - 注意：目前针对 CentOS 7 到 Rocky 7 的成熟脚本较少，更多是针对 CentOS Stream 或其他版本的。对于生产环境，强烈不建议仅依赖脚本而不进行人工复核。
如果坚持尝试此方案，基本逻辑如下（仅供参考，非一键执行）：
- 备份系统。
- 移除 CentOS 的 release 包。
- 安装 Rocky 的 release 包。
- 修改
yum.repos.d文件指向 Rocky 源。 - 执行
dnf distro-sync。 - 风险：此过程极易失败，一旦失败需回滚备份。
方案 C：容器化或虚拟化迁移
如果你的应用已经容器化（Docker/Podman）或部署在 KVM/OpenStack 中：
- 导出虚拟机镜像或容器镜像。
- 导入到新安装的 Rocky Linux 环境中。
- 这种方式本质上也是“重建”，但比物理机迁移快得多。
3. 重要提示：关于 CentOS 7 的生命周期
- EOL 状态：CentOS 7 已于 2024 年 6 月 30 日 正式停止维护（EOL）。这意味着你将不再收到安全更新。
- 版本选择：
- 如果你选择迁移到 Rocky Linux 7：虽然兼容性好，但 Rocky 7 本身也即将面临生命周期结束的问题（预计 2024-2025 年左右）。
- 最佳实践：建议直接迁移到 Rocky Linux 8 或 Rocky Linux 9。这需要你同时解决操作系统版本跨越带来的兼容性改造（如 Python 2 转 Python 3，Systemd 配置变化等），但能获得长期的安全支持。
总结建议
不要寻找所谓的“一键升级脚本”。为了生产环境的稳定性，请执行以下标准流程：
- 全量备份（最重要的一步）。
- 准备一台新的 Rocky Linux 服务器（建议选 v8/v9）。
- 在新服务器上重新部署应用和服务。
- 对比新旧系统配置，进行数据同步。
- 割接上线。
如果你是在云厂商（如 AWS, Azure, 阿里云等）环境，直接使用云厂商提供的“镜像克隆”功能，然后在新实例上挂载磁盘并重装系统往往是最快的方式。