• 文件系统没坏的话可以尝试在grub shell设置 root 和prefix 进系统修复

转载：作者 [Jerry_Jin]

怎样修复grub开机引导(grub rescue)

很多时候，特别是在linux调整分区后，开机重启时会出现

    error : unknow filesystem

    grub rescue>

    的字样，系统就是进不去。这表示你的grub2的配置文件坏了……

    由于分区调整或分区UUID改变造成grub2不能正常启动，从而进入修复模式了（grub rescue)，也称救援模式。

  

    在救援模式下只有很少的命令可以用：set  ,  ls , insmod , root , prefix



    (1)set  查看环境变量，这里可以查看启动路径和分区。

    (2)ls   查看设备

    (3)insmod  加载模块

    (4)root  指定用于启动系统的分区,在救援模式下设置grub启动分区

    (5)prefix 设定grub启动路径

具体修复步骤如下：

   1、查看分区：grub rescue> ls   回车

        会出现如下字样：

        (hd0) (hd0,msdos9) (hd0,msdos8) (hd0,msdos7) (hd0,msdos6) (hd0,msdos5) (hd0,msdos2) (hd0,msdos1)

   注：上面是我的分区设备，每个人可能不一样，但原理都是一样的。

   

   2、寻找deepin所在分区：

       （就是寻找你的Linux系统是装在以上哪个分区里）

         grub rescue> ls (hd0,msdos1)/

        若出现unknown filesystem字样，则尝试下一个

        ……

        若出现的是你的deepin主文件夹下的文件夹和文件的名字，那就是的要找的分区了。



    3、修改启动分区：

         （假如你找到的启动分区是hd0,msdos8）

     grub rescue>root=(hd0,msdos8)
     grub rescue>prefix=/boot/grub                         //grub路径设置
     grub rescue>set root=(hd0,msdos8)
     grub rescue>set prefix=(hd0,msdos8)/boot/grub
     grub rescue>insmod normal                            //启动normal启动

     grub rescue>normal

    之后你就会看到熟悉的启动菜单栏了

4、进入命令行启动deepin

     进入系统启动选项界面后还是进不去，

   因为你还没有真正的修改grub,这个要到deepin里修改

进入系统启动项界面后，按C进入命令行模式

    grub >set root=hd0,msdos8

    grub >set prefix=(hd0,msdos8)/boot/grub

    grub >linux /vmlinuz-xxx-xxx root=/dev/sda8 //里边的xxxx可以按Tab键，如果有acpi问题,在最后加一句acpi=off
    grub >initrd /initrd.img-xxx-xxx
    grub >boot

   这样就可以进入了



   5、进入deepin修复grub

在终端里运行 ：

sudo update-grub 
sudo grub-install /dev/sda


   6、重启，搞定！！

set root=(hd0,gpt6) 试过， set root='hd0,gpt6', set root='hd0,6' 都尝试过

复制/boot/efi/EFI/deepin/grub.cfg中采用search.fs_uuid myuuid root 也尝试过

因为ls -l 显示(hd0,gpt6)是no known filesystem detected. 所以，正常时此行会有uuid，现在没有了。

以上不管哪种方法，set root前后都无法ls (hd0,gpt6)/查看目录下内容。

所以我接下来即使手工执行linux /boot/vmlinuz... 也是报文件或目录不存在的错误。

哪个分区是根分区，哪个是efi分区，这个是清楚，不需要按文章再去尝试。关键是当前的grub shell突然不识别这个ext4分区了

至少简单的设置这两个变量再normal的方法是无效的

search.fs_uuid 找的就是分区的文件系统id，一旦文件系统不识别，这个当然找不到。所以通过这个来设置root失败属于正常现象。

因为根分区文件系统不识别，所以所有对(hd0,gpt6)/下面的文件访问都失败，也属于正常现象。

所以从逻辑上可以反推，只要能让grub识别(hd0,gpt6)这个分区是ext4文件系统，应该一切问题就解决了。

现在的矛盾是archlinux的live盘是能识别这个分区为ext4的，只有现在这个grub 不识别。

当前grub版本是2.04.3-17

通过testdisk和diskgenius都说明gpt6分区是正常的

会不会是双系统的问题，Windows11的升级造成的？

发现bios中多了一个linpus lite的启动项，不记得以前有次启动项。

所以删除此启动项后，系统回复正常。

删除步骤：

1. 使用archlinux镜像通过usb启动
2. 挂载根分区和efi分区
3. 将efi分区下的Boot目录删除或移动备份到根分区
4. reboot
5. 成功重启进入deepin

思考：

或许是deepin某次升级中，造成了efi分区新增了Boot启动项导致。
具体原因不明，期望deepin官方给个回答。