前阵子帮一家客户处理了一台银河麒麟V10 SP3服务器，情况很典型：上一任管理员给GRUB启动菜单加了密码，又把系统root密码改了，然后人直接失联。设备摆在机房里，业务验收在即，开机到GRUB菜单这一步就卡死，按e要密码，按c也要密码，现场同事对着屏幕干瞪眼，最后只能把问题抛给我远程加现场配合处理。
这种“双密码遗忘”故障，在麒麟系统运维里其实并不冷门。GRUB密码和系统密码是两层独立的认证，任何一个忘了都进不了系统，两个一起忘就是完全锁死。这篇指南就围绕V10 SP3的实测救援展开，会一步步讲清楚如何借助安装镜像进入救援模式、通过chroot清理GRUB密码配置、重置root密码，也会覆盖GRUB命令行手动引导、grub minimal bash故障修复、磁盘加密等特殊场景的处理办法。不管你是刚接手二手服务器，还是自己手抖把密码弄丢了，只要设备在物理上可触碰，照着做大概率能救回来。整套操作仅适用于自有设备或已获授权的运维场景。
1. 双密码遗忘，先把救援思路理清楚
1.1 双密码到底锁在哪个环节
先明确一个概念：银河麒麟V10 SP3的双密码，和Windows那种“双账户”不是一回事。它指的是GRUB引导器的超级用户密码，加上系统的root或普通用户登录密码，两层独立认证叠在一起。
GRUB密码是写死在启动器配置里的。常见的设置方式是管理员在/etc/grub.d/00_header里追加set superusers和password_pbkdf2配置，然后用update-grub把脚本合并生成/boot/grub/grub.cfg。一旦设置生效，在GRUB菜单里按e要密码、按c进命令行也要密码，相当于把系统引导入口焊死。很多人不理解为什么GRUB也要锁密码，其实它的意义在于防止有人通过修改内核启动参数绕过系统登录认证——这是Linux救援逻辑里最经典的一条后门路径。
系统登录密码是用户认证层的东西，由PAM和/etc/shadow管理。理论上GRUB没锁的情况下，只要能在菜单里编辑内核参数，就能想办法绕过认证进入系统。但GRUB密码一锁，这条后门也被堵上，这就是双密码同时遗忘时，一定要从引导器层开始解的根本原因。
我从实战角度把救援逻辑总结成一句话：GRUB密码本质上只是配置文件里的字段，我们要做的不是“破解”它，而是绕开它，进入一个能写文件系统的环境，把这个字段删掉或替换。理解了这点，后面所有操作都不会乱。
1.2 三种现场情况对应三条救援路线
实际操作之前，先按你手头的现场条件对号入座。不同情况的操作路径差很多，选错了会白白浪费时间：
| 现场情况 | 推荐做法 | 需要的前提 |
|---|---|---|
| GRUB密码、系统密码都忘了 | 用系统ISO进救援模式，chroot后清理GRUB密码并重置root密码 | 有同大版本的系统镜像、能插U盘或光驱 |
| GRUB没锁，root密码忘了 | 在GRUB菜单按e，修改内核参数进入bash重置密码 | 有物理控制台或IPMI远程控制台 |
| GRUB配置损坏，出现minimal bash提示 | 在GRUB命令行手动指定分区、内核和initrd引导 | 记得系统盘分区结构、内核版本号 |
拿到故障机先别急着做启动盘。按电源开机，看它在哪一步停下来。如果卡在GRUB菜单要求输用户名密码，基本判断是GRUB配置还在，只是被密码锁住，走ISO救援最稳。如果开机直接黑屏、光标闪烁，或者跳出grub minimal bash like line editing is supported这种提示，那是引导配置本身出问题了，处理思路要换成手动引导。先把现场情况摸清楚，能省掉至少两小时的盲目尝试，也避免反复重启对磁盘文件系统造成二次损伤。
2. 救急启动盘这样准备，救援才不卡壳
2.1 为什么用Ventoy而不是直接写盘
救援的第一步是做一个能启动的介质。很多人习惯用dd把ISO二进制写入U盘，或者用各种刻录工具直接烧录，这两个办法在麒麟系统救援场景下都不够灵活。
我实测下来最推荐Ventoy。它的原理是把U盘做成一个引导管理器，你只需要把ISO文件拷贝到U盘根目录，开机选择对应ISO就能启动。好处有三个：第一，U盘可以同时放多个版本的ISO，比如V10 SP3桌面版和服务器版各放一个，现场缺什么都能应对；第二，U盘剩余空间还能正常存文件，不用专门准备一个“纯启动盘”；第三，Ventoy对麒麟这类Debian系镜像的兼容性已经比较成熟，不用反复试验写盘方式。
如果你手头实在没有第二个可用U盘，又赶时间，也可以用装系统时留下的安装光盘，或者用iLO、iDRAC这类带外管理工具的虚拟光驱挂载ISO，道理一样。重点是确保介质能引导，版本最好和故障机同属V10系列。跨大版本进入救援模式不是不行，但后面chroot时可能遇到库里依赖差异，没必要给自己加难度。
2.2 UEFI和Legacy启动模式别搞混
启动盘做好之后，在BIOS/UEFI设置里把启动顺序调整成U盘优先。这里有个特别容易踩的坑：UEFI和Legacy两种固件引导模式。
麒麟V10 SP3服务器版默认多是UEFI引导，老设备才是传统BIOS。从U盘启动时，如果固件菜单里出现同一U盘的多个启动项，一个带UEFI前缀，一个不带，一定要选和原系统安装方式一致的那个。选择错误最典型的影响是：救援模式能进、系统盘能挂载、命令全部正常，但最后重新安装GRUB时会因为固件接口不匹配而写错位置，甚至直接导致启动条目丢失，救援变二次事故。
快速判断原系统引导模式的土办法：进救援模式挂载系统后，看/boot/efi目录是否存在。如果存在且里面有grub或EFI/kylin之类的文件，说明是UEFI；没有的话基本是传统BIOS。后面执行grub-install时，UEFI平台要加--target=x86_64-efi，传统BIOS不加。这一条记不住的话，很容易在最后关头功亏一篑。
3. 全程实测：ISO救援模式重置GRUB密码与root密码
3.1 进救援模式，把原系统盘挂载起来
这是整个救援过程的核心动作，我把执行过程一步步拆开讲。用Ventoy启动盘选择麒麟V10 SP3 ISO后，会看到安装器菜单。菜单里一般有安装项，也可能有“系统修复助手”或类似修复救援入口。优先选修复类入口；如果ISO没有单独提供修复模式，就选试用或Live桌面环境，在终端里操作，效果一样。
进到救援环境后，第一步是识别硬盘和设备节点。执行lsblk和fdisk -l，先把所有磁盘和分区结构看清楚。常见布局有两种：一种是/boot和根分区在同一块盘上，只是普通分区；另一种是服务器版常用的LVM布局，/boot单独分出来，根分区是逻辑卷。
普通分区布局的执行参考（以根分区为nvme0n1p2为例）：
mkdir -p /mnt/sys mount /dev/nvme0n1p2 /mnt/sys mount /dev/nvme0n1p1 /mnt/sys/boot # 有独立boot分区才需要 mount --bind /dev /mnt/sys/dev mount --bind /proc /mnt/sys/proc mount --bind /sys /mnt/sys/sys mount --bind /run /mnt/sys/run chroot /mnt/sys /bin/bashLVM布局则要先激活卷组再挂载：
vgscan vgchange -ay ls /dev/mapper/ mkdir -p /mnt/sys mount /dev/mapper/kylin-root /mnt/sys # 实际卷名以vgdisplay输出为准 mount /dev/nvme0n1p1 /mnt/sys/boot # 后续bind和chroot命令同上这里有个很容易被忽略的细节：挂载根分区之后，/dev、/proc、/sys这些目录必须全部就位，chroot进去才能正常执行命令。尤其是/proc和/sys，不bind的话，update-grub或grub-mkconfig很可能报奇怪错误，你会误以为是配置文件坏了，其实只是虚拟文件系统没挂全。
3.2 用chroot清理GRUB密码配置
chroot成功进入原系统后，先确认GRUB密码写在哪里。不同管理员习惯不同，有人写到/etc/grub.d/00_header，有人单独建了/etc/grub.d/01_users，还有人直接修改/boot/grub/grub.cfg。所以在chroot环境里先做一次全目录搜索：
grep -rn "password_pbkdf2\|superusers" /etc/grub.d/ grep -n "set superusers\|password_pbkdf2" /boot/grub/grub.cfg定位到位置后，先把文件备份，再删除或注释密码配置。以修改/etc/grub.d/00_header为例：
cp /etc/grub.d/00_header /etc/grub.d/00_header.bak sed -i '/password_pbkdf2/d;/superusers/d' /etc/grub.d/00_header update-grubupdate-grub的执行逻辑是把/etc/grub.d/下的脚本合并生成新的/boot/grub/grub.cfg。因为密码字段已在源头清理，新生成的配置文件自然没有密码。这是最稳妥的，比你直接手改grub.cfg干净，也经得起系统更新时重新生成配置的考验。
如果不想彻底删除GRUB密码，只想换成自己知道的新密码，可以用grub-mkpasswd-pbkdf2生成新的密文，把00_header里的password_pbkdf2字段替换后再update-grub。这种方式适合有安全基线、要求GRUB必须开启密码的企业环境，密码被人为清掉反而违反合规要求。
3.3 顺手完成root密码与普通用户密码重置
GRUB密码清理完之后，在同一个chroot环境里接着做系统密码重置，两步不用分开跑：
passwd root passwd kylin # 换成实际需要重置的用户名执行过程中会要求输入两次新密码。这里提醒一下：新密码尽量不要和旧密码太相似，也别用公司名加年份这类容易猜的组合。麒麟系统对密码复杂度校验普遍比较严格，设置太简单会被PAM策略直接拒绝。
如果不知道系统里有哪些普通用户，可以看/etc/passwd里uid在1000以上的条目，或者直接翻/home目录确认：
getent passwd | awk -F: '$3 >= 1000 {print $1}'重置完成后，退出chroot、卸载所有挂载点，然后正常重启：
exit umount -R /mnt/sys reboot到这一步，GRUB菜单密码和系统密码都已经恢复正常。重启后进GRUB不需要密码，系统用新密码也能登录。整体看下来，救援过程核心依赖的就三件事：能进救援环境、能挂载文件系统、会操作chroot。这也是Linux系统管理员早晚要熟练掌握的基本功。
4. 不依赖镜像的备选方案：GRUB命令行硬核引导
4.1 菜单能进但root密码忘了：改内核参数偷渡
如果没有安装镜像，但GRUB菜单没有被密码锁住，还有一条更快的路。开机到GRUB菜单后，选中要进入的内核条目，按e进入编辑界面。菜单文本里找到以linux开头的那一行，行尾追加一个内核参数init=/bin/bash，然后按Ctrl+X或F10引导。
引导完成后会直接进入bash shell，但这时根文件系统多半还是只读状态，先重新挂载成读写，再执行passwd重置：
mount -o rw,remount / passwd root exec /sbin/init使用这条路线有两点要注意。第一，只对没有开启完整磁盘加密的系统有效，如果根分区是LUKS加密的，启动过程中不输入密码无法解锁，改内核参数也没用。第二，部分安全策略较严的版本会对启动参数做检查，init=/bin/bash可能被安全模块拦下，这种情况不要硬用，老老实实回第3节的ISO救援路线。
顺便说一句，很多人问能不能用single参数代替init=/bin/bash。麒麟系统上single进入的确实是单用户模式，同样能重置密码，但有些版本在单用户模式下会要求先输入root密码才给shell，等于白搭。init=/bin/bash直接跳到bash会话，实际用下来更省事。
4.2 遇到minimal bash：手动指定内核启动
如果开机后看到grub minimal bash like line editing is supported这种黑底白字提示，说明GRUB能找到自身代码，但找不到grub.cfg配置文件，掉进了一个功能受限的最小shell。这种情况不能等它自己恢复，得手动引导系统进到运行环境，再从系统内部修复配置。
手动引导的思路是：告诉GRUB根分区在哪、内核文件在哪、initrd文件在哪，然后boot。用Tab键做补全，能帮你快速定位可用分区和文件：
grub> ls (hd0) (hd0,gpt1) (hd0,gpt2) grub> set root=(hd0,gpt2) grub> linux /boot/vmlinuz-4.19.90-89.11.v2101.ky10.x86_64 root=/dev/mapper/kylin-root ro grub> initrd /boot/initrd.img-4.19.90-89.11.v2101.ky10.x86_64 grub> boot内核版本号要根据机子上实际安装的来填，不用照抄。如果/boot是独立分区，上面linux和initrd两行的路径要去掉/boot前缀，写成/vmlinuz-...和/initrd.img-...。进系统之后，重新生成GRUB配置并安装引导器，恢复后续启动能力：
update-grub grub-install /dev/sda如果需要把引导器安装到主驱动器，安装时注意设备名要写整块磁盘（比如/dev/sda），不是分区（/dev/sda1）。麒麟安装器检测到引导缺失时通常也会提示“将grub启动引导器安装至您的主驱动器”，顺着引导执行一次就好。这类损坏多半是升级中断、意外断电或磁盘调整导致，处理完这步就能恢复正常冷启。
5. 实测中踩过的坑，整理成速查表给你
5.1 grub minimal bash故障与修复要领
minimal bash这个报错我在救援现场见过很多次，而且常常和密码问题一起出现。典型场景是：管理员用分区工具调整分区大小，或者把系统盘clone到新硬盘后UUID对不上，GRUB在启动时找不到配置文件，直接掉shell。
修复要领就四条：先ls看清分区存在与否，摸清哪个分区是/boot；再用set root把根分区指对；然后按第4.2节手动boot进系统；最后一定记得update-grub并检查grub.cfg里的UUID。检查命令：
cat /boot/grub/grub.cfg | grep "search\|uuid" | head -20 lsblk -f对比blkid输出和grub.cfg里的UUID，不一致就重新生成配置或重装引导。很多人在手动引导进去后忘了重建配置，结果下次开机又掉回minimal bash，白忙一场。如果你用的是克隆盘或迁移过的系统，这一步尤其不能省。
5.2 磁盘加密和安全模块拦路怎么办
如果装系统时勾了磁盘加密，救援难度会上升一个档次。LUKS加密状态下，用ISO救援模式挂载根分区时，系统会提示输入加密口令。这一步绕不过去，不存在“忘记口令还能解开LUKS”的通用办法。所以操作前务必确认：要么记得加密口令，要么系统没开加密。遇到加密口令也忘了的，现实中基本只能走数据恢复或重建系统，别指望任何救援命令能帮你绕过。
另一个拦路的是安全增强模块。麒麟V10 SP3部分版本会启用内核安全模块，对启动参数和系统配置有较严格的完整性约束。实测中init=/bin/bash方式在某些内核参数策略下会被拒绝，表现就是看起来引导成功，却卡在空壳shell或者直接重启。我的经验是：遇到安全策略拒绝，不要反复换参数硬试，直接转ISO救援模式加chroot方案。后者面对安全模块时要可靠得多，因为是以挂载编辑原系统文件的方式操作，不涉及启动参数层面的绕过。
5.3 重置后黑屏、引导丢失的善后处理
密码重置成功并不代表万事大吉，重启阶段还可能遇到两种情况，我在不同机器上都踩过。
第一是系统启动到一半黑屏或卡在桌面加载之前。这多半不是救援操作的问题，而是显示驱动或图形服务状态异常。处理方式是进GRUB菜单按e，在linux那行末尾追加nomodeset参数，先绕过显卡驱动强制加载的问题，进系统后更新驱动或调整显卡配置。
第二是重启后提示找不到操作系统或引导器损坏。这通常发生在对UEFI设备执行了错误平台参数的grub-install之后。解决思路是重新进救援环境，挂载系统盘，确认/boot/efi和/run这些目录都挂载到位，再执行一次正确平台参数的安装。UEFI机器大致如下：
mount /dev/nvme0n1p1 /mnt/sys/boot/efi mount --bind /dev /mnt/sys/dev mount --bind /proc /mnt/sys/proc mount --bind /sys /mnt/sys/sys chroot /mnt/sys /bin/bash grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=kylin update-grubSecure Boot相关提示也常在这环节冒出来。固件开了Secure Boot的话，引导器要经过签名校验，麒麟官方驱动器和模块一般没问题，但手动重建引导器时有可能因为ESP分区没挂载到位而报错。把/boot/efi这类ESP分区挂对，是排查这类报错的第一动作。
6. 救援成功后的防锁死策略
6.1 密码分层保管，别把鸡蛋放一个篮子
救援完成之后，很多人过两天又开始裸奔，等下次密码丢了再来一轮。与其反复折腾，不如趁这次把密码管理机制建立起来。
GRUB密码和系统密码属于不同安全层级，不要存在同一张便签、同一个记事本里。企业内部建议放到两个独立保管人手里：一个管BIOS/GRUB这层物理引导口令，一个管系统账户口令。这样既避免单人全知全能，也防止权限交接时一次性把所有秘密带走。对于个人管理的小规模机器，至少也要把密码写进正规密码管理工具并开启双因子验证，而不是记在手机备忘录里。
如果负责设备较多，建议给每台机器做一张信息卡，记录主机名、IP、磁盘分区布局、LVM卷组名、是否启用LUKS、GRUB是否加锁等。密码本身不在这张卡上，但它能让你在下一次救援时省掉大量摸索时间——比如直接知道卷组叫什么、boot分区在哪，不用临时翻fdisk输出。
6.2 预留一个不用密码也能走通的恢复通道
最后分享一个自己坚持的做法：每台重要服务器，都会额外准备一个不被GRUB密码和系统密码双重锁死的恢复通道。
最简单的形式，是一个标好版本号、固定存放的Ventoy启动U盘，里面放好对应系统的麒麟ISO，外加一张纸质的引导备注，写上分区结构和LVM卷组名。别小看这个动作，成本几乎为零，但在双密码遗忘、grub配置损坏这类绝境里，往往是唯一能把你从机柜前捞回来的东西。虚拟化平台上的虚拟机，则给虚拟光驱挂一个常用救援ISO，并确认带外管理控制台能访问；物理机把IPMI、iLO的账号密码单独归档。
我在实际救援过程中最深的体会是：双密码问题的难度往往不在技术上，而在对设备细节的熟悉程度上。每次帮人救完，我都会建议他们把分区结构、引导方式、密码分层这三样东西固定记录。准备工作做得越细，现场需要试错的次数就越少。下次再遇到锁机，直接照本指南走一遍，基本半小时内能重获控制权。
