开机屏幕上突然跳出grub提示符或者一行grub minimal bash like line editing is supported再不就是直接黑屏只剩个光标在闪——经历过银河麒麟V10系统grub崩溃的朋友应该都懂那种“心里一沉”的感觉。更让人头大的是麒麟系统的引导结构虽然和主流Linux发行版同源但在细节上又有不少自己的脾气网上搜到的Ubuntu修复教程经常不能直接照搬。这篇文章就是我自己的完整急救记录和踩坑总结。从制作救援光盘/U盘开始到进入救援环境、chroot修复grub、重建引导配置再到把最常见的报错一条条拆开来看最后是能直接拿去用的排查速查表。不管你是在x86台式机上装的双系统还是用兆芯、海光、鲲鹏、飞腾这些国产平台的机器思路基本通用命令我会尽量给到可以直接“抄作业”的程度。这篇文章适合谁看系统运维、单位信息中心的技术人员、实验室管理员、还有自己折腾银河麒麟不小心把引导弄挂的桌面用户。哪怕你现在还没遇到问题我也建议收藏——grub这东西真出问题时往往连系统都进不去手边没有靠谱参考是真的很被动。1. grub崩溃的常见场景与根因分析1.1 先对号入座你遇到的到底是哪种故障现象grub崩溃不是一个固定表现不同的损坏程度对应的症状差别很大。我按自己遇到和帮同事处理过的案例把常见现象分成了几类开机直接进grub交互提示符这算“半死”状态grub本体还在只是找不到配置文件或引导文件位置不对。系统内核其实还在硬盘里只是没人告诉grub该去哪里加载它。grub rescue提示符比上面更严重grub的核心模块加载不完整只能执行ls、set、insmod这些最基础命令。这个阶段往往意味着/boot/grub里的模块文件损坏或者grub被装错位置了。黑屏或只显示GRUB字样后卡死常见于grub第一阶段代码写入引导扇区/EFI分区后第二阶段文件找不到的情况或者显卡驱动在启动早期就出了问题干扰了显示。No bootable device found、Operating system not found这类提示经常被误认为硬盘坏了实际是引导记录完全丢失或者BIOS/UEFI启动项被清掉了。开机直接进Windows或者其他系统双系统用户最容易遇到重装Windows或者其他系统后把硬盘开头的引导区域整个覆盖grub不再参与启动。拿到故障机器第一步不是急着敲命令而是先判断是“grub损坏”还是“启动项丢失”这两者的修复路径完全不同。判断方法很简单看开机时能不能进固件设置、启动菜单里还有没有Linux的入口、有没有grub类提示符出现。有grub说明引导程序本身还活着只是配置坏了连grub都没出现就要考虑引导项或者分区表层面的问题了。1.2 崩了之后别急着重装先搞明白是什么把它搞崩的处理过几十次grub故障之后我的经验是最危险的往往不是grub坏了本身而是“不知道为什么坏的”就开始乱操作。常见元凶其实就那么几类挨个排查反而效率更高内核升级中断麒麟系统在线更新内核时断电、强行关机、磁盘空间不足都可能导致/boot下的内核镜像和initrd文件是半成品或者grub配置没有及时更新。这列排在首位是因为真不少人就是在“更新软件”之后重启就挂了。误操作覆盖引导记录双系统机器上重装Windows、用第三方分区工具“自动修复引导”、或者手滑在DiskGenius里执行了“重建主引导记录”功能都会覆盖掉grub写入MBR或EFI分区的内容。手动改grub配置改坏了有些同学喜欢折腾主题、调启动参数直接编辑/boot/grub/grub.cfg。这个文件是update-grub自动生成的手动改完一旦语法错误开机就直接进grub。grub被安装到错误位置在某些修复教程的误导下把grub装进了某个分区里比如grub-install /dev/sda1而GRUB Legacy时代“装到分区”是可行的GRUB2时代如果你不是特别清楚自己在做什么这样干反而制造麻烦。正确目标应该是MBR硬盘的设备节点如/dev/sda或UEFI下的EFI分区。分区表变化用分区工具调整过/boot分区大小、移动过分区位置、或从Legacy启动改成UEFI启动后没有重装grub分区UUID对不上了自然就找不到内核。先判断原因再动手能省掉后面80%的折腾。尤其提醒一句先备份数据再谈修复。虽然grub修复本身不触碰用户数据但如果你的问题根源其实是硬盘坏道或者分区表损坏修复过程中的挂载、fsck操作有可能让情况更复杂。有重要数据的机器先把硬盘拆下来挂到别的机器上做镜像备份再回来修引导这是最稳妥的顺序。2. 救援前的准备工具、镜像与关键信息记录2.1 到底用光盘还是U盘救援介质准备指南标题里写的是“光盘救援”但现在大多数机器连光驱都没有。光盘和U盘在救援这件事上本质没有区别它们都只是把一份独立的Linux系统带到你面前。核心思路是让机器先从一个不依赖硬盘上操作系统的环境启动然后我们去“修理”硬盘里那个起不来的系统。首选方案是用银河麒麟V10的安装镜像ISO。你到麒麟官方或单位软件仓库下载对应版本的ISO就行不需要非得是“救援版”普通安装镜像里的“试用系统”功能就完全够用。下载时注意区分x86版本和ARM版本镜像架构必须和原系统一致否则后面chroot进去会直接报“cannot execute binary file”。制作启动盘的工具Windows下用Rufus就行写入模式选DD镜像模式不是ISO模式实测兼容性最好。Linux环境下更简单直接把ISO写进U盘sudo dd ifKylin-Desktop-V10-SP1-xxxx.iso of/dev/sdX bs4M statusprogress sync注意of后面必须是U盘设备节点不是分区如/dev/sdb而不是/dev/sdb1。千万别写错设备名把系统盘覆盖了可就真的是“整个盘重做”了。如果机器支持也可以试试开机按F12/F2/F10不同品牌不一样进一次性启动菜单临时选择从U盘启动不改动BIOS里的启动顺序这样修复完重启拔掉U盘就恢复原状。2.2 动手前先摸清家底要记录哪些关键信息修复grub最怕的是两眼一抹黑进入救援环境后看到一堆/dev/sda、/dev/nvme0n1p2完全不知道哪个分区对应系统里的什么目录。所以动手前花两分钟记录以下信息能让你之后的操作清晰很多一是引导模式。开机进BIOS/UEFI设置界面看在Boot选项中启动模式是Legacy传统BIOS还是UEFI。怎么看如果启动盘正好创建了EFI分区通常是FAT32格式、挂载在/boot/efi、里面有EFI目录那就是UEFI模式如果硬盘上是MBR分区表且没有EFI分区大概率是Legacy。这个判断直接决定后面grub-install往哪里写引导代码。二是系统盘大致布局。如果机器还能进系统用lsblk -f和blkid把各分区UUID记录下来。特别留意根分区/是哪个、/boot独不独立、EFI分区是哪个设备。三是系统原版本信息。麒麟系统的版本号比如V10 SP1还是V10 SP2、桌面环境UKUI、内核版本方便从镜像恢复后确认修复是否完整。如果机器已经彻底进不去系统这些信息怎么拿只有一个办法把硬盘拆下来挂到另一台正常电脑上用lsblk -f查看。如果你不方便拆盘也可以直接从救援环境本身入手——后面会讲到一旦能从U盘启动分区的识别就不难了。3. 进入救援环境从光盘/U盘启动并到达chroot门口3.1 从安装介质启动并进入“试用系统”用制作好的U盘或光盘启动机器看到银河麒麟的安装欢迎界面后注意界面上通常会有两个选项一个是“安装系统”另一个是“试用系统”不同版本可能叫“Try Kylin”或者“体验模式”。这里要选试用系统。这个模式的本质是把U盘/光盘上的麒麟系统完整加载到内存里运行不会碰硬盘上的任何数据但它能看到硬盘上的所有分区——这正是我们“救火”所需要的环境。如果你下载的镜像版本里找不到“试用”入口或者grub菜单直接没有这个选项还有一条路在引导菜单里按e编辑引导参数找到以linux开头的那一行在末尾加上systemd.unitrescue.target或者singleCtrlX启动后也能进入急救环境。不过这个方法对操作水平要求稍高新手优先还是找带试用模式的完整ISO更省事。启动进入试用系统桌面后或直接在命令行界面打开终端先确认一下能看到硬盘lsblk -f这条命令会把所有硬盘、分区、文件系统类型、UUID一口气列出来。到这里救援环境的第一步就算迈出去了。3.2 chroot前的路径规划先挂载再动刀我现在假设你已经用lsblk -f看清了硬盘分区布局举例来说系统盘是/dev/sda其中/dev/sda1是EFI分区FAT32/dev/sda2是根分区ext4没有单独的/boot分区——这是大多数银河麒麟V10 x86桌面版常见的分配方式。如果你的机器是单独的/boot分区、或者根分区是LVM、或者是NVMe固态硬盘设备名是/dev/nvme0n1pX的形式思路一样仅设备名不同。接下来的操作要按顺序来先挂载根分区再挂载EFI分区然后为chroot准备必需的虚拟文件系统# 1. 挂载根分区 sudo mount /dev/sda2 /mnt # 2. 如果/boot是独立分区要先挂载它无独立/boot可跳过 # sudo mount /dev/sda3 /mnt/boot # 3. UEFI模式下挂载EFI分区Legacy模式无此步骤 sudo mount /dev/sda1 /mnt/boot/efi # 4. 准备chroot所需的虚拟文件系统 sudo mount --bind /dev /mnt/dev sudo mount --bind /proc /mnt/proc sudo mount --bind /sys /mnt/sys sudo mount --bind /run /mnt/run # 5. 如果使用UEFI还需要挂载efivarfs sudo mount -t efivarfs efivarfs /mnt/sys/firmware/efi这里解释一下为什么第4步这么重要。chroot进去之后修复grub需要执行grub-install、update-grub这些命令要和硬件设备交互、要读取系统状态。如果不把/dev、/proc、/sys这些内核提供的界面绑进去很多操作会莫名其妙地失败。第5步的efivarfs是UEFI模式特有的它让修复程序能直接读写UEFI启动项变量。少了这一步grub-install对UEFI机器可能能装成功但重启后发现在启动菜单里根本没有Linux的入口。挂载完成后先别急着chroot做一次检查ls /mnt/boot/grub/ 2/dev/null || echo grub目录不存在 ls /mnt/etc/fstab第一个命令看grub目录还在不在第二个确认根分区的挂载没有搞错对象。确认无误后chroot进去sudo chroot /mnt /bin/bash现在你面前的终端已经不是U盘里那个试用系统了而是进入了硬盘上原本那个银河麒麟系统的文件系统——虽然它是一个没有运行的“静态世界”但你可以在里面执行几乎任何原系统内的命令。这个过程就是修复grub的核心舞台。4. 核心修复chroot环境下重装grub与重建引导配置4.1 为什么非要用chroot一个生活化的类比把chroot想象成一次“隔空手术”。病人是硬盘里那个起不来的系统手术室是U盘上的试用系统。你不能直接把病人搬进手术室全程操作因为他的循环系统内核与设备是停摆的。chroot相当于只把“病人的器官”文件系统接上了生命维持设备同时医生的手也能伸进去操作但外面的血液USB系统内核和里面的器官互不干扰。在Linux世界里chroot让我们能够使用目标系统自己的工具程序grub-install、update-grub来处理它自己的配置。为什么不能直接在试用系统里敲grub-install指向那个分区理论上有些场景也可以但会遇到两个麻烦一是试用系统的grub版本和目标系统的grub版本可能不一样生成出来的配置文件可能存在兼容差异二是grub-install需要读取目标系统的/etc/default/grub等配置不在chroot里执行这些配置找不全。所以规规矩矩走chroot流程是故障率最低的修复路径。4.2 UEFI x86平台的标准修复流程进入chroot后按顺序执行以下命令。我这里注释写清楚每一步在干什么方便你对号入座# 1. 确认当前所在环境应该显示/mnt pwd # 2. 重新安装grub到硬盘 # UEFI模式目标是EFI系统分区所在磁盘 grub-install /dev/sda # 3. 重新生成grub.cfg update-grub # 4. 退出chroot环境 exit # 5. 卸载所有挂载点重启 sudo umount -R /mnt sudo reboot执行grub-install时要注意UEFI模式下目标是磁盘设备/dev/sda而不是EFI分区/dev/sda1命令里也可以不写设备名只写grub-install让它探测但指定设备更明确、不容易装错盘。这个命令做的事情是把grub核心模块复制到EFI分区里的EFI/麒麟目录下同时生成一个UEFI启动项把引导的“契约”重新签好。update-grub这条命令本质是grub-mkconfig -o /boot/grub/grub.cfg的封装它会扫描/boot下的内核文件扫描系统里的其他操作系统按/etc/default/grub里的参数和/etc/grub.d/里的脚本重新生成一份全新的grub.cfg。这也是为什么我们前面强调“手动改grub.cfg容易出问题”——因为一旦跑update-grub你手动改的内容会被完全覆盖不留痕迹。4.3 Legacy BIOS模式的差异别把引导装进分区里如果你的机器是传统BIOSLegacy/MBR模式启动修复命令略有不同# 进入chroot # 安装grub到主引导记录MBR grub-install /dev/sda # 生成配置 update-grub看起来命令一样但原理完全不同。Legacy模式下grub-install 会把第一阶段代码写入硬盘0号扇区MBR区接着是512字节之后的一段gap里写后续代码和配置地址。需求对磁盘是“最少要有31KB的MBR间隙空间”现在绝大多数分区工具默认留下的空间都够用。注意目标是/dev/sda不是/dev/sda1。把grub装进分区比如grub-install /dev/sda1在多系统环境下可能引发连锁问题除非你是真的需要把另一个grub作为链式引导入口否则不要这么干。Legacy模式下如果grub-install报错说“embedding is not possible, but GRUB can still be installed in a cross-disk fashion”之类通常就是MBR后面留给grub的空间不够解决办法是调整分区起点把第一个分区往后挪但这个操作有一定风险需要借助GParted这类工具先做无损分区调整后再修复。如果你对分区调整不熟宁可维持原状也别轻易动分区表。4.4 修复完必做的一件事验证引导文件真的存在很多人执行完grub-install和update-grub就着急重启结果还是在原地打转然后怀疑操作有问题。其实很可能修复本身是成功的但缺少了验证这一步没发现EFI分区里其实没写入东西。UEFI模式下修复完成后检查一下ls /mnt/boot/efi/EFI/正常情况下你会看到麒麟或ubuntu目录里面应该有grubx64.efi或shimx64.efi文件。另外还可以用efibootmgr -v查看UEFI启动项里是否多了一条指向这个efi文件的记录。没有的话可以手动添加启动项efibootmgr -c -d /dev/sda -p 1 -L Kylin -l \\EFI\\kylin\\grubx64.efiLegacy模式下验证稍微简单点确认执行grub-install时没有报错然后重启前可以看一眼/boot/grub/grub.cfg文件的大小正常情况应该有几十KB取决于系统里装了多少内核、多少个启动菜单条目。只有几KB甚至几百字节多半是内核扫描没找到要回头检查根分区挂载对不对、/boot下是不是空目录。5. 核心修复的进阶场景与新手翻车点5.1 用ISO里自带的“救援模式”能不能偷懒严格来说银河麒麟的安装ISO默认没有像RHEL那样独立的“Rescue a system”菜单项最接近的就是我们前面讲的“试用系统”。但从V10 SP1开始有些版本的引导菜单里会出现“Install Kylin”之外的“Advanced Options”之类的子菜单里面可能藏着内存测试工具或者救援相关入口。如果你在菜单里看到了rescue相关选项直接选它然后按提示选择语言、键盘布局、根分区系统会自动帮你挂载好并进入chroot能省掉手工挂载那几步。不过自动救援模式也经常翻车——它探测根分区时可能选错尤其机器上有多个系统或多个类似分区时挂载完成后你发现chroot进去的并不是你要修的那个系统。所以我的建议是自动救援可以用但进去之后先lsblk检查挂载的是不是目标系统不对就退出手动来。自动捷径反而容易在不该省事的地方省出事。5.2 双系统机器修完grub后Windows消失怎么办这个问题排在我收到求助的前三名。重装grub、update-grub执行完重启开机菜单里只有麒麟Windows的启动项不见了。这通常分两种情况一种是Windows还在硬盘上只是update-grub没扫到它。原因可能是Windows的EFI分区残留在某个小分区里而grub的os-prober扫描默认在某些配置下不启用。检查一下/etc/default/grub里有没有GRUB_DISABLE_OS_PROBERtrue这一行有就改成GRUB_DISABLE_OS_PROBERfalse然后重新update-grub。另一种情况是Windows其实已经被破坏——比如你在grub修复前用分区工具误删了Windows所在分区。这种情况神仙也救不回来除非你在删除前做过分区镜像。所以我反复强调grub修复本身不删数据但所有硬盘操作的失误都可能演变成数据灾难操作前一定想清楚分区对应关系。5.3 ARM平台鲲鹏、飞腾、麒麟的修复差异银河麒麟V10有大量ARM版本部署在信创整机上grub修复逻辑和x86基本一致但有两个明显区别第一设备名称可能不同。ARM主板的硬盘可能是/dev/nvme0n1也可能是/dev/mmcblk0甚至还有SATA控制器后接的盘。用lsblk -f看清楚再动手不要条件反射地认为第一块盘一定是/dev/sda。第二UEFI固件对启动项的依赖更重。有些ARM主板固件只认固定路径的efi文件比如/EFI/BOOT/BOOTAA64.EFI如果你原来的系统用的文件名不是这个grub-install默认安装路径可能不被固件识别。解决办法是先看原系统在EFI分区里的目录结构再决定是否要手工复制一份到BOOT目录。ARM平台还有一个常见问题固件里没有启动项的“删除”概念修复装了几次grub后启动菜单里会累积好几条同名项每次开机要手动选。可以用efibootmgr调整顺序-o参数或删除多余项-B参数但这个操作需要谨慎删错了可能连引导入口都没了。6. 常见报错与排查技巧实录6.1 grub minimal bash like line editing is supported 到底怎么救这个报错绝对是所有grub故障里出现频率最高的。它的完整提示一般是grub minimal bash like line editing is supported. For the first word, TAB lists possible command completions. Anywhere else TAB lists possible device or file completions.然后停在grub提示符。这个报错的本质是grub找不到/boot/grub/grub.cfg配置文件也没法从预设的root设备位置找到内核文件于是掉进了最小交互环境。造成的原因多半是分区UUID变了比如调整过分区、grub的root变量指向的设备和实际系统所在设备不一致。临时启动法如果只是想让系统尽快起来然后在系统里跑完整修复可以在grub提示符下手动指定引导参数# 1. 列出所有分区找到Linux根分区 grub ls # 会显示类似 (hd0,gpt2)、(hd0,gpt1) 这样的设备列表 # 2. 逐个试探找对包含/boot/vmlinuz的分区 grub ls (hd0,gpt2)/ # 看到 boot/、etc/、usr/ 等目录就对了 # 3. 设置根分区并加载内核 grub set root(hd0,gpt2) grub linux /boot/vmlinuz-你的内核版本号 root/dev/sda2 grub initrd /boot/initrd.img-你的内核版本号 grub boot内核版本号在哪看在grub里可以按Tab键补全输linux /boot/vmlinuz-然后按Tabgrub会列出所有匹配的文件名非常方便。手动引导进入系统后再按第4章的流程执行grub-installupdate-grub完成彻底修复。彻底修复法如果手动引导能进系统问题大概率是配置文件丢失或UUID不匹配直接进chroot重装grub即可。如果你不想进系统直接走第3、4章的U盘救援流程一步到位。6.2 执行 normal 命令后没反应或者还是grub提示符有些教程会教你在grub下执行normal说这样能“退出最小模式”。但这个命令的前提是grub的正常模块normal.mod存在且能加载。如果你执行normal后屏幕闪了一下又回到grub多半是/boot/grub/i386-pc/x86 Legacy或对应的模块目录损坏、不完整或者是grub根目录设置不对。这种情况下别恋战直接走U盘救援。这也说明了为什么“手写几个命令救grub”的方法只适合临时应急——它能让你起来一次但如果模块文件本身坏了每次开机你都要手动引导很痛苦。真正的解决思路永远是用一个健康的系统环境重装grub本体修复文件而不是迷恋在grub命令行里做手动引导。6.3 grub-install 报了 “failed to get canonical path of /dev/sda”这个报错我遇到时一度以为是设备不存在折腾半天才发现是chroot后设备节点没有正确映射。也就是挂载/dev那步没做或者绑错了。回到救援环境重新检查ls -la /mnt/dev/sda如果看不到设备文件说明绑挂失败重新执行sudo mount --bind /dev /mnt/dev sudo mount --bind /proc /mnt/proc sudo mount --bind /sys /mnt/sys sudo mount --bind /run /mnt/run另外还有一种可能你chroot进去的系统本身设备管理器不完整比如之前误删过 /dev 下的文件那就比较麻烦可以有条件地把原系统的/lib/modules和/boot备份出来直接在试用系统的chroot里用救援工具处理不过这种情况比较少见。6.4 /boot/grub/grub.cfg 文件找不到了如果你发现/boot/grub/grub.cfg整个文件没了这就好办了——反正它本来就是自动生成的重新生成就完事了。进chroot后执行update-grub如果没有update-grub命令直接用它的底层命令grub-mkconfig -o /boot/grub/grub.cfg在执行前先检查/etc/default/grub里的参数是否符合预期特别是GRUB_TIMEOUT、GRUB_CMDLINE_LINUX、GRUB_DEFAULT这几个重要字段。顺带说一个细节update-grub扫描系统时通常会调用os-prober如果这个组件缺失双系统里的Windows项就不会出现。缺了的话装一下apt install os-prober update-grub6.5 修复成功但重启后还是进不去系统这是最让人崩溃的命令全部执行成功没有报错但重启还是在原地打转。排查方向有这么几个启动顺序没改BIOS/UEFI仍然把U盘或Windows Boot Manager排在Linux前面。进固件设置把Linux引导项调上来。UEFI启动项有冗余或错乱用U盘进入试用系统执行efibootmgr -v看当前启动项列表确认Linux入口指向的efi文件路径存在或者用efibootmgr -o重排顺序。grub安装到了错误的盘典型场景是机器上有多块硬盘系统装在/dev/sdb而grub-install把引导写进了/dev/sda的MBR/EFI分区结果BIOS引导的第一块盘根本没有grub。内核实则没有安装进 /boot修复grub只是找回了“开门的钥匙”如果门后面根本没有内核比如/boot分区损坏或者内核文件被误删grub菜单能出现但选“启动”的瞬间就会报错。这种要靠重新安装内核解决进chroot后apt install --reinstall linux-image-版本号。根分区挂载参数错误如果重启后能进grub菜单但选内核后卡在“waiting for /dev/sda2”之类多半是/etc/fstab里写的分区UUID和实际不符。回到救援环境blkid对比一下改fstab。6.6 其他容易踩的坑磁盘命名漂移与分区表残留硬盘在故障前后设备名发生变化sda变sdb是很常见的事。很多老教程会在grub配置里硬编码设备名但现代Linux内核和grub都推荐用UUID定位分区为的就是避免这个问题。如果你发现修复好的系统偶尔能启动、偶尔不能且报错信息和设备名相关就重点检查/etc/fstab和/boot/grub/grub.cfg里使用的到底是UUID还是设备名。还有一种情况机器上原来有旧系统的grub残留新装的麒麟grub装完后重启时被“旧grub → 新grub”链式引导绕晕了出现一些诡异的菜单组合。这种建议不要手工删分区先把新系统grub修好再用分区工具检查是否存在多份EFI系统分区确认哪一份是当前系统真正使用的。盲目格式化“看起来没用”的EFI分区可能会把引导彻底搞没。7. 总结与个人实践建议说实话grub修复这个事难度不在于命令多复杂而在于不同的机器、不同的安装方式、不同的故障原因组合出来的故障现场千奇百怪。同一个grub-install报错在这台机器上是EFI分区挂载问题在另一台机器上可能是磁盘设备名搞错了。所以这篇文章我刻意把排查思路放在命令前面——先搞清楚“为什么”再动手“怎么修”。我个人在实际操作中有两个习惯愿意分享给大家第一系统正常运行时就做好grub配置的备份。把/etc/default/grub、/boot/grub/grub.cfg、/etc/fstab这三个文件复制到U盘或者云盘上存一份grub出问题时拿出来对比就知道有哪些东西变了修复后也能确认配置是否恢复原样。第二准备一个写有修复命令的速查笔记。grub故障时人往往是慌的有笔记在手按步骤执行能避免很多“救火时头脑空白”的低级错误。下面的速查表是我对常见错误和排查要点的最终整理建议截图保存。故障现象可能原因排查/修复方向grub最小模式grub.cfg丢失/分区UUID变化手动引导临时进入系统再chroot重装grubgrub rescuegrub模块文件损坏必须用救援介质重装grubnormal无反应模块目录缺失直接用U盘/光盘进入试用系统修复No bootable device引导记录被覆盖/启动项丢失检查UEFI启动项或重装grub到MBRfailed to get canonical path/dev绑定挂载缺失重新 mount --bind /dev 后再试修复后Windows消失os-prober未运行或禁用开启GRUB_DISABLE_OS_PROBERfalse重跑update-grub修复后仍然无法启动启动顺序/装错设备/内核损坏检查efibootmgr、确认grub-install目标设备、重装内核ARM平台不进系统固件路径与grub安装路径不一致检查EFI分区目录复制efi文件到BOOTAA64.EFI对应路径最后再分享一个小技巧如果你的机器上恰好有一个能正常启动的另一个Linux系统哪怕装在U盘里grub修复的很多步骤可以在那个系统里直接对目标分区操作不需要专门下载麒麟的ISO。方法是在能启动的系统里挂载目标系统的根分区和EFI分区执行grub-install --boot-directory/mnt/boot /dev/sda手动指定引导目录位置效果和chroot里操作完全一样。这个方式在有Live USB的时候就特别顺手。但不管哪种方式动手前备份数据、记录分区信息永远都是最值得花的那几分钟。grub这个东西恢复一次之后你会对它熟悉很多但最好还是祈祷下次别再用到这份指南。真要用到时按步骤来、别慌、别乱敲命令系统大多都能救回来。 银河麒麟V10系统GRUB崩溃急救：从救援盘制作到chroot修复全流程
开机屏幕上突然跳出grub提示符或者一行grub minimal bash like line editing is supported再不就是直接黑屏只剩个光标在闪——经历过银河麒麟V10系统grub崩溃的朋友应该都懂那种“心里一沉”的感觉。更让人头大的是麒麟系统的引导结构虽然和主流Linux发行版同源但在细节上又有不少自己的脾气网上搜到的Ubuntu修复教程经常不能直接照搬。这篇文章就是我自己的完整急救记录和踩坑总结。从制作救援光盘/U盘开始到进入救援环境、chroot修复grub、重建引导配置再到把最常见的报错一条条拆开来看最后是能直接拿去用的排查速查表。不管你是在x86台式机上装的双系统还是用兆芯、海光、鲲鹏、飞腾这些国产平台的机器思路基本通用命令我会尽量给到可以直接“抄作业”的程度。这篇文章适合谁看系统运维、单位信息中心的技术人员、实验室管理员、还有自己折腾银河麒麟不小心把引导弄挂的桌面用户。哪怕你现在还没遇到问题我也建议收藏——grub这东西真出问题时往往连系统都进不去手边没有靠谱参考是真的很被动。1. grub崩溃的常见场景与根因分析1.1 先对号入座你遇到的到底是哪种故障现象grub崩溃不是一个固定表现不同的损坏程度对应的症状差别很大。我按自己遇到和帮同事处理过的案例把常见现象分成了几类开机直接进grub交互提示符这算“半死”状态grub本体还在只是找不到配置文件或引导文件位置不对。系统内核其实还在硬盘里只是没人告诉grub该去哪里加载它。grub rescue提示符比上面更严重grub的核心模块加载不完整只能执行ls、set、insmod这些最基础命令。这个阶段往往意味着/boot/grub里的模块文件损坏或者grub被装错位置了。黑屏或只显示GRUB字样后卡死常见于grub第一阶段代码写入引导扇区/EFI分区后第二阶段文件找不到的情况或者显卡驱动在启动早期就出了问题干扰了显示。No bootable device found、Operating system not found这类提示经常被误认为硬盘坏了实际是引导记录完全丢失或者BIOS/UEFI启动项被清掉了。开机直接进Windows或者其他系统双系统用户最容易遇到重装Windows或者其他系统后把硬盘开头的引导区域整个覆盖grub不再参与启动。拿到故障机器第一步不是急着敲命令而是先判断是“grub损坏”还是“启动项丢失”这两者的修复路径完全不同。判断方法很简单看开机时能不能进固件设置、启动菜单里还有没有Linux的入口、有没有grub类提示符出现。有grub说明引导程序本身还活着只是配置坏了连grub都没出现就要考虑引导项或者分区表层面的问题了。1.2 崩了之后别急着重装先搞明白是什么把它搞崩的处理过几十次grub故障之后我的经验是最危险的往往不是grub坏了本身而是“不知道为什么坏的”就开始乱操作。常见元凶其实就那么几类挨个排查反而效率更高内核升级中断麒麟系统在线更新内核时断电、强行关机、磁盘空间不足都可能导致/boot下的内核镜像和initrd文件是半成品或者grub配置没有及时更新。这列排在首位是因为真不少人就是在“更新软件”之后重启就挂了。误操作覆盖引导记录双系统机器上重装Windows、用第三方分区工具“自动修复引导”、或者手滑在DiskGenius里执行了“重建主引导记录”功能都会覆盖掉grub写入MBR或EFI分区的内容。手动改grub配置改坏了有些同学喜欢折腾主题、调启动参数直接编辑/boot/grub/grub.cfg。这个文件是update-grub自动生成的手动改完一旦语法错误开机就直接进grub。grub被安装到错误位置在某些修复教程的误导下把grub装进了某个分区里比如grub-install /dev/sda1而GRUB Legacy时代“装到分区”是可行的GRUB2时代如果你不是特别清楚自己在做什么这样干反而制造麻烦。正确目标应该是MBR硬盘的设备节点如/dev/sda或UEFI下的EFI分区。分区表变化用分区工具调整过/boot分区大小、移动过分区位置、或从Legacy启动改成UEFI启动后没有重装grub分区UUID对不上了自然就找不到内核。先判断原因再动手能省掉后面80%的折腾。尤其提醒一句先备份数据再谈修复。虽然grub修复本身不触碰用户数据但如果你的问题根源其实是硬盘坏道或者分区表损坏修复过程中的挂载、fsck操作有可能让情况更复杂。有重要数据的机器先把硬盘拆下来挂到别的机器上做镜像备份再回来修引导这是最稳妥的顺序。2. 救援前的准备工具、镜像与关键信息记录2.1 到底用光盘还是U盘救援介质准备指南标题里写的是“光盘救援”但现在大多数机器连光驱都没有。光盘和U盘在救援这件事上本质没有区别它们都只是把一份独立的Linux系统带到你面前。核心思路是让机器先从一个不依赖硬盘上操作系统的环境启动然后我们去“修理”硬盘里那个起不来的系统。首选方案是用银河麒麟V10的安装镜像ISO。你到麒麟官方或单位软件仓库下载对应版本的ISO就行不需要非得是“救援版”普通安装镜像里的“试用系统”功能就完全够用。下载时注意区分x86版本和ARM版本镜像架构必须和原系统一致否则后面chroot进去会直接报“cannot execute binary file”。制作启动盘的工具Windows下用Rufus就行写入模式选DD镜像模式不是ISO模式实测兼容性最好。Linux环境下更简单直接把ISO写进U盘sudo dd ifKylin-Desktop-V10-SP1-xxxx.iso of/dev/sdX bs4M statusprogress sync注意of后面必须是U盘设备节点不是分区如/dev/sdb而不是/dev/sdb1。千万别写错设备名把系统盘覆盖了可就真的是“整个盘重做”了。如果机器支持也可以试试开机按F12/F2/F10不同品牌不一样进一次性启动菜单临时选择从U盘启动不改动BIOS里的启动顺序这样修复完重启拔掉U盘就恢复原状。2.2 动手前先摸清家底要记录哪些关键信息修复grub最怕的是两眼一抹黑进入救援环境后看到一堆/dev/sda、/dev/nvme0n1p2完全不知道哪个分区对应系统里的什么目录。所以动手前花两分钟记录以下信息能让你之后的操作清晰很多一是引导模式。开机进BIOS/UEFI设置界面看在Boot选项中启动模式是Legacy传统BIOS还是UEFI。怎么看如果启动盘正好创建了EFI分区通常是FAT32格式、挂载在/boot/efi、里面有EFI目录那就是UEFI模式如果硬盘上是MBR分区表且没有EFI分区大概率是Legacy。这个判断直接决定后面grub-install往哪里写引导代码。二是系统盘大致布局。如果机器还能进系统用lsblk -f和blkid把各分区UUID记录下来。特别留意根分区/是哪个、/boot独不独立、EFI分区是哪个设备。三是系统原版本信息。麒麟系统的版本号比如V10 SP1还是V10 SP2、桌面环境UKUI、内核版本方便从镜像恢复后确认修复是否完整。如果机器已经彻底进不去系统这些信息怎么拿只有一个办法把硬盘拆下来挂到另一台正常电脑上用lsblk -f查看。如果你不方便拆盘也可以直接从救援环境本身入手——后面会讲到一旦能从U盘启动分区的识别就不难了。3. 进入救援环境从光盘/U盘启动并到达chroot门口3.1 从安装介质启动并进入“试用系统”用制作好的U盘或光盘启动机器看到银河麒麟的安装欢迎界面后注意界面上通常会有两个选项一个是“安装系统”另一个是“试用系统”不同版本可能叫“Try Kylin”或者“体验模式”。这里要选试用系统。这个模式的本质是把U盘/光盘上的麒麟系统完整加载到内存里运行不会碰硬盘上的任何数据但它能看到硬盘上的所有分区——这正是我们“救火”所需要的环境。如果你下载的镜像版本里找不到“试用”入口或者grub菜单直接没有这个选项还有一条路在引导菜单里按e编辑引导参数找到以linux开头的那一行在末尾加上systemd.unitrescue.target或者singleCtrlX启动后也能进入急救环境。不过这个方法对操作水平要求稍高新手优先还是找带试用模式的完整ISO更省事。启动进入试用系统桌面后或直接在命令行界面打开终端先确认一下能看到硬盘lsblk -f这条命令会把所有硬盘、分区、文件系统类型、UUID一口气列出来。到这里救援环境的第一步就算迈出去了。3.2 chroot前的路径规划先挂载再动刀我现在假设你已经用lsblk -f看清了硬盘分区布局举例来说系统盘是/dev/sda其中/dev/sda1是EFI分区FAT32/dev/sda2是根分区ext4没有单独的/boot分区——这是大多数银河麒麟V10 x86桌面版常见的分配方式。如果你的机器是单独的/boot分区、或者根分区是LVM、或者是NVMe固态硬盘设备名是/dev/nvme0n1pX的形式思路一样仅设备名不同。接下来的操作要按顺序来先挂载根分区再挂载EFI分区然后为chroot准备必需的虚拟文件系统# 1. 挂载根分区 sudo mount /dev/sda2 /mnt # 2. 如果/boot是独立分区要先挂载它无独立/boot可跳过 # sudo mount /dev/sda3 /mnt/boot # 3. UEFI模式下挂载EFI分区Legacy模式无此步骤 sudo mount /dev/sda1 /mnt/boot/efi # 4. 准备chroot所需的虚拟文件系统 sudo mount --bind /dev /mnt/dev sudo mount --bind /proc /mnt/proc sudo mount --bind /sys /mnt/sys sudo mount --bind /run /mnt/run # 5. 如果使用UEFI还需要挂载efivarfs sudo mount -t efivarfs efivarfs /mnt/sys/firmware/efi这里解释一下为什么第4步这么重要。chroot进去之后修复grub需要执行grub-install、update-grub这些命令要和硬件设备交互、要读取系统状态。如果不把/dev、/proc、/sys这些内核提供的界面绑进去很多操作会莫名其妙地失败。第5步的efivarfs是UEFI模式特有的它让修复程序能直接读写UEFI启动项变量。少了这一步grub-install对UEFI机器可能能装成功但重启后发现在启动菜单里根本没有Linux的入口。挂载完成后先别急着chroot做一次检查ls /mnt/boot/grub/ 2/dev/null || echo grub目录不存在 ls /mnt/etc/fstab第一个命令看grub目录还在不在第二个确认根分区的挂载没有搞错对象。确认无误后chroot进去sudo chroot /mnt /bin/bash现在你面前的终端已经不是U盘里那个试用系统了而是进入了硬盘上原本那个银河麒麟系统的文件系统——虽然它是一个没有运行的“静态世界”但你可以在里面执行几乎任何原系统内的命令。这个过程就是修复grub的核心舞台。4. 核心修复chroot环境下重装grub与重建引导配置4.1 为什么非要用chroot一个生活化的类比把chroot想象成一次“隔空手术”。病人是硬盘里那个起不来的系统手术室是U盘上的试用系统。你不能直接把病人搬进手术室全程操作因为他的循环系统内核与设备是停摆的。chroot相当于只把“病人的器官”文件系统接上了生命维持设备同时医生的手也能伸进去操作但外面的血液USB系统内核和里面的器官互不干扰。在Linux世界里chroot让我们能够使用目标系统自己的工具程序grub-install、update-grub来处理它自己的配置。为什么不能直接在试用系统里敲grub-install指向那个分区理论上有些场景也可以但会遇到两个麻烦一是试用系统的grub版本和目标系统的grub版本可能不一样生成出来的配置文件可能存在兼容差异二是grub-install需要读取目标系统的/etc/default/grub等配置不在chroot里执行这些配置找不全。所以规规矩矩走chroot流程是故障率最低的修复路径。4.2 UEFI x86平台的标准修复流程进入chroot后按顺序执行以下命令。我这里注释写清楚每一步在干什么方便你对号入座# 1. 确认当前所在环境应该显示/mnt pwd # 2. 重新安装grub到硬盘 # UEFI模式目标是EFI系统分区所在磁盘 grub-install /dev/sda # 3. 重新生成grub.cfg update-grub # 4. 退出chroot环境 exit # 5. 卸载所有挂载点重启 sudo umount -R /mnt sudo reboot执行grub-install时要注意UEFI模式下目标是磁盘设备/dev/sda而不是EFI分区/dev/sda1命令里也可以不写设备名只写grub-install让它探测但指定设备更明确、不容易装错盘。这个命令做的事情是把grub核心模块复制到EFI分区里的EFI/麒麟目录下同时生成一个UEFI启动项把引导的“契约”重新签好。update-grub这条命令本质是grub-mkconfig -o /boot/grub/grub.cfg的封装它会扫描/boot下的内核文件扫描系统里的其他操作系统按/etc/default/grub里的参数和/etc/grub.d/里的脚本重新生成一份全新的grub.cfg。这也是为什么我们前面强调“手动改grub.cfg容易出问题”——因为一旦跑update-grub你手动改的内容会被完全覆盖不留痕迹。4.3 Legacy BIOS模式的差异别把引导装进分区里如果你的机器是传统BIOSLegacy/MBR模式启动修复命令略有不同# 进入chroot # 安装grub到主引导记录MBR grub-install /dev/sda # 生成配置 update-grub看起来命令一样但原理完全不同。Legacy模式下grub-install 会把第一阶段代码写入硬盘0号扇区MBR区接着是512字节之后的一段gap里写后续代码和配置地址。需求对磁盘是“最少要有31KB的MBR间隙空间”现在绝大多数分区工具默认留下的空间都够用。注意目标是/dev/sda不是/dev/sda1。把grub装进分区比如grub-install /dev/sda1在多系统环境下可能引发连锁问题除非你是真的需要把另一个grub作为链式引导入口否则不要这么干。Legacy模式下如果grub-install报错说“embedding is not possible, but GRUB can still be installed in a cross-disk fashion”之类通常就是MBR后面留给grub的空间不够解决办法是调整分区起点把第一个分区往后挪但这个操作有一定风险需要借助GParted这类工具先做无损分区调整后再修复。如果你对分区调整不熟宁可维持原状也别轻易动分区表。4.4 修复完必做的一件事验证引导文件真的存在很多人执行完grub-install和update-grub就着急重启结果还是在原地打转然后怀疑操作有问题。其实很可能修复本身是成功的但缺少了验证这一步没发现EFI分区里其实没写入东西。UEFI模式下修复完成后检查一下ls /mnt/boot/efi/EFI/正常情况下你会看到麒麟或ubuntu目录里面应该有grubx64.efi或shimx64.efi文件。另外还可以用efibootmgr -v查看UEFI启动项里是否多了一条指向这个efi文件的记录。没有的话可以手动添加启动项efibootmgr -c -d /dev/sda -p 1 -L Kylin -l \\EFI\\kylin\\grubx64.efiLegacy模式下验证稍微简单点确认执行grub-install时没有报错然后重启前可以看一眼/boot/grub/grub.cfg文件的大小正常情况应该有几十KB取决于系统里装了多少内核、多少个启动菜单条目。只有几KB甚至几百字节多半是内核扫描没找到要回头检查根分区挂载对不对、/boot下是不是空目录。5. 核心修复的进阶场景与新手翻车点5.1 用ISO里自带的“救援模式”能不能偷懒严格来说银河麒麟的安装ISO默认没有像RHEL那样独立的“Rescue a system”菜单项最接近的就是我们前面讲的“试用系统”。但从V10 SP1开始有些版本的引导菜单里会出现“Install Kylin”之外的“Advanced Options”之类的子菜单里面可能藏着内存测试工具或者救援相关入口。如果你在菜单里看到了rescue相关选项直接选它然后按提示选择语言、键盘布局、根分区系统会自动帮你挂载好并进入chroot能省掉手工挂载那几步。不过自动救援模式也经常翻车——它探测根分区时可能选错尤其机器上有多个系统或多个类似分区时挂载完成后你发现chroot进去的并不是你要修的那个系统。所以我的建议是自动救援可以用但进去之后先lsblk检查挂载的是不是目标系统不对就退出手动来。自动捷径反而容易在不该省事的地方省出事。5.2 双系统机器修完grub后Windows消失怎么办这个问题排在我收到求助的前三名。重装grub、update-grub执行完重启开机菜单里只有麒麟Windows的启动项不见了。这通常分两种情况一种是Windows还在硬盘上只是update-grub没扫到它。原因可能是Windows的EFI分区残留在某个小分区里而grub的os-prober扫描默认在某些配置下不启用。检查一下/etc/default/grub里有没有GRUB_DISABLE_OS_PROBERtrue这一行有就改成GRUB_DISABLE_OS_PROBERfalse然后重新update-grub。另一种情况是Windows其实已经被破坏——比如你在grub修复前用分区工具误删了Windows所在分区。这种情况神仙也救不回来除非你在删除前做过分区镜像。所以我反复强调grub修复本身不删数据但所有硬盘操作的失误都可能演变成数据灾难操作前一定想清楚分区对应关系。5.3 ARM平台鲲鹏、飞腾、麒麟的修复差异银河麒麟V10有大量ARM版本部署在信创整机上grub修复逻辑和x86基本一致但有两个明显区别第一设备名称可能不同。ARM主板的硬盘可能是/dev/nvme0n1也可能是/dev/mmcblk0甚至还有SATA控制器后接的盘。用lsblk -f看清楚再动手不要条件反射地认为第一块盘一定是/dev/sda。第二UEFI固件对启动项的依赖更重。有些ARM主板固件只认固定路径的efi文件比如/EFI/BOOT/BOOTAA64.EFI如果你原来的系统用的文件名不是这个grub-install默认安装路径可能不被固件识别。解决办法是先看原系统在EFI分区里的目录结构再决定是否要手工复制一份到BOOT目录。ARM平台还有一个常见问题固件里没有启动项的“删除”概念修复装了几次grub后启动菜单里会累积好几条同名项每次开机要手动选。可以用efibootmgr调整顺序-o参数或删除多余项-B参数但这个操作需要谨慎删错了可能连引导入口都没了。6. 常见报错与排查技巧实录6.1 grub minimal bash like line editing is supported 到底怎么救这个报错绝对是所有grub故障里出现频率最高的。它的完整提示一般是grub minimal bash like line editing is supported. For the first word, TAB lists possible command completions. Anywhere else TAB lists possible device or file completions.然后停在grub提示符。这个报错的本质是grub找不到/boot/grub/grub.cfg配置文件也没法从预设的root设备位置找到内核文件于是掉进了最小交互环境。造成的原因多半是分区UUID变了比如调整过分区、grub的root变量指向的设备和实际系统所在设备不一致。临时启动法如果只是想让系统尽快起来然后在系统里跑完整修复可以在grub提示符下手动指定引导参数# 1. 列出所有分区找到Linux根分区 grub ls # 会显示类似 (hd0,gpt2)、(hd0,gpt1) 这样的设备列表 # 2. 逐个试探找对包含/boot/vmlinuz的分区 grub ls (hd0,gpt2)/ # 看到 boot/、etc/、usr/ 等目录就对了 # 3. 设置根分区并加载内核 grub set root(hd0,gpt2) grub linux /boot/vmlinuz-你的内核版本号 root/dev/sda2 grub initrd /boot/initrd.img-你的内核版本号 grub boot内核版本号在哪看在grub里可以按Tab键补全输linux /boot/vmlinuz-然后按Tabgrub会列出所有匹配的文件名非常方便。手动引导进入系统后再按第4章的流程执行grub-installupdate-grub完成彻底修复。彻底修复法如果手动引导能进系统问题大概率是配置文件丢失或UUID不匹配直接进chroot重装grub即可。如果你不想进系统直接走第3、4章的U盘救援流程一步到位。6.2 执行 normal 命令后没反应或者还是grub提示符有些教程会教你在grub下执行normal说这样能“退出最小模式”。但这个命令的前提是grub的正常模块normal.mod存在且能加载。如果你执行normal后屏幕闪了一下又回到grub多半是/boot/grub/i386-pc/x86 Legacy或对应的模块目录损坏、不完整或者是grub根目录设置不对。这种情况下别恋战直接走U盘救援。这也说明了为什么“手写几个命令救grub”的方法只适合临时应急——它能让你起来一次但如果模块文件本身坏了每次开机你都要手动引导很痛苦。真正的解决思路永远是用一个健康的系统环境重装grub本体修复文件而不是迷恋在grub命令行里做手动引导。6.3 grub-install 报了 “failed to get canonical path of /dev/sda”这个报错我遇到时一度以为是设备不存在折腾半天才发现是chroot后设备节点没有正确映射。也就是挂载/dev那步没做或者绑错了。回到救援环境重新检查ls -la /mnt/dev/sda如果看不到设备文件说明绑挂失败重新执行sudo mount --bind /dev /mnt/dev sudo mount --bind /proc /mnt/proc sudo mount --bind /sys /mnt/sys sudo mount --bind /run /mnt/run另外还有一种可能你chroot进去的系统本身设备管理器不完整比如之前误删过 /dev 下的文件那就比较麻烦可以有条件地把原系统的/lib/modules和/boot备份出来直接在试用系统的chroot里用救援工具处理不过这种情况比较少见。6.4 /boot/grub/grub.cfg 文件找不到了如果你发现/boot/grub/grub.cfg整个文件没了这就好办了——反正它本来就是自动生成的重新生成就完事了。进chroot后执行update-grub如果没有update-grub命令直接用它的底层命令grub-mkconfig -o /boot/grub/grub.cfg在执行前先检查/etc/default/grub里的参数是否符合预期特别是GRUB_TIMEOUT、GRUB_CMDLINE_LINUX、GRUB_DEFAULT这几个重要字段。顺带说一个细节update-grub扫描系统时通常会调用os-prober如果这个组件缺失双系统里的Windows项就不会出现。缺了的话装一下apt install os-prober update-grub6.5 修复成功但重启后还是进不去系统这是最让人崩溃的命令全部执行成功没有报错但重启还是在原地打转。排查方向有这么几个启动顺序没改BIOS/UEFI仍然把U盘或Windows Boot Manager排在Linux前面。进固件设置把Linux引导项调上来。UEFI启动项有冗余或错乱用U盘进入试用系统执行efibootmgr -v看当前启动项列表确认Linux入口指向的efi文件路径存在或者用efibootmgr -o重排顺序。grub安装到了错误的盘典型场景是机器上有多块硬盘系统装在/dev/sdb而grub-install把引导写进了/dev/sda的MBR/EFI分区结果BIOS引导的第一块盘根本没有grub。内核实则没有安装进 /boot修复grub只是找回了“开门的钥匙”如果门后面根本没有内核比如/boot分区损坏或者内核文件被误删grub菜单能出现但选“启动”的瞬间就会报错。这种要靠重新安装内核解决进chroot后apt install --reinstall linux-image-版本号。根分区挂载参数错误如果重启后能进grub菜单但选内核后卡在“waiting for /dev/sda2”之类多半是/etc/fstab里写的分区UUID和实际不符。回到救援环境blkid对比一下改fstab。6.6 其他容易踩的坑磁盘命名漂移与分区表残留硬盘在故障前后设备名发生变化sda变sdb是很常见的事。很多老教程会在grub配置里硬编码设备名但现代Linux内核和grub都推荐用UUID定位分区为的就是避免这个问题。如果你发现修复好的系统偶尔能启动、偶尔不能且报错信息和设备名相关就重点检查/etc/fstab和/boot/grub/grub.cfg里使用的到底是UUID还是设备名。还有一种情况机器上原来有旧系统的grub残留新装的麒麟grub装完后重启时被“旧grub → 新grub”链式引导绕晕了出现一些诡异的菜单组合。这种建议不要手工删分区先把新系统grub修好再用分区工具检查是否存在多份EFI系统分区确认哪一份是当前系统真正使用的。盲目格式化“看起来没用”的EFI分区可能会把引导彻底搞没。7. 总结与个人实践建议说实话grub修复这个事难度不在于命令多复杂而在于不同的机器、不同的安装方式、不同的故障原因组合出来的故障现场千奇百怪。同一个grub-install报错在这台机器上是EFI分区挂载问题在另一台机器上可能是磁盘设备名搞错了。所以这篇文章我刻意把排查思路放在命令前面——先搞清楚“为什么”再动手“怎么修”。我个人在实际操作中有两个习惯愿意分享给大家第一系统正常运行时就做好grub配置的备份。把/etc/default/grub、/boot/grub/grub.cfg、/etc/fstab这三个文件复制到U盘或者云盘上存一份grub出问题时拿出来对比就知道有哪些东西变了修复后也能确认配置是否恢复原样。第二准备一个写有修复命令的速查笔记。grub故障时人往往是慌的有笔记在手按步骤执行能避免很多“救火时头脑空白”的低级错误。下面的速查表是我对常见错误和排查要点的最终整理建议截图保存。故障现象可能原因排查/修复方向grub最小模式grub.cfg丢失/分区UUID变化手动引导临时进入系统再chroot重装grubgrub rescuegrub模块文件损坏必须用救援介质重装grubnormal无反应模块目录缺失直接用U盘/光盘进入试用系统修复No bootable device引导记录被覆盖/启动项丢失检查UEFI启动项或重装grub到MBRfailed to get canonical path/dev绑定挂载缺失重新 mount --bind /dev 后再试修复后Windows消失os-prober未运行或禁用开启GRUB_DISABLE_OS_PROBERfalse重跑update-grub修复后仍然无法启动启动顺序/装错设备/内核损坏检查efibootmgr、确认grub-install目标设备、重装内核ARM平台不进系统固件路径与grub安装路径不一致检查EFI分区目录复制efi文件到BOOTAA64.EFI对应路径最后再分享一个小技巧如果你的机器上恰好有一个能正常启动的另一个Linux系统哪怕装在U盘里grub修复的很多步骤可以在那个系统里直接对目标分区操作不需要专门下载麒麟的ISO。方法是在能启动的系统里挂载目标系统的根分区和EFI分区执行grub-install --boot-directory/mnt/boot /dev/sda手动指定引导目录位置效果和chroot里操作完全一样。这个方式在有Live USB的时候就特别顺手。但不管哪种方式动手前备份数据、记录分区信息永远都是最值得花的那几分钟。grub这个东西恢复一次之后你会对它熟悉很多但最好还是祈祷下次别再用到这份指南。真要用到时按步骤来、别慌、别乱敲命令系统大多都能救回来。