企业官网建设流程全解析

开机键按下去的那一瞬间，屏幕没有出现熟悉的麒麟Logo，取而代之的是一个灰底黑字的grub>提示符，后面跟着一行不太友好的英文说明：grub minimal bash like line editing is supported。如果你还见过error: file '/boot/grub2/i386-pc/normal.mod' not found、grub rescue>这种更恐怖的场面，说明你的银河麒麟V10系统引导加载器已经处在崩溃或半崩溃状态。

这篇指南就是围绕这个场景写的。我会用一次完整的“光盘救援 + chroot + 重建GRUB”流程，把银河麒麟V10从grub崩溃中拉回来，同时对grub minimal bash like line editing is supported、输入normal后不能启动、grub找不到cfg、U盘启动后root权限、单用户模式进入方法这些高频问题做逐一排查。明天上班要用的机器，不用急着重装系统，看完这条路径，大概率能自己救回来。

1. 先分清：grub>、grub rescue>和黑屏各代表哪一层坏了

很多人拿到一台grub崩溃的机器，第一反应就是“引导坏了，重装吧”。其实grub坏掉的形态有七八种，每一种对应的故障层级完全不同，盲目重装既费时间，还可能把原本没坏的数据盘也搭进去。我按实际维修中的出现频率，把崩溃现场分成四类，你先对照一下自己的屏幕。

1.1 四种崩溃形态与故障层级

这里先记住一个结论：只要还能进入grub>，你的GRUB主体通常还活着，修复难度最低；落到grub rescue>，说明GRUB连文件系统都认不出了，难度上了一个台阶；黑屏和直接进固件设置，问题往往不一定只在GRUB上，还要查内核、initrd和EFI引导项。

1.2 为什么银河麒麟V10的grub特别容易出问题

银河麒麟V10的引导体系继承自RHEL/CentOS那一套，用的是GRUB 2，配置目录在/boot/grub2，生成的主配置文件叫grub.cfg。它和Ubuntu的GRUB相比，有几个容易踩的差异点：

• 内核更新后，grub2-mkconfig不会自动重跑，需要手动执行，很多人跳过这一步直接重启，重启后grub菜单还引用旧内核文件，一旦旧内核文件被清理就崩。
• 系统盘如果用了LVM逻辑卷，GRUB需要依赖lvm模块才能读取根分区，换硬盘或克隆系统后模块路径变了，就出现unknown filesystem。
• 双系统场景下，Windows更新或重装会把MBR/EFI引导区覆盖掉，银河麒麟的grub入口被抹掉，开机直接进Windows或黑屏。
• 异常断电、强制关机导致grub.cfg写入一半，或者/boot所在分区出现坏块，同样会引发minimal bash。

1.3 判断这台机器是传统BIOS还是UEFI启动

在动手救援之前，先确认固件模式，因为后面所有命令都不一样。

• 开机进BIOS/UEFI设置，查看启动模式（Boot Mode）是Legacy还是UEFI。
• 如果原来系统盘上有一个几百MB的FAT32分区且挂着/boot/efi，就是UEFI启动。
• 如果整个磁盘只有一个/boot分区且没有EFI系统分区，大概率是传统BIOS。

银河麒麟V10在兆芯KX-6640MA这类国产x86平台的老主板上，经常默认走传统BIOS+MBR；在较新的飞腾、鲲鹏或Intel/AMD主板上则以UEFI+GPT为主。这两种模式的恢复命令差异很大，我会在第4章分别给出。

2. 从光盘/优盘进live桌面：救援环境准备与启动优先级排错

确认了grub状态和固件模式，下一步是准备一个能独立启动的救援环境。银河麒麟V10的官方ISO既能安装系统，也能进入一个临时的live桌面，这是修复grub的基础环境。手里没有安装镜像的话，先找一台能正常上网的机器，从银河麒麟官方渠道下载对应版本的ISO，注意桌面版和服务器版不要混用，x86和ARM也不要混用。

2.1 刻录启动盘：光盘与优盘的关键差异

标题里写的是“光盘救援”，实际工作中优盘更常用，但两者操作逻辑一样：

• 光盘方案：用brasero、k3b或Windows下的UltraISO把ISO刻录成光盘，需要光驱，对于没有光驱的迷你主机就没办法了。
• 优盘方案：下载好ISO后，用rufus、Ventoy或dd把镜像写入优盘。

如果你在Linux下做启动盘，最简单的是：

sudo dd if=kylin-v10.iso of=/dev/sdX bs=4M status=progress

注意of=后面是整块优盘设备名（比如/dev/sdb），不是分区/dev/sdb1，写错会把自己数据盘覆盖掉。dd写出来的优盘兼容性最好，Fedora Media Writer这类工具也行，但个别主板对某些写入方式不认。

Ventoy方式的优点是以后可以一个优盘放多个ISO，引导时手动选，并且在部分UEFI机器上对ISO的兼容性比dd更好。不过一旦用Ventoy，启动进入live桌面后，优盘自己会被识别为一般移动盘，不影响后续操作。

2.2 UEFI与Zhaoxin平台的启动顺序设置

启动盘做好后，插入目标机器，开机进BIOS设置启动顺序。这里容易踩的坑是：

• UEFI机器必须在启动优先级里找到带UEFI:前缀的优盘项，如果是Legacy:或USB-HDD方式启动，可能出现live桌面起来之后，后面找硬盘分区时看到的设备顺序和原系统不一致。
• 兆芯KX-6640MA平台需要留意CSM兼容模块是否打开。部分主板默认关闭CSM，传统引导的live盘直接不识别；而如果系统本身装在MBR磁盘上，UEFI模式下又无法正常引导，必须临时开启CSM才能进入live环境。
• 进入live环境时，如果卡在图形界面黑屏，可以尝试在启动菜单按e编辑内核参数，在quiet后面加nomodeset，跳过显卡驱动初始化。这一步能救很多不常见显卡的机器。

2.3 进入live环境后的第一件事：稳定root权限

银河麒麟V10的live桌面默认登录用户不是root，在图形界面里打开终端执行sudo -i切换为root。热搜里经常有人问“u盘启动root权限”，指的就是这一步，没拿到root权限后面所有挂载和chroot都做不了。

sudo -i

切换成功后，确认自己已经拿到root，再执行：

lsblk

把所有磁盘和分区列出来，记录下系统盘和优盘的设备名。这块信息是整个救援过程的导航图，后面全程要依赖它。

3. chroot三步走：挂载分区、绑定目录、切进受损系统

拿到root权限并看清磁盘布局后，进入核心环节：把原来装在硬盘里的银河麒麟V10系统挂载起来，然后通过chroot钻进那个受损系统内部。打个比方，chroot就是给自己套一层“空间传送”效果——看起来像在目标系统里操作，实际命令还是靠live环境的内核在跑。

3.1 识别根分区、/boot分区和EFI分区

先用lsblk -f查看带文件系统类型的完整信息：

lsblk -f

重点确认三件事：

• 根分区/：通常是ext4或xfs格式，挂载点是/。
• /boot分区：有些安装场景单独分了/boot，有些则把启动文件直接放在根分区的/boot目录下，后者在lsblk里看不到独立分区。
• EFI系统分区：UEFI模式下会有一个vfat格式的小分区，一般200MB到1GB，挂载点为/boot/efi或/efi。

判断根分区是物理分区还是LVM逻辑卷：

lvs vgs

如果lvs有输出，说明系统用了LVM。银河麒麟V10安装默认有时会用LVM，这时挂载前要先激活逻辑卷：

vgchange -ay

3.2 按固定顺序挂载，顺序错了修复必失败

挂载顺序不能乱，否则chroot进去后grub2-mkconfig要么报错，要么生成的配置路径不对。以根分区是/dev/sda3、LVM逻辑卷是/dev/vgkylin/lv_root为例：

传统BIOS模式：

mount /dev/vgkylin/lv_root /mnt mount /dev/sda1 /mnt/boot # 如果有独立boot分区

UEFI模式：

mount /dev/vgkylin/lv_root /mnt mount /dev/sda1 /mnt/boot # 如果有独立boot分区 mount /dev/sda2 /mnt/boot/efi # EFI分区固定挂到这里

挂完根分区后，绑定系统运行时目录：

mount --bind /proc /mnt/proc mount --bind /sys /mnt/sys mount --bind /dev /mnt/dev mount --bind /run /mnt/run

/run经常被漏挂，漏挂的后果是chroot里执行grub2-mkconfig时，udev设备信息不完整，生成的grub.cfg里磁盘编号乱掉。

3.3 确认挂载无误后进入chroot

执行：

chroot /mnt /bin/bash source /etc/profile export PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

进入chroot后，你的ls、df看到的都已经是原系统的视角。验证一下：

cat /etc/os-release

如果能看到银河麒麟版本信息，说明你已经在目标系统里面了，下一步就可以开始重装GRUB。

如果挂载时提示设备忙，说明live环境自动挂载了硬盘分区，先umount掉再挂。

3.4 挂载后常见报错及处理

4. 重建引导：传统BIOS和UEFI两条路线的关键命令

现在来到了可能让你原地翻车的分叉口。传统BIOS和UEFI虽然都是执行grub2-install和grub2-mkconfig，但目标设备、目标目录、还需要的额外步骤完全不同，搞混了会得到一个“命令没报错但开机还是不进系统”的尴尬结果。

4.1 传统BIOS模式：grub2-install装到主驱动器

先确认当前grub版本：

grub2-install --version

在传统BIOS模式下，把引导代码写入磁盘主引导记录区，目标设备是整块磁盘而不是分区：

grub2-install /dev/sda

我见过很多人在这里写成grub2-install /dev/sda1，这个错误很危险，它会尝试把GRUB核心镜像写到分区首部，破坏原文件系统的启动扇区。记住，传统模式下永远是整盘设备名。

安装成功后，重新生成配置文件：

grub2-mkconfig -o /boot/grub2/grub.cfg

执行后如果出现Found linux image: /boot/vmlinuz-...和Found initrd image: /boot/initramfs-...，说明配置生成正常。如果没有任何输出，多半是/boot没挂对，或者内核文件确实丢了。

4.2 UEFI模式：grubx64.efi安装与EFI启动项注册

UEFI模式下先确认几件事：

ls /sys/firmware/efi

如果目录存在，才说明当前live环境本身是UEFI启动的。如果这个目录不存在，即使你原来系统是UEFI，也建议重启把live盘改成UEFI模式再进来。

确认后执行：

grub2-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=Kylin --recheck

这条命令会把grubx64.efi写入/boot/efi/EFI/Kylin/，并尝试注册EFI启动项。接着生成配置：

grub2-mkconfig -o /boot/efi/EFI/Kylin/grub.cfg

注意，UEFI模式下默认也生成到/boot/grub2/grub.cfg，但EFI固件实际读取的是EFI分区里的那个文件，所以最好两边都生成：

grub2-mkconfig -o /boot/grub2/grub.cfg

如果你的主板固件不认自带的bootloader-id，还可以用efibootmgr手动增加一条启动项：

efibootmgr -c -d /dev/sda -p 2 -L "Kylin V10" -l '\EFI\Kylin\grubx64.efi'

其中-p 2是EFI分区序号，看你的实际布局。

4.3 传统模式/UEFI模式通用兜底：手动指定root和prefix

如果grub2-install一直失败，比如提示磁盘写入被拒或无法读取分区，可以退回GRUB手动模式。在grub rescue>或grub>提示符下，先查看分区：

ls

假设得到(hd0) (hd0,msdos1) (hd0,msdos2)，其中(hd0,msdos2)是boot分区，执行：

set root=(hd0,msdos2) set prefix=(hd0,msdos2)/grub2 insmod normal normal

这里的msdos表示MBR分区表，GPT分区表的UEFI机器会显示为gpt，这是分辨当前属于哪种分区的另一条线索。如果能正常进入菜单，说明GRUB主体没坏，只是grub.cfg丢了或路径不对。

5. 高频报错的一线排查逻辑：minimal bash、normal黑屏、cfg缺失

重建完成后，很多机器能正常进系统了，但还有一批机器会在修完之后出现一些看似相同、实则原因完全不同的报错。我把热搜里提到的几个高频问题拿出来做一次完整排查，建议你按顺序对照。

5.1 grub minimal bash like line editing is supported 的完整排查链路

这是出现频率最高的提示，字面意思是“GRUB进入最小bash，只支持行编辑”。出现这个页面的本质是：GRUB主程序能从磁盘首部加载，但找不到或无法解析/boot/grub2/grub.cfg。排查链路分三步：

第一步，在grub>里执行：

ls

先看看GRUB自己能否枚举出磁盘和分区。如果输出为空，说明磁盘驱动没加载，常见于磁盘用了较新的NVMe控制器而GRUB模块不在默认位置。

第二步，手动指定前缀后尝试进入normal：

set root=(hd0,gpt2) set prefix=(hd0,gpt2)/grub2 insmod normal normal

如果normal命令后报not found，说明/boot/grub2/i386-pc/normal.mod文件损坏或丢失。这时候不要犹豫，直接进live环境chroot重装：

grub2-install /dev/sda

如果没有报错，说明模块重新装好了。

第三步，确认grub.cfg里内核路径是否与磁盘实际一致。打开grub.cfg检查：

cat /boot/grub2/grub.cfg | grep linux

如果里面的/boot/vmlinuz-xxx对应的文件在/boot下实际不存在，说明之前内核升级时清理过旧内核，而grub.cfg没有更新。重新用grub2-mkconfig生成一次就能覆盖掉旧路径。

5.2 输入normal后不能启动：三种隐藏情况

热搜里“修复grub 输入normal后不能启动”是很折磨人的问题——normal命令输入了，菜单也出来了，但不管选哪个内核，屏幕一黑或者转回grub>。

第一种情况：normal.mod不完整，但grub.cfg里模块加载顺序依赖了这个文件。确认方法是在grub>里执行：

insmod /boot/grub2/i386-pc/normal.mod

如果这条单独加载没问题，再把grub.cfg里所有load_video、insmod相关行和实际文件比对，有缺失就重装grub。

第二种情况：内核或initrd损坏。这种通常不是grub的锅，但表现出来就是在grub菜单里选择后黑屏。用live环境chroot进去，重装内核：

dnf reinstall kernel -y

或者手动替换initramfs：

dracut -f /boot/initramfs-$(uname -r).img $(uname -r)

第三种情况：显卡驱动或内核参数异常。在grub菜单界面按e编辑启动项，把quiet改成quiet nomodeset，再按Ctrl+x启动。如果能进系统，说明问题出在显卡驱动，进系统后调整驱动即可。

5.3 grub找不到cfg / error: file '/boot/grub2/grub.cfg' not found

这个报错比minimal bash更进一步：GRUB直接根据prefix找配置文件，文件路径不存在。排查时优先怀疑的是——/boot分区是否独立？如果独立，grub.cfg应该放在/boot/grub2/grub.cfg，同时prefix应该指向(hd0,gptN)/grub2；如果/boot不独立，grub.cfg应该放在根分区的/boot/grub2/grub.cfg下，而prefix应该指向(hd0,gptN)/boot/grub2。

很多人重建时只执行了grub2-mkconfig -o /boot/grub2/grub.cfg，但忘了确认文件真的生成了。chroot里执行：

ls -l /boot/grub2/grub.cfg

文件体积应该在几十KB以上，如果只有几百字节甚至不存在，多半是grub2-mkconfig执行时没有检测到内核，回查第3步的挂载顺序。

5.4 单用户模式怎么进：忘记密码和grub修复时的另一条路

如果你暂时没有live光盘，系统本身还能进入grub菜单，可以试试单用户模式。在grub菜单界面按e，找到linux开头的那一行，在末尾加上：

single

或：

rd.break

然后按Ctrl+x启动。前者是经典的SYSV单用户模式，适合重置密码；后者会先进入dracut的break shell，适合排查initrd相关的问题。银河麒麟V10的SELinux开启状态下，单用户模式修改文件前可能需要临时设置：

setenforce 0

或者在内核参数里加enforcing=0。

5.5 关于“格式化c盘”的提醒：救援盘上最昂贵的操作

热搜词里有一个诡异的组合“grub>格式化c盘”。我不建议在任何情况下从grub或随便找的维护工具里执行格式化操作，尤其不要在看到设备名/dev/sdd之类就默认是优盘。live环境里的设备名和原系统不保证一致——拔插优盘、挂载硬盘的顺序变化，都会导致/dev/sda变成优盘、原系统盘变成/dev/sdc。

在格式化或fdisk操作前，至少用三个手段交叉确认：

1. lsblk看大小和挂载点。
2. blkid看UUID。
3. 确认优盘设备名和自己要操作的设备名，必要时拔掉优盘再插上。

5.6 grub和systemd-boot：另一条可选路径

如果你修过多次grub，每次都因为配置文件丢失而复发，可以考虑把引导管理器换成systemd-boot，尤其适合UEFI模式的机器。它把每个系统的启动项写成独立的conf文件，不容易出现grub.cfg整体损坏的问题。但换引导管理器有两个前提：一是你熟悉EFI分区结构，二是不介意放弃grub的菜单级编辑能力。

在chroot里安装：

bootctl install

然后编辑/boot/loader/loader.conf和/boot/loader/entries/kylin.conf。这个方案不适合新手，但对特定反复故障的机器，比每次都做一次grub重建省心。我自己的经验是，传统BIOS机器不要碰systemd-boot，意义不大；UEFI笔记本可以试试。

6. 恢复后的收尾工作与一劳永逸的防护习惯

系统能正常开机、能看到麒麟桌面，并不代表救援彻底结束。grub重建后还有几件不引人注意但关乎下次故障成本的事，趁现在系统还能用，一次做完。

6.1 验证恢复结果的三个动作

第一，重启两次，确认没有偶发性的引导失败。很多grub问题是有概率的，比如磁盘自检慢导致等不到设备，重启一次不够。

第二，进系统后检查grub.cfg和内核文件路径：

grub2-mkconfig -o /boot/grub2/grub.cfg

如果之前内核更新过，这步会把最新内核加入菜单。

第三，检查EFI启动项顺序：

efibootmgr

确保Kylin的启动项排在第一位，如果Windows或其他系统的入口排在前面，可以用efibootmgr -o调整。

6.2 写一个可复用的修复脚本

我建议把救命的步骤固化成一个脚本，放到优盘里，下次遇到同样故障，不用现场回忆命令顺序。脚本核心逻辑不复杂，大概是这样：

#!/bin/bash # 救援脚本：请先在live环境中以root执行 set -e DISK="/dev/sda" # 按实际修改 BOOT_PART="/dev/sda1" # /boot分区，无独立boot则留空 EFI_PART="/dev/sda2" # UEFI EFI分区，传统BIOS则留空 mount /dev/vgkylin/lv_root /mnt || mount $ROOT_PART /mnt [ -n "$BOOT_PART" ] && mount $BOOT_PART /mnt/boot [ -n "$EFI_PART" ] && mount $EFI_PART /mnt/boot/efi mount --bind /proc /mnt/proc mount --bind /sys /mnt/sys mount --bind /dev /mnt/dev mount --bind /run /mnt/run chroot /mnt /bin/bash -c " grub2-install $DISK grub2-mkconfig -o /boot/grub2/grub.cfg "

超时的朋友可以直接把这段存成rescue-kylin.sh，用启动盘进live环境后执行。这个脚本算不上优雅，但绝对实用。

6.3 给grub上双保险：备用ESP里的备用入口

UEFI模式下，可以在另一个优盘或第二块硬盘上装一个独立的GRUB入口，作为系统的“v2引导”。做法是把这个备用盘挂到live环境，然后：

grub2-install --target=x86_64-efi --efi-directory=/mnt/usbesp --bootloader-id=Rescue

这样即使主硬盘的EFI分区彻底损坏，BIOS里还能选到备用优盘或备用盘启动，再顺手把主盘的grub修回来。

传统BIOS机器没这个便利，但可以准备一个带GRUB的维护优盘，开机从优盘启动后，用configfile (hd0,gpt2)/boot/grub2/grub.cfg这种命令直接引导原系统，也是一种可靠的兜底方案。

6.4 我在多次grub崩溃救援中的三个体会

第一，grub修复命令本身不难，难的是准确判断故障在哪一层。拿到机器先别急着敲grub2-install，把lsblk、blkid、固件模式这三条信息摆在桌面上，成功率直接提升一半。

第二，银河麒麟V10的内核升级机制和CentOS类似，升级后不自动重建grub菜单。如果你习惯“装完更新直接重启”，建议把这个习惯改掉：更新完内核，先跑一遍grub2-mkconfig再重启，能避开大量引导类故障。

第三，修复grub时一定要有耐心做“两眼验证”——mount之后看一眼ls /mnt/etc，生成配置之后看一眼文件大小，重启之前再看一眼固件启动项，每个动作都确认一步再走下一步。grub救援最怕的不是命令复杂，而是前面某一步挂错了分区，后面所有操作都建立在错误基础上。

这些步骤走完，银河麒麟V10的grub问题基本都能解决。退一步说，即使哪次修复失败需要重装，按第3章、第4章的思路先备份好根分区里的数据再动手，损失也能降到最低。平时有空的话，建议在虚拟机里把“光盘救援+chroot+grub重建”完整演练一遍，真到了现场，你会感谢之前那个提前踩坑的自己。