根据几份指南(包括这微软的一个)Windows 10 只需要
- EFI 系统分区 (ESP),
- MSR 分区(显然是用于 GPT 分区)
- 系统/操作系统分区,以及
- 恢复分区。
但是,我找不到关于分区号、分区顺序以及分区之间可用空间的任何明确说明。因此,经过一些实验后,我发现了以下情况,所有这些情况都允许系统无错误地安装,但其中一些情况不允许系统启动。
以下是我将用来描述场景的分区
- “ESP” 将是一个 500 MiB 的分区,类型为
EFI System Partition
(类型代码ef00
或类型 GUIDC12A7328-F81F-11D2-BA4B-00A0C93EC93B
),格式为 FAT-32(使用mkfs.vfat -F 32
) - “MSR” 是一个 16 MiB 分区,类型为
Microsoft reserved
(类型代码0c01
或类型 GUIDE3C9E316-0B5C-4DB8-817D-F92DF00215AE
),未格式化 - “Win” 将是一个 32 GiB 分区,类型为
Microsoft basic data
(类型代码0700
或类型 GUIDEBD0A0A2-B9E5-4433-87C0-68B6B72699C7
),格式为 NTFS(使用mkfs.ntfs --fast
) - “WinRE” 将是一个 1 GiB 的分区,类型为
Microsoft basic data
,格式为 NTFS(使用mkfs.ntfs --fast
) - “Raw” 将是未格式化、未指定大小、类型为 的分区
Microsoft basic data
。
为了描述场景,我将使用字符串,例如1:ESP, 2:MSR, 3:Win, 4:WinRE, [remaining]
数字代表分配的分区号gdisk
(在 ArchLinux 上),字符串中项目的顺序描述分区和可用空间的物理磁盘顺序,括号描述可用空间(不包括 GPT 标头本身)。
以下是安装成功(没有任何错误)且系统启动的情况。
1:ESP, 2:MSR, 3:Win, 4:WinRE, [remaining]
1:Win, 2:WinRE, 3:MSR, 4:ESP, [remaining]
2:MSR, 1:ESP, 3:Win, 4:WinRE, [remaining]
1:Win, 2:WinRE, 3:MSR, 5:ESP, [remaining]
以下是安装成功(没有任何错误)但系统无法启动的情况。所有情况都以蓝屏结束,错误代码为INACCESSIBLE_BOOT_DEVICE
。
2:MSR, 3:ESP, 4:Win, 5:WinRE, [remaining]
[1 MiB], 2:Raw, 3:ESP, 4:MSR, 5:Raw, 6:Win, 7:WinRE, [remaining]
[1 MiB], 3:ESP, 4:MSR, [32 GiB], 6:Win, 7:WinRE, [remaining]
1:ESP, 2:MSR, 3:WinRE, 5:Win, [remaining]
我在 VirtualBox 中测试了所有这些场景,但我相当确定这也会在物理机器上发生(尽管我没有任何多余的机器)。
我现在的问题是,这是否是预期的行为?我当然找不到任何文档来排除所有失败的情况作为有效的分区布局。也许你们知道得更多。
如果有人可以在 VirtualBox 中、使用其他虚拟化软件或物理机器上重现此行为,我也会感兴趣。
答案1
不,不是。通常情况下是这样的,这是个好主意,因为如果您必须修复分区,您知道它从哪里开始。
答案2
好吧,在仔细研究了这些场景(并进行了更多实验)之后,我得出的结论是
- 分区本身的顺序似乎根本不重要,
- GPT 中分区条目的顺序似乎有时很重要,
- 分配的 GPT 条目的每个连续范围的顺序似乎无关紧要。
我最好的猜测是,Windows 引导加载程序在启动系统时,通过从头到尾迭代 GPT 条目来搜索 Windows 分区,并在发现未分配的分区条目(类型 GUID 00000000-0000-0000-0000-000000000000
)时终止搜索。
如果这是真的,那么 Windows 分区必须位于分配的 GPT 条目的第一个连续范围内。