linux调整分区后，开机重启时会出现
error : unknow filesystem
grub rescue>
我是windows11 + archlinux双系统使用。这段时间用下来，感觉使用linux更多一些。就想把windows的分区中扣出一点的空间给linux使用。把windows的D盘调整了大小，并增加了一个分区。
因为我的linux分区是在硬盘的最后一个分区，前面增加了一个分区就导致分区索引变了。然后就无法启动了。
原本D盘是200GB，现在D盘由一个单独的分区，拆分成两个100G的分区了，图中空闲的100GB就是多出来的分区了。
原因分析
我的电脑情况来看。
按linux的计算方式，因本最后一个分区叫(hd0,gpt6)因为中间多出了一个分区。现在就成了(hd0,gpt7)导致原来的grub配置文件中描述的分区已经无法正常找到了。
解决办法
进入系统
GRUB启动不了，会自动进入救援模式。我在救援模式输入了以下指令后，成功解决了引导问题。
Welcome to GRUB!
error:unknown filesystem.
Entering rescue mode...
#查所有磁盘列表
grub rescue> ls
(hd0) (hd0,gpt7) (hd0,gpt6) (hd0,gpt4) (hd0,gpt3) (hd0,gpt2) (hd0,gpt1)
#查环境变量
grub rescue> set
cmdpath=(hd0,gpt1)/EFI/GRUB
#问题就出现在此外了，原(hd0,gpt6)实际上已经变成了(hd0,gpt7)
prefix=(hd0,gpt6)/boot/grub
root=hd0,gpt6
#查看磁盘下的文件，确定是否是我们想要切换的磁盘
grub rescue> ls (hd0,gpt7)/
./ ../ lost+found/ var/ dev/ run/ etc/ tmp/ sys/
#此处略一些目录
#（关键）设置环境变量,把错误的环境变量修改成正确的
grub rescue> set root=(hd0,gpt7)
grub rescue> set prefix=(hd0,gpt7)/boot/grub
grub rescue> insmod normal
#进入熟悉的启动菜单栏
grub rescue> normal
#然后我选择archlinux的启动菜单就可以正常的进入操作系统了。
命令说明：
set查看环境变量，这⾥可以查看启动路径和分区。ls查看设备insmod加载模块
环境变量：
root指定⽤于启动系统的分区,在救援模式下设置grub启动分区prefix设定grub启动路径
彻底修复
既然已经成功进入系统了，使用root权限执行：
mkdir /boot/EFI
mount /dev/nvme0n1p1 /boot/EFI
grub-install --target=x86_64-efi --efi-directory=/boot/EFI --bootloader-id=GRUB
grub-mkconfig -o /boot/grub/grub.cfg
自动配置一下grub，我的执行结果如下：
root@vivobook: /boot # grub-mkconfig -o /boot/grub/grub.cfg
正在生成 grub 配置文件 ...
找到 Linux 镜像：/boot/vmlinuz-linux
找到 initrd 镜像：/boot/intel-ucode.img /boot/initramfs-linux.img
Found fallback initrd image(s) in /boot: intel-ucode.img initramfs-linux-fallback.img
警告： os-prober will be executed to detect other bootable partitions.
Its output will be used to detect bootable binaries on them and create new boot entries.
找到 Windows Boot Manager 位于 /dev/nvme0n1p1@/efi/Microsoft/Boot/bootmgfw.efi
Adding boot menu entry for UEFI Firmware Settings ...
完成
至此引导的启动问题就彻底修复啦。会者不难，难者不会啊！！！
探索过程
以下是探索过程记录，仅供参考。没有多少实际作用。
探索过程1
我在网上找到了一个跟我情况非常接近的解决办法。我感觉大概率可以解决。
https://wenku.baidu.com/view/3b9adf8cd2f34693daef5ef7ba0d4a7302766ccb.html
为什么我不用这个办法呢？原因很简单，我用不了。因为我的笔记本电脑在archlinux的 grub界面，无法使用我的笔记本自带的键盘。
理论上外接usb键盘肯定可以，但是我手头又没有usb键盘。仅有一个蓝牙键盘。
探索过程2
引导进archlinux的安装光盘，重新修复一下grub引导。
可以参考：
《2021年vmware安装archlinux》
https://blog.csdn.net/lxyoucan/article/details/115226297
这个算是大招了，专制各种不服。又是因为我的键盘问题，我无法在命令行连接我的蓝牙键盘。
导致我目前什么也做不了。这个方法就暂时放弃了。
探索过程3
前面两个解决办法都是相对容易的，可惜因为我的电脑键盘的问题，导致我无法操作。现在仅剩一个办法了。
我可以进入manjaro 的live环境，这个是图像化界面的，我只要动动鼠标就能连接上我的蓝牙键盘。
实现方法见：
《没有U盘纯硬盘安装linux之manjaro》
https://blog.csdn.net/lxyoucan/article/details/124541834
当然进ubuntu的预安装环境也是可以的，见：
《没有U盘纯硬盘安装linux之Ubuntu22.04》
https://blog.csdn.net/lxyoucan/article/details/124506518
现在我有操作空间了。那就开始搞起吧。
思路很简单：
直接修改grub.cfg配置文件，并把之前的UUID修改成现在正确的UUID即可。
Linux磁盘分区UUID的获取方法
方法一：
ls -l /dev/disk/by-uuid/
执行结果如下：
[manjaro manjaro]# ls -l /dev/disk/by-uuid/
总用量 0
lrwxrwxrwx 1 root root 15 5月 25 17:14 163AAA0B3AA9E7C7 -> ../../nvme0n1p3
lrwxrwxrwx 1 root root 11 5月 25 17:15 2022-04-16-05-50-10-00 -> ../../loop0
lrwxrwxrwx 1 root root 15 5月 25 17:14 6291afc7-7bc2-4426-a78d-c1ea948e84f0 -> ../../nvme0n1p7
lrwxrwxrwx 1 root root 15 5月 25 17:14 947D-3FF9 -> ../../nvme0n1p1
lrwxrwxrwx 1 root root 15 5月 25 17:14 E788236116CB079F -> ../../nvme0n1p4
lrwxrwxrwx 1 root root 15 5月 25 17:14 E9E8-76FA -> ../../nvme0n1p6
通过blkid命令
#查设备名称
fdisk -l
比如查到是：/dev/nvme0n1p7
blkid /dev/nvme0n1p7
执行结果如下：
[manjaro manjaro]# blkid /dev/nvme0n1p7
/dev/nvme0n1p7: UUID="6291afc7-7bc2-4426-a78d-c1ea948e84f0" BLOCK_SIZE="4096" TYPE="ext4" PARTLABEL="root" PARTUUID="10d257ce-975d-b64a-8df3-daea47f7bc1d"
后来我发现其实在PE中常用的分区软件DiskGenius也可以轻松的查到。
UUID:6291afc7-7bc2-4426-a78d-c1ea948e84f0
最终还是失败了，我发现原来这个UUID原本 就没有变化。
参考
https://wenku.baidu.com/view/3b9adf8cd2f34693daef5ef7ba0d4a7302766ccb.html