升级内核本身一步到位结果重启后屏幕不是系统登录界面而是一段冷冰冰的英文最后停在一个grub rescue的光秃秃提示符上。这种事CentOS运维多少都碰过尤其是在CentOS 7.7这样的老版本上升级内核概率还不低。如果你现在正被这台机器卡住或者只是想提前搞明白这台机器要怎么救回来这篇文章就把整条链路给你捋清楚从rescue模式到底是个什么东西到怎么用手打命令把系统拉起来再到回系统后的修复和大白话版的内核升级避坑流程。1. 升级内核怎么会把GRUB搞进rescue模式三条最常走的歪路1.1 rescue模式与normal模式的本质区别想搞清楚为什么升级内核会进grub rescue得先明白GRUB的两种“卡死状态”有什么不一样。正常启动时GRUB会进入一个加载好的菜单界面里面列着一堆内核选项你选了某个内核它再把对应vmlinuz和initramfs加载起来。这份菜单来自GRUB的normal模块这个模块文件一般放在/boot/grub2/下面由配置文件grub.cfg指挥。只要normal模块能加载、grub.cfg能读出来你最多看到的是grub这个普通命令行属于“配置坏了但模块没坏”。而grub rescue是比普通命令行更底层的一层。它意味着GRUB连自己的模块文件都找不到或者连boot分区里的文件系统都识别不了只能停在有限的一小撮内置命令里。换句话说这台机器现在处在“GRUB自身环境不完整”的状态而不是“GRUB找不到启动项”两者差的不是一点半点。升级内核之后常见的落差就在这里你以为升级只是换了内核文件实际上它可能动了GRUB自己踩的那块地基于是一重启就整体翻车。1.2 歪路一/boot分区被旧内核塞满这是我在CentOS 7.7上见过最多的一种情况。yum安装新内核包时post脚本会做两件事一是用dracut重新生成initramfs二是调用grub2-mkconfig重建grub.cfg。如果/boot分区剩余空间不足新内核的vmlinuz文件写到一半文件系统就满了新内核没放进去但脚本已经进入重建grub.cfg的阶段。此时生成的grub.cfg里写着一个不存在的内核文件路径甚至生成过程报错后只留下半个配置文件。GRUB启动时去读grub.cfg读到一半发现文件结构不对继续不下去模块也没加载就掉进grub rescue。还有一种更隐蔽的情况旧的内核全部健在但/boot满了之后内核ex安装脚本写不进去新的menuentry却把旧的menuentry清掉了等于菜单整体失效。CentOS 7.7默认分区时给/boot的空间常常只有200MB或者500MB挂着三四个旧内核、每个内核加initramfs几十到上百MB很容易就捉襟见肘。升级前不看分区余量升级后一重启就中招这是整条路线里概率最高的。1.3 歪路二第三方大版本内核的post安装脚本崩了CentOS 7.7默认内核停留在3.10系列版本比较老有些业务因为硬件驱动或者性能需要会装第三方仓库提供的4.x、5.x版本内核。第三方内核的安装脚本同样要重建initramfs和grub.cfg但它默认生成的menuentry里面可能带了系统当前GRUB版本不支持的启动参数或者说它依赖的grub2-common组件没有跟着升级。这种情况下最典型的表现就是内核装完了重启动画一闪而过然后出现error: unknown filesystem或error: file /grub2/grub.cfg not found直接掉进rescue模式。前者是GRUB读不懂boot分区的文件系统后者是GRUB按误设的prefix找不到配置。第三方内核带来的另一个麻烦是/boot下生成的vmlinuz、initramfs文件本身没有错但启动时与系统的initrd生成脚本存在版本差异间接导致grub.cfg里写入了不兼容的initrd路径。各种叠加下来重启就成了开盲盒。用第三方源不是不行只是升级前你最好先想清楚当前GRUB版本、系统里的dracut版本能不能吃下新内核的脚本行为。直接拿别家打包好的内核扔进去不管出事的概率比我做菜不放盐的概率还高。1.4 歪路三GRUB模块与boot文件系统不匹配还有一种情况跟内核版本关系不大但升级内核时会被一并引爆。CentOS 7.7安装时/boot分区常见的是xfs或ext4如果之前有人因为特殊需求重新格式化过boot分区或者手动调整过分区类型新内核安装后调用grub2-install时写进去的GRUB模块可能与当前grub.cfg、文件系统驱动不匹配。重启时GRUB的引导镜像去加载normal模块结果normal模块尝试挂载boot分区失败GRUB无法读取真正的配置只能降到rescue模式。换句话说升级前grub2-install写的是旧模块升级过程中被意外覆盖新模块又不认boot分区的状态最后卡在一个两边都不兼容的中间态。这是三种歪路里最不好定位的因为它没有留日志只在屏幕上有错误码。下面这张表可以作为快速对照帮你在grub rescue下判断大概是什么原因屏幕上出现的错误大概率原因处理方向error: unknown filesystemGRUB读不了boot分区文件系统或根分区类型不被GRUB模块支持重新确认分区布局、考虑insmod xfs/ext4/lvmerror: file /grub2/grub.cfg not foundprefix没指对或grub.cfg真丢了手动set prefix/set root看能否读到grub2/grub.cfgerror: file /boot/grub2/grub.cfg not foundboot独立分区时路径写多了一层boot在rescue里调整prefix路径error: invalid arch independent ELF magicGRUB模块与文件实际架构或版本不匹配重启后用安装介质chroot重装grub2-install屏幕什么都闪过然后停rescue多个原因叠加按第2章手动引导进去再说知道大概是哪条路后面就好办了。下面先讲怎么在grub rescue这种半残状态下把系统拉起来。2. grub rescue 自救在没有引导菜单时把手伸进系统2.1 起点先用ls盘点GRUB看见了谁别一上来就乱敲。grub rescue里能用的命令不多但ls这条够用它有两个作用列出GRUB认出的磁盘和分区列出某个分区根目录下的文件。先敲grub rescue ls大概率输出类似(hd0) (hd0,msdos1) (hd0,msdos2)这表示一块硬盘两个分区。接着挨个看分区里到底有什么grub rescue ls (hd0,msdos1)/如果输出里能看到grub2/目录还有vmlinuz-*、initramfs-*.img这些文件说明这个分区就是 boot 分区。如果看到bin/、boot/、dev/、etc/、home/这类目录说明这是根分区boot目录在根分区里没有独立boot分区。这一步的关键在于判断GRUB到底“看见”了谁。如果ls (hd0,msdos1)/直接报错比如error: unknown filesystem那就说明GRUB目前连该分区的文件系统驱动都没有加载后面就需要考虑先insmod对应模块再试比如insmod xfs、insmod ext4。这一步往往能直接定位出到底是不是模块不匹配的问题。2.2 手敲三行命令把系统拉回来确认了boot分区具体在哪个磁盘分区之后接下来就是经典的GRUB手动引导三板斧。以boot分区在(hd0,msdos1)为例grub rescue set prefix(hd0,msdos1)/grub2 grub rescue set root(hd0,msdos1) grub rescue insmod normal grub rescue normalset prefix告诉GRUB去哪里找它的模块目录set root告诉它根分区在哪insmod normal加载菜单模块normal则让它回到正常的菜单加载流程。这三者缺一不可很多人卡住就是因为只设了root没设prefix或者反过来。这里有个细节要特别留意如果boot是独立分区且本身就是根目录那prefix写的是(hd0,msdos1)/grub2如果boot目录是根分区下的一个子目录那prefix要写成(hd0,msdos1)/boot/grub2。多了或少了一层boot/结果就是GG。所以前面用ls确认文件位置这一步不能跳。执行normal之后如果GRUB能正常读到grub.cfg你就能看到内核选择菜单。这时候别急着选最新的内核先选一个当前/boot下文件确实存在的、之前的旧内核进去只要能进系统修复工作就成功了大半。2.3 如果还是进不去手动指定vmlinuz和initramfs有的情况比较恶心normal执行完连菜单都出不来直接退回grub或者继续报文件找不到。这时候别灰心你还有一条路完全手动指定内核文件启动。先继续ls看看boot分区下实际有哪些内核文件grub rescue ls (hd0,msdos1)/找到具体的vmlinuz-3.10.0-xxx.el7.x86_64和initramfs-xxx.img文件名后手动引导grub rescue set root(hd0,msdos1) grub rescue linux /vmlinuz-3.10.0-xxx.el7.x86_64 rootUUID你的根分区UUID ro grub rescue initrd /initramfs-xxx.img grub rescue bootrootUUID你的根分区UUID里的UUID不是boot分区的UUID是系统根文件系统那个分区的UUID这个值可以从/etc/fstab里抄或者用blkid看前提是你有地方找到它。手头没有的话也可以先试试root/dev/sda2这种设备路径写法虽然不够优雅但应急时候先让它起来比啥都强。这种方式没走grub.cfg也没加载normal完全绕过配置文件直接把内核指定出来。只要GRUB能认读文件系统、能加载vmlinuz基本就能把你弄进系统。进系统的瞬间先深呼吸因为接下来才是真正的修复。2.4 LVM、UEFI和RAID机器上的变体上面这套流程默认是BIOS引导、boot分区独立的情况。如果机器使用了LVM或者UEFI操作还会有变化。LVM场景下根分区很可能在逻辑卷里。手动引导前先加载lvm模块grub rescue insmod lvm grub rescue ls (lvm/vg_root-lv_root)/看到能列出文件后set root和linux参数里就要写(lvm/vg_root-lv_root)这样的逻辑卷路径而不是(hd0,msdos2)这种物理分区路径。之前遇到过同事没加载lvm模块直接按物理分区引导结果error: unknown filesystem卡了一下午。UEFI引导的机器则不同。GRUB的配置文件和EFI分区相关rescue模式下需要先找到EFI分区一般是(hd0,gpt1)之类然后set prefix(hd0,gpt1)/EFI/centos再insmod normal和normal。如果你机器本身是UEFI还按BIOS的(hd0,msdos1)去写prefix永远指向错误位置。3. 进系统只是第一步把引导修复到能正常重启才算完事3.1 先别高兴重建grub.cfg是绕不开的重点手动引导成功进了系统千万别直接重启。你现在只是把系统拉起来看了一圈grub.cfg该坏的还是坏的引导模块该不兼容的还是不兼容。此时必须进系统把GRUB配置和相关文件整个重做一遍才算真正治好。先确认当前状态uname -r df -h /boot cat /etc/fstab看当前内核是什么版本boot剩余空间还有多少以及各分区挂载关系。如果/boot使用率已经90%以上那第一步不是重建配置而是先给boot分区腾地方否则你重建grub.cfg的时候脚本照样半途而废。这里插一个经验修这台机器时千万不要反复执行grub2-mkconfig但不grub2-install只改配置文件、不重写引导块下次一断电很可能又回rescue模式。配置和引导块是两个层面的东西得一起处理。3.2 chroot环境搭建与boot分区清理如果系统能正常登录直接root操作就行如果系统都进不了图形终端需要用安装U盘进rescue环境那就要靠chroot。以安装U盘救援模式为例进入shell后先挂载根分区和boot分区mkdir /mnt/sysroot mount /dev/sda2 /mnt/sysroot mount /dev/sda1 /mnt/sysroot/boot如果根分区是LVM先激活卷组vgchange -ay mount /dev/vg_root/lv_root /mnt/sysroot然后再挂载系统信息目录并chrootmount --bind /proc /mnt/sysroot/proc mount --bind /dev /mnt/sysroot/dev mount --bind /sys /mnt/sysroot/sys chroot /mnt/sysrootchroot进去之后很多人容易忘一个东西如果boot分区本来没挂上在chroot里光看/boot下面空空如也以为文件全丢了其实是没挂载。上面第二步就是为了避免这种“假丢文件”的惊吓。接下来清理旧内核。查看已装内核rpm -qa | grep ^kernel一般情况下保留正在用的这个和最新安装的一个就够了剩下的直接删rpm -e kernel-3.10.0-xxx.el7.x86_64删的时候注意别把当前运行的内核删了。删完再df -h /boot看一眼空间释放完再做下一步。3.3 重建initramfs和安装GRUB空间清理完先重建当前内核的initramfs防止升级过程中initramfs文件本身残缺dracut -f-f参数表示强制覆盖现有initramfs镜像。执行完看一眼输出有没有报错没报错继续。接着重建grub.cfggrub2-mkconfig -o /boot/grub2/grub.cfg这一步会把当前存在的所有内核都扫描一遍生成对应的menuentry。正常的输出里会看到Found linux image: /boot/vmlinuz-xxx、Found initrd image: /boot/initramfs-xxx.img这样的行。如果这些行一个都没出现说明GRUB根本没扫到内核文件多半是boot分区没挂载对检查一下再继续。最后重写引导块。BIOS引导的机器指定整块磁盘grub2-install /dev/sda这里写的是/dev/sda不是/dev/sda1GRUB的引导块要装到磁盘开头的保留扇区而不是某个分区里很多人写错成/dev/sda1装完照样引导不了。UEFI机器则是grub2-install --efi-directory/boot/efi之后还要用efibootmgr确认引导项里没有丢行丢了就手动加一个。3.4 重启前的验证清单不验证就重启是修复的大忌。我一般按下面这份清单检查确认无误才敢重启检查项命令预期结果当前内核uname -r显示一个实际存在的内核名boot分区空间df -h /boot使用率低于80%grub.cfg里有正确entrysed -n /menuentry /p /boot/grub2/grub.cfg至少看到两个可用内核条目默认启动项存在grub2-editenv listsaved_entry指向一个存在的菜单项引导块已写入dd if/dev/sda bs512 count1 | file -能识别出GRUB相关数据这里grub2-editenv list很多人会忽略它显示的saved_entry如果指向一个不存在的菜单条目重启后会黑屏或者停在菜单上不动。发现不对就重新grub2-mkconfig或者手动grub2-set-default一下。4. 预防永远比修复省心内核升级的安全操作与应急预案4.1 升级前三分钟检查经历过grub rescue的黑暗时刻之后我给自己定了三条升级前的检查纪律这三条花不了三分钟但能省掉一晚上的折腾。第一条看boot空间。执行df -h /boot剩余空间低于200MB就先清理旧内核再升级别硬塞。第二条想着备份grub配置。把当前正常的grub.cfg备份一份到系统里cp /boot/grub2/grub.cfg /root/grub.cfg.bak一旦升级完重启进rescue你至少有一个已知可用的配置可以在救援模式下对照。第三条确认系统里至少保留一个当前版本的旧内核也就是说升级时不急着把旧内核一起删掉留着它当退路。新内核起不来了旧内核还能顶。4.2 正确升级内核的姿势很多人误以为内核升级就是一条yum update全搞定在CentOS 7.7上想稳妥一点还是分步走更稳。先升级内核包但不重启yum update kernel或者指定新内核版本安装yum install kernel-3.10.0-1160.el7.x86_64装完之后先手动重新生成initramfs和grub配置dracut -f grub2-mkconfig -o /boot/grub2/grub.cfg这两步做了就相当于把内核包安装脚本里容易出问题的部分单独又强化了一遍。再执行grub2-install /dev/sda把引导块干脆利落地重写一次。最后确认默认引导项grub2-set-default 0 grub2-editenv list这样折腾过一遍再重启升级内核就只是换个内核文件而已翻车概率低到可以忽略。用第三方内核源的时候更要谨慎。第三方大版本内核和CentOS 7.7自带的GRUB配合有时不是那么丝滑装之前先看看源里对应的grub2相关包版本有更新就一起升。装完第三方内核后如果第一次重启进rescue别在rescue里死蹲直接按第2章手动引导然后进去把grub配置重建一遍别给它第二次教育你的机会。4.3 冷备一个救援U盘再讲一个“防呆”的法子准备一个CentOS 7.7的安装U盘。用安装U盘启动时不选Install而是选Troubleshooting里的Rescue a CentOS system它会自动发现系统并提供一个可用的shell环境。就算系统盘被整到GRUB都认不出来U盘依然能从自身启动进入救援环境挂载硬盘做chroot修复。很多同学平时根本不准备这东西真出问题只能求爷爷告奶奶找人送U盘实属没必要。U盘不用天天带着放在你维护的服务器机柜旁边或者抽屉里关键时候它就是你最后的稻草。4.4 我给自己定的几条纪律最后分享几条我在实际跑了几年CentOS之后立下的规矩不算什么高深理论但每条后面都是教训堆出来的。内核升级永远选在业务低峰期手里有远程管理卡或者带外通道再动别挑周五傍晚手痒痒去升级。升级前必看/boot空间和现有内核列表这是机器翻车之后代价最小的一道保险。升级完不急着删除旧内核至少隔一周、确认系统运行稳定之后再清理。修GRUB这类问题所有操作都先想清楚再做别在一个干净环境里凭感觉瞎试命令GRUB的配置和引导是环环相扣的一步错了下一步就是新坑。如果你现在正在rescue模式里按照第2章手动引导先起来再用第3章的流程修复一遍这台机器的命基本就捡回来了。以后升级内核别急着点确认多看一眼分区空间多敲一条备份命令很多惊吓其实根本轮不到你经历。