0x01 问题描述

需要在物理机上做实验，环境有冲突。故考虑在硬盘上安装多个系统，使用GRUB引导。然而发现，GRUB能引导硬盘上靠前的分区（/dev/sdb2），但是引导不了靠后的分区（/dev/sdb3）。宁畅服务器，BIOS为AMI 2.20.1275，阵列卡组RAID5。

1
2
3
4
5
6
7
8
9

sda     8:0    0    476G    0  disk
├─sda1  8:1    0    475G    0  part
├─sda2  8:2    0    1K      0  part
└─sda5  8:5    0    975M    0  part
sdb     8:16   0    11.4T   0  disk
├─sdb1  8:17   0    4G      0  part  /boot/efi
├─sdb2  8:18   0    1T      0  part  /
├─sdb3  8:19   0    1T      0  part
└─sdb4  8:20   0    1T      0  part  

在配置GRUB一阶段引导到/dev/sdb3之后，启动时会回退到grub shell中。在其中使用ls检查分区，观察到/dev/sdb3和/dev/sdb4都无法访问：No known filesystem detected。

如果尝试在GRUB二阶段引导到/dev/sdb3，仍然会报unknown filesystem错误。

0x02 问题排查

首先进行一番搜索，发现大伙遇到过类似的问题：制作 Linux 模版时出现 grub error: unknown filesystem 的解决办法。该文章得出的结论是GRUB旧版本不兼容metadata_csum_seed特性。

然而我安装的所有系统都是Ubuntu，版本分别是22.04和20.04，Ubuntu在最新版本上用的也是GRUB 2.06。故在其安装程序格式化分区的时候不应该带有该特性。进行检查，确定这一点：

注意到其中的metadata_csum是早已支持的特性，一直有兼容。故排除该标记导致的问题。

随后再搜索一番，发现Legacy BIOS访问硬盘会有限制，例如legacy limit . Ventoy指出，在某些主板的BIOS中，Legacy模式下访问硬盘会有137G的限制。该限制源自于24-bit LBA的寻址方式。但是问题在于，我的引导方式是UEFI，并非Legacy BIOS。

此时忽然想起，机器上原有安装的系统是BIOS PC引导的。难道错误设置成了链式引导？遂检查设置，排除之。再想想，服务器同时支持两种引导方式，应该是启用了CSM兼容模式。是不是在UEFI+CSM下，硬件仍然会采用24-bit LBA寻址方式？最后测试果真如此。

0x03 解决方案

关闭CSM兼容模式，即可解决UEFI引导下无法读取137GB以后的分区的问题。

根据消融实验，只要使能CSM兼容模式就有这个问题，无论它提供的子选项设置。