在我们的实验室中，我们有几十台安装了 Windows 10 和 Ubuntu 的双启动计算机，根据机器的不同，使用传统 (CSM) 或 UEFI 启动。在这两种情况下，都使用 GRUB2 作为引导加载程序。所有机器都有自定义分区方案没有Windows 恢复分区，因为后者对于 Windows 的正常启动/工作来说不是必需的。如果机器出现问题，我们宁愿从网络重新镜像它（使用 PXE 启动的 Linux）。
现在问题出现在 Windows 功能更新中，最新版本是 2004（编辑：在撰写此问题时，但问题仍然存在于较新的更新中，例如 21H1）。当安装其中一个更新时，它会稍微缩小 Windows 系统分区以重新添加恢复分区。考虑到其缩小的大小，可以不去管它，但是此操作会破坏 GRUB因为 Linux 分区编号会发生变化，而 GRUB 的第一阶段无法理解分区标签，因此无法找到第二阶段（即使在 UEFI 机器上也是如此）。如果机器在提示符上挂起GRUB rescue，则无法远程更正该问题……有时需要让必须保持远程访问的机器离线数小时（甚至更长时间）。
由于我们对恢复分区没有任何用处，因此问题是如何防止更新创建它在第一点？当然，我们可以在对机器进行映像处理时将其放在那里，但考虑到我们实际上并不想要它，这似乎只是浪费磁盘空间。
编辑为了清楚起见：（A）我提到的分区是不是FAT32 格式的 UEFI 系统分区 (ESP)，如果没有它，Windows 甚至无法在 UEFI 设置上启动。它是 NTFS 格式，大小为 400-500 MB。我们没有理由在 UEFI 系统上删除 ESP，顺便说一句，这也是 UEFI-GRUB 所必需的……（二）我观察到一些情况，在更新成功的情况下恢复分区没有创建。这可能与系统分区上的可用空间有关，或者与 MBR 系统上的主分区数量有关（最多 4 个 - 如果已经有 4 个，Windows 就无法轻易添加另一个）。（C）主要研究如何在当前安装的系统上防止这种情况发生。对于未来的安装，我们可以包含一个预先创建的恢复分区，以防止更新更改分区方案。
编辑：经过几个月对几台机器的观察，似乎（A）更新过程无需恢复分区即可正常运行，并且（二）在已经具有 4 个主分区而没有扩展分区的 MBR 格式磁盘上，永远不会创建分区。因此，一种解决方案可能是让 PXE 加载的代码在启动前运行，以创建占位符分区来填充 MBR 表……但修改 MBR 总是会带来麻烦。但在 UEFI 机器上，我看不到明确的解决方案，因为 GPT 总是有足够的条目来创建恢复分区。
答案1
Windows 10 需要系统分区才能正常运行。原因之一是升级过程需要它。
与其与系统的工作方式作斗争，不如重新分区磁盘。由于您是从服务器集中部署，所以这应该不是问题。
将 Windows 部署到基于 UEFI 的设备时，必须使用 GUID 分区表 (GPT) 文件系统格式化包含 Windows 分区的硬盘驱动器。其他驱动器可以使用 GPT 或主启动记录 (MBR) 文件格式。
系统分区
设备必须包含系统分区。在 GPT 驱动器上，这称为 EFI 系统分区或 ESP。此分区通常存储在主硬盘上。设备将启动到此分区。此分区的最小大小为 100 MB，并且必须使用 FAT32 文件格式进行格式化。