离线环境下的欧拉系统升级实战：从22.03到24.03的避坑指南

1. 离线升级前的“粮草”准备镜像与心态兄弟们最近是不是被内网、隔离环境下的系统升级搞得焦头烂额我懂那种看着公网教程流口水自己却连个包都下不下来的感觉太憋屈了。这次咱们就来啃一块硬骨头在完全没有外网的环境下把欧拉系统从22.03版本一路升级到最新的24.03版本。我前前后后折腾了好几个礼拜踩的坑比吃的饭还多今天就把这份血泪换来的实战指南分享给你保证每一步都踩在实地上。首先咱们得搞清楚离线升级的核心矛盾系统需要新包但网络不给力。解决这个矛盾的唯一钥匙就是本地RPM镜像源。这玩意儿就像是你的私人军火库所有升级需要的“弹药”软件包都得提前备好。很多公司内部会有自己的镜像服务器通过内部端口提供访问比如http://your-internal-mirror:port/openEuler-24.03/这样的地址。如果你的环境连这个都没有那就得自己动手丰衣足食——找一台能上网的机器用reposync或者wget把整个24.03版本的仓库同步下来做成一个本地的HTTP或FTP服务器。这一步是基础没这个源后面的一切都是空中楼阁。除了镜像源心态准备同样重要。离线升级不是点一下按钮就完事的自动化流程它更像是一次精密的外科手术过程中可能会遇到依赖冲突、引导丢失、服务异常等各种“并发症”。所以备份备份再备份这不是一句空话。我强烈建议你在操作前至少做三件事1. 对关键业务数据进行全量备份2. 使用tar或rsync备份整个/etc目录这里存放了所有系统配置3. 记录下当前的网络配置、磁盘分区情况ip addr,df -h,fdisk -l。万一升级后SSH连不上、网卡名变了比如从eth0变成了ens192或者干脆进不了系统这些备份就是你救命的稻草。最后检查一下当前系统的状态。登录到你的22.03系统用uname -r看看内核版本。根据我的实测要顺利升级到24.03内核版本最好先升级到6.6。如果版本较低可以先从你的本地源升级内核。同时运行dnf -y update把现有系统更新到最新状态这能避免很多因基础包版本过低导致的奇葩问题。做完这些咱们的“粮草”就算基本到位了可以准备开拔。2. 搭建稳固的本地作战基地配置Repo源有了本地镜像下一步就是告诉系统“别去网上找了你的新家在这里。” 这个“告诉”的过程就是配置本地的 repo 源文件。在欧拉系统里这些配置文件都放在/etc/yum.repos.d/目录下。为了安全起见咱们第一步不是直接修改而是先给这个目录做个备份。这招我百试不爽关键时刻能让你一键回退。# 备份现有的源配置目录 cp -av /etc/yum.repos.d/ /etc/yum.repos.d.backup_$(date %Y%m%d) # 清空该目录准备配置我们自己的源 rm -rf /etc/yum.repos.d/*接下来创建一个新的 repo 文件比如local-openEuler-24.03.repo。文件内容的核心就是指向你的本地镜像地址。这里有个关键点baseurl的路径必须精确到仓库的os/$basearch/这一层。很多兄弟配置完源后dnf makecache失败八成就是路径写错了。# 编辑新的repo文件 vi /etc/yum.repos.d/local-openEuler-24.03.repo将以下内容粘贴进去请务必将baseurl替换成你实际的本地镜像URL[local-openEuler-24.03-OS] namelocal-openEuler-24.03-OS baseurlhttp://your-internal-ip:port/openEuler-24.03/OS/$basearch/ enabled1 gpgcheck0 priority1 [local-openEuler-24.03-Everything] namelocal-openEuler-24.03-Everything baseurlhttp://your-internal-ip:port/openEuler-24.03/Everything/$basearch/ enabled1 gpgcheck0 priority1 [local-openEuler-24.03-EPOL] namelocal-openEuler-24.03-EPOL baseurlhttp://your-internal-ip:port/openEuler-24.03/EPOL/$basearch/ enabled1 gpgcheck0 priority1这里我做了几个关键设置gpgcheck0是因为我们用的是自建源跳过GPG签名检查能省去很多麻烦priority1是给这个源设置最高优先级确保系统升级时优先从本地拉取包。保存退出后运行dnf clean all清除旧的缓存再运行dnf makecache建立新缓存。如果看到成功下载了元数据恭喜你本地作战基地搭建成功3. 攻坚升级核心处理依赖冲突与版本同步这是整个升级过程中最核心、也最容易出错的环节。直接运行dnf distro-sync升级大概率会撞上一堵叫做“依赖冲突”的墙。错误信息通常长得像这样file /usr/share/xxx from install of package-A conflicts with file from package-B。这意思是新版本包A提供的某个文件和系统里旧版本包B提供的文件冲突了系统不知道听谁的。面对这种冲突网上的教程很多会教你无脑--force或者--nodeps强上。我强烈反对这种做法这相当于给病人做手术时把出血的血管直接剪断后面隐患无穷。我摸索出的稳妥方法是“先拆后建”。首先仔细阅读错误信息找到冲突双方的具体包名。通常冲突的一方是来自新版本仓库的包如ukui-power-manager-3.1.2-5.oe2203sp2.x86_64另一方是系统里残留的旧版本包如ukui-power-manager-common-2.0.3-1.oe1.x86_64。我们的策略是暂时移除那个旧的、可能已被废弃或拆分的包。注意是移除erase不是升级。使用rpm -e --nodeps package-name命令。--nodeps参数在这里是必要的因为它允许我们不检查依赖关系直接移除但你必须非常清楚你在移除什么。通常移除旧架构oe1或明显过时的子包是相对安全的。# 示例移除冲突的旧包 rpm -e --nodeps ukui-power-manager-common-2.0.3-1.oe1.x86_64 # 可能还有其他冲突包根据错误提示依次处理处理完所有冲突包后再执行升级命令。这里我推荐使用一个更全面的命令组合它能处理更复杂的版本替换dnf -y --releasever24.03 --allowerasing --setoptdeltarpmfalse distro-sync --nogpgcheck我来解释一下这几个关键参数--releasever24.03明确指定目标版本。--allowerasing允许DNF为了解决依赖关系而移除一些包。这个参数比单纯的--force更智能。--setoptdeltarpmfalse禁用增量RPM包。在离线环境或网络不稳定的情况下使用完整包更可靠。distro-sync这是关键它不仅升级包还会降级那些版本过高的包使整个发行版版本同步。--nogpgcheck因为我们用的是本地源跳过GPG检查。这个过程可能会持续较长时间并且中间可能还会提示你确认一些包的移除操作。务必仔细查看列表确认没有核心系统包被误删。执行完毕后建议立即重建RPM数据库rpm --rebuilddb。这个操作能修复因包变更可能导致的数据库不一致问题很多后续的“包找不到”的灵异事件都是靠这招解决的。4. 升级后的系统修缮与引导加固系统包同步完成先别急着重启这时候的系统处于一个“新旧混合”的脆弱状态很多基础环境可能不完整。我们首先要做的是重装最小化安装组。这个操作能确保系统最核心的组件都被正确安装和配置避免出现连ls、vi这种基础命令都找不到的尴尬情况。dnf groupinstall Minimal Install -y接下来是重中之重修复系统引导。这是离线升级最大的“坑王”一不小心就会导致系统重启后黑屏直接“变砖”。修复引导分两步走第一步是重新生成GRUB配置文件第二步是根据你的磁盘分区表类型重新安装引导程序。首先查看你的磁盘分区表类型fdisk -l /dev/sda在输出信息的最开始几行你会看到类似Disklabel type: gpt或Disklabel type: dos的字样。gpt对应UEFI启动方式dos对应传统的Legacy BIOS启动方式。这两种方式的修复命令截然不同千万别搞错。情况一GPT分区表 UEFI启动这是现在新服务器的标配。你需要做两件事重新生成GRUB配置。欧拉系统下GRUB配置文件路径可能比较特殊用这个命令查找并生成export grubcfg$(find /boot -name grub.cfg 2/dev/null | head -1) grub2-mkconfig -o $grubcfg如果找不到通常的路径是/boot/efi/EFI/openEuler/grub.cfg。使用efibootmgr在UEFI固件中创建或更新启动项。这里的参数需要你根据实际情况调整# 假设你的EFI系统分区ESP是 /dev/sda1 efibootmgr -c -w -L openeuler -d /dev/sda -p 1 -l \\EFI\\openEuler\\grubx64.efi-d /dev/sda指定磁盘-p 1指定分区号即sda1-l后面是efi文件的路径注意这里是双反斜杠。情况二MBR分区表 Legacy BIOS启动这是传统方式操作相对简单# 重新生成GRUB配置文件到默认位置 grub2-mkconfig -o /boot/grub2/grub.cfg # 将GRUB引导程序安装到磁盘主引导记录MBR grub2-install /dev/sda同样/dev/sda需要替换成你的系统盘设备名。完成这两步后你可以稍微松一口气了。但重启前还有一件“打扫战场”的事可做清理旧内核。升级后系统里可能会保留多个旧内核占用/boot分区空间。可以用dnf remove kernel-4.19*这样的命令移除指定版本的旧内核请先确认当前启动的新内核版本别删错了。最后深吸一口气执行reboot。如果一切顺利你将看到一个崭新的、版本号为24.03的欧拉系统。如果遇到问题别慌我们还有下一章的“救命锦囊”。5. 常见翻车现场与救命锦囊即使按照指南一步步操作在复杂的离线环境中翻车也在所难免。下面是我和同事们踩过的一些典型深坑以及救火方案希望能帮你快速排雷。翻车点一重启后卡在“grub”或“initramfs”提示符这是引导修复不彻底的最直接表现。如果卡在grub你还可以手动引导进入系统来补救。在grub提示符下依次输入以下命令需要你知道根分区和boot分区的位置例如/dev/sda2和/dev/sda1grub set root(hd0,gpt2) # 假设根分区是第2个GPT分区 grub linux /boot/vmlinuz-6.6.xx root/dev/sda2 grub initrd /boot/initramfs-6.6.xx.img grub boot如果能成功进入系统请立即重新执行上一章中对应的、正确的grub2-install和grub2-mkconfig命令。如果卡在initramfs通常是初始内存盘镜像损坏或缺失可以尝试从备用内核启动或者进入救援模式使用dracut --force /boot/initramfs-$(uname -r).img $(uname -r)重新生成。翻车点二SSH无法连接网络不通升级后最常见的问题是网络服务没起来或者网卡名变了。首先通过服务器本地终端登录检查网络状态ip addr查看网卡名称和IP地址。如果网卡名从eth0变成了ens192你需要更新/etc/sysconfig/network-scripts/下的网卡配置文件或者直接使用新的nmcli命令管理。systemctl status network或systemctl status NetworkManager查看网络服务状态。很可能服务因为依赖问题没有自动启用手动systemctl start network并systemctl enable network。检查/etc/ssh/sshd_config是否被意外修改特别是PermitRootLogin设置。确保防火墙规则也放行了22端口firewall-cmd --add-servicessh --permanent firewall-cmd --reload。翻车点三关键服务如Docker数据库启动失败系统升级了但用户空间的软件环境可能还没跟上。首先用systemctl status service-name查看具体的失败原因。很大概率是依赖的库文件版本不匹配。例如Docker可能依赖特定版本的containerd.io或libseccomp。解决方法是从你的本地24.03镜像源中查找并安装这些服务所需的最新版本依赖包。如果软件本身如MySQL是从官方rpm安装的可能需要卸载后重新从本地源安装与系统版本兼容的版本。一个万能思路使用ldd $(which your-service-binary)命令查看二进制文件的动态链接库依赖对比缺失或版本冲突的库然后从本地源补充安装。翻车点四DNF/YUM包管理器本身出错例如执行任何dnf命令都报“RPM数据库损坏”错误。这时可以尝试以下修复组合拳# 尝试重建数据库 rm -f /var/lib/rpm/__db* rpm --rebuilddb # 清理并重建DNF缓存 dnf clean all rm -rf /var/cache/dnf/* # 如果还不行尝试强制安装RPM工具包本身 rpm -Uvh --force /path/to/local/rpm-packages/*.rpm在整个救火过程中你最强大的后盾就是第一步做的备份。如果问题实在无法解决可以考虑从备份中恢复/etc目录下的配置文件或者利用安装镜像进入救援模式从备份中恢复数据。记住离线升级是一场硬仗耐心和细致的排查往往比复杂的技巧更重要。每次踩坑和解决问题的过程都是你对这套系统理解加深的时刻。