【实战解析】银河麒麟服务器内核升级:从4.19.90-17到23.18的完整避坑指南

📅 2026/7/13 11:16:46
【实战解析】银河麒麟服务器内核升级:从4.19.90-17到23.18的完整避坑指南
1. 升级前的准备工作银河麒麟服务器操作系统作为国产操作系统的代表其内核升级过程与常规Linux发行版存在显著差异。这次从4.19.90-17升级到23.18版本不仅是版本号的跨越更涉及到底层架构的优化和新特性的引入。在实际操作中我发现有几个关键点必须提前确认首先需要明确当前系统的详细版本信息。执行nkvers命令可以获取完整的系统版本、内核版本和构建信息。这个步骤看似简单但很多运维人员容易忽略细节。比如我曾遇到过一个案例管理员误将SP1版本识别为基础版导致后续依赖包安装出现连锁错误。硬件兼容性检查同样重要。特别是使用鲲鹏920处理器的环境需要确认新内核是否包含特定架构的优化模块。通过lscpu命令查看CPU架构信息后建议到麒麟软件官网查阅对应版本的白皮书。去年我们团队在升级某金融系统时就发现23.18内核针对鲲鹏920的L3缓存管理有重大改进但需要额外安装性能优化包。备份策略必须严格执行。除了常规的配置文件备份/etc目录有几个特殊位置需要特别注意/boot/efi/EFI/kylin/ 下的GRUB配置文件/etc/default/grub 中的内核参数/var/crash/ 下的内核转储文件 我习惯使用tar -zcvf kylin_backup_$(date %Y%m%d).tar.gz /etc /boot /var/crash创建完整备份同时会记录当前安装的软件包列表rpm -qa installed_rpms_before_upgrade.log。2. 获取正确的升级包银河麒麟的软件包管理有其特殊性官方提供的升级包通常包含多个关联组件。根据我的经验23.18版本需要以下核心RPM包以aarch64架构为例包名作用是否必须kernel-core-4.19.90-23.18.v2101.ky10.aarch64.rpm内核核心文件是kernel-modules-4.19.90-23.18.v2101.ky10.aarch64.rpm基础内核模块是kernel-4.19.90-23.18.v2101.ky10.aarch64.rpm内核元数据包是kernel-modules-extra-4.19.90-23.18.v2101.ky10.aarch64.rpm额外驱动模块视硬件需求kernel-modules-internal-4.19.90-23.18.v2101.ky10.aarch64.rpm内部专用模块视应用场景获取这些包有三种途径从麒麟软件官方仓库直接下载使用配套的ISO镜像中的Packages目录通过授权代理商获取定制包这里有个容易踩的坑不同来源的包可能存在微妙的差异。去年我们遇到过一个案例从第三方镜像站下载的包缺少kylin-fonts依赖导致安装时报错。因此我强烈建议通过官方渠道获取下载完成后务必验证SHA256校验值。3. 内核包安装实战安装内核包不是简单的rpm -ivh命令执行而是需要遵循特定顺序的精密操作。根据多次升级经验我总结出最稳妥的安装流程# 先安装核心组包必须一次性安装 rpm -ivh kernel-core-4.19.90-23.18.v2101.ky10.aarch64.rpm \ kernel-modules-4.19.90-23.18.v2101.ky10.aarch64.rpm \ kernel-4.19.90-23.18.v2101.ky10.aarch64.rpm \ kernel-modules-extra-4.19.90-23.18.v2101.ky10.aarch64.rpm \ kernel-modules-internal-4.19.90-23.18.v2101.ky10.aarch64.rpm这个步骤有几点需要注意所有核心包必须同一条命令安装分开安装会导致依赖关系断裂如果出现字体相关警告常见于图形化环境需要额外安装kylin-fonts包在低内存环境小于4GB下建议先释放缓存echo 3 /proc/sys/vm/drop_caches安装完成后需要处理可选组件。这些包根据实际需求决定是否安装# 开发工具包仅开发环境需要 rpm -Uvh kernel-devel-4.19.90-23.18.v2101.ky10.aarch64.rpm \ kernel-headers-4.19.90-23.18.v2101.ky10.aarch64.rpm # 性能分析工具生产环境建议安装 rpm -Uvh python3-perf-4.19.90-23.18.v2101.ky10.aarch64.rpm \ bpftool-4.19.90-23.18.v2101.ky10.aarch64.rpm4. kexec-tools与kdump配置内核升级后崩溃转储机制需要特别关注。23.18内核要求kexec-tools版本不低于2.0.20否则会导致kdump服务异常。配置过程分为三个关键步骤首先是安装依赖包rpm -ivh dracut-squash-049-8.p04.se.09.ky10.aarch64.rpm然后升级kexec-tools主包rpm -Uvh kexec-tools-2.0.20-14.p02.ky10.aarch64.rpm \ kexec-tools-help-2.0.20-14.p02.ky10.noarch.rpm最后重新加载服务配置systemctl daemon-reload systemctl restart kdump.service这里有个实际案例值得分享某次升级后kdump服务虽然显示active但实际无法生成vmcore文件。排查发现是dracut-squash版本不匹配导致。解决方法是在升级前先卸载旧版rpm -e dracut-squash --nodeps然后安装新版。5. crashkernel参数调整crashkernel内存分配是保证kdump正常工作的关键。在鲲鹏920平台上23.18内核需要特殊配置编辑/etc/default/grub文件找到包含crashkernel的行确保配置为crashkernel1024M,high并移除任何crashkernelauto的设置对于内存大于64GB的系统建议设置为crashkernel2048M,high修改后需要重新生成GRUB配置# 对于UEFI启动的系统 grub2-mkconfig -o /boot/efi/EFI/kylin/grub.cfg # 对于传统BIOS启动的系统 grub2-mkconfig -o /boot/grub2/grub.cfg这个环节最容易出现的问题是内存分配不足。我遇到过多个案例管理员保留默认的512M设置结果在生成大容量转储文件时失败。根据经验对于运行数据库等内存密集型应用的服务建议至少保留1.5GB的crashkernel内存。6. 验证升级结果系统重启后需要通过多层验证确保升级完全成功检查当前运行的内核版本uname -r # 应显示4.19.90-23.18.v2101.ky10.aarch64验证引导参数cat /proc/cmdline | grep crashkernel # 应包含crashkernel1024M,high检查kdump服务状态systemctl status kdump.service # 应显示active (running)确认kexec-tools版本rpm -qa | grep kexec-tools # 应显示kexec-tools-2.0.20-14.p02.ky10.aarch64查看默认启动项grub2-editenv list # 应指向新内核版本建议创建一个完整的验证检查表。去年我们为某证券系统升级时就因为没有检查/boot分区的剩余空间新内核占用更多空间导致后续安全更新失败。现在我会额外执行df -h /boot命令确保至少有200MB剩余空间。7. 故障处理与回退方案即使准备充分升级过程仍可能出现意外。根据实战经验我总结出以下常见问题及解决方案问题一系统无法启动新内核现象重启后卡在GRUB界面或内核panic解决方案在GRUB界面选择旧内核启动进入系统后检查/var/log/messages和/var/log/dmesg常见原因是显卡驱动不兼容可尝试添加nomodeset启动参数问题二kdump服务启动失败现象systemctl status显示failed解决方案检查/var/log/messages中的kdump相关错误常见错误是内存不足需增大crashkernel值执行kdumpctl showmem验证保留内存问题三硬件设备无法识别现象lspci能看到设备但无对应驱动解决方案检查dmesg | grep -i error安装对应内核模块包或降级到旧内核等待驱动更新回退操作需要特别注意在GRUB界面选择旧内核启动进入系统后执行rpm -e kernel-core-4.19.90-23.18.v2101.ky10.aarch64 \ kernel-modules-4.19.90-23.18.v2101.ky10.aarch64重新配置默认启动项grub2-set-default Kylin Linux Advanced Server (4.19.90-17)在最近的一次升级中我们遇到一个棘手问题新内核导致某型号RAID卡性能下降50%。通过分析发现是23.18内核修改了SCSI超时机制。临时解决方案是在/etc/modprobe.d/下添加参数覆盖最终等厂商发布了新版驱动才彻底解决。这提醒我们关键业务系统升级前务必在测试环境做完整的性能基准测试。