记Win10系统更新后导致Linux(KaliLinux,Manjaro)开机无法引导启动的修复方法

悲剧的序幕（起因）

本人的电脑系统安装环境很复杂，使用的是Refind引导多系统，包含有Windows(Win7&Win10)和Linux（Kali Linux和Manjaro系统），昨天Win10系统提示需要重启并安装更新，于是手贱点了Win10系统的重启并安装更新，结果安装更新，更新了一个小时左右，安装完更新后就悲剧了，Kali Linux和Manjaro系统全部都无法引导，无法进入系统了(ノへ￣、)o(╥﹏╥)o

解决方法 使用set命令查看当前grub引导设置 例如会显示：

grub rescue> set
cmdpath=(hd1,gpt2)/EFI/Manjaro/
prefix=(hd1,gpt5)/boot/grub
root=(hd1,gpt5)

上述结果表明当前引导指向第二块硬盘（hd1）的gpt5分区。

使用ls命令查看当前所有磁盘分区情况

grub rescue> ls
(hd0) (hd1) (hd1,gpt7)  (hd1,gpt6) (hd1,gpt5) (hd1,gpt4) (hd1,gpt3) (hd1,gpt2) (hd1,gpt1)

使用ls(hd1,gpt数字)/ 尝试出能够返回安装了manjaro系统或者kali linux系统根目录的分区，当不是Linux分区时会显示如下结果

grub rescue> ls (hd1,gpt4)
(hd1,gpt4): Filesystem is unknown.
grub rescue> ls (hd1,gpt3)
(hd1,gpt3): Filesystem is unknown.

例如当尝试（hd1,gpt7）时返回了manjaro分区,正确的返回结果如下:

grub rescue> ls (hd1,gpt7)/
./ ../ lost+found/ bin/ boot/ dev/ etc/ ...

设置正确的gpt分区的引导目录和Linux根目录，例如gpt7分区是正确的

set profix=(hd1,gpt7)/boot/grub 
set root=(hd1,gpt7)

再用set命令查看是否已设定好

grub rescue> set
cmdpath=(hd1,gpt2)/EFI/Manjaro/
prefix=(hd1,gpt7)/boot/grub
root=(hd1,gpt7)

接下来载入normal模块，并使用normal模块启动系统

grub rescue> insmod normal
grub rescue> normal

回车后就能正常进入系统了,到这里还没结束 进入系统后，打开终端，重新安装grub，并更新引导 首先使用fdisk -l 或者 df 指令查看系统引导所在的挂载位置，比如我这里kali linux在/dev/sdb1

执行如下指令，重新安装grub引导

sudo grub-install /dev/sdb1

最后更新并生成grub引导文件

sudo update-grub

如此就大功告成了，kali linux系统就能正常引导了，manjaro是同样的操作，不过如此操作会导致一个问题，会使kali linux或者Manjaro变成第一启动项，refind引导变成第二启动项，此时只需进入Windows系统在Easy UEFI里调整启动项顺序即可，或者在BIOS里调整Refind为第一启动项。

The End,蟹蟹阅读，≧( ° ° )≦