在 Debian 10（buster）系统上，我刚刚尝试安装最新grub-pc更新，第一次收到此错误：
Installing for i386-pc platform.
grub-install: warning: your core.img is unusually large. It won't fit in the embedding area.
grub-install: error: embedding is not possible, but this is required for RAID and LVM install.
对组成我的分区的每个磁盘都重复了此操作/boot/。
这个安装非常老了；它是在 2006 年安装的，磁盘已经多次移植到新硬件中，并且操作系统从那时起一直保持最新状态。
因此，设置/boot相当陈旧，但应该仍然可以工作。有四个硬盘驱动器的分区相同：
$ sudo fdisk -u -l /dev/sda
Disk /dev/sda: 298.1 GiB, 320069031424 bytes, 625134827 sectors
Disk model: ST3320620AS
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x00000000
Device Boot Start End Sectors Size Id Type
/dev/sda1 * 63 514079 514017 251M fd Linux raid autodetect
/dev/sda2 514080 6393869 5879790 2.8G fd Linux raid autodetect
/dev/sda3 6393870 625121279 618727410 295G fd Linux raid autodetect
因此，这是一个旧式 MBR，其第一个分区从 63 个扇区开始。每个磁盘的第一个分区放入 4 路 RAID-1，即md0我的/boot：
$ sudo mdadm --detail /dev/md0
/dev/md0:
Version : 0.90
Creation Time : Sun Jun 4 08:18:05 2006
Raid Level : raid1
Array Size : 256896 (250.88 MiB 263.06 MB)
Used Dev Size : 256896 (250.88 MiB 263.06 MB)
Raid Devices : 4
Total Devices : 4
Preferred Minor : 0
Persistence : Superblock is persistent
Update Time : Thu Mar 4 06:52:36 2021
State : clean
Active Devices : 4
Working Devices : 4
Failed Devices : 0
Spare Devices : 0
Consistency Policy : resync
UUID : 78cf4169:e31908f4:e667021c:582159fb
Events : 0.2479
Number Major Minor RaidDevice State
0 8 49 0 active sync /dev/sdd1
1 8 1 1 active sync /dev/sda1
2 8 17 2 active sync /dev/sdb1
3 8 33 3 active sync /dev/sdc1
这个 md 阵列有意具有元数据版本 0.90，以便它可以由 grub 启动，因为它诞生于 grub 不支持 md 的时代；0.90 元数据版本将元数据放在分区的末尾，因此 grub 应该能够读取每个分区，就好像它不是软件 RAID 一样。
grub 已安装到基础磁盘设备，即每个/dev/sd{a,b,c,d}。 软件包的后续升级grub-pc似乎知道运行grub-install /dev/sda，然后对 也一样sd{b,c,d}。
直到今天才出现这个错误。
现在这个系统无法启动了吗？这看起来像是一个错误情况，所以我假设新版本的 grub 实际上还没有安装。
我很困惑为什么它说需要为 RAID/LVM 做些什么，而启动这个系统并不需要这样的支持。
由于某种原因，grub 的大小是否增大了，现在无法容纳每个磁盘的前 63 个扇区？我知道现在的惯例是从 1MB 开始分区，但正如我所说，这是一个非常古老的安装，一直有效。
安装此 grub 更新的最简单方法是什么？如果我需要删除那些第一个分区并以 1MB 启动它们，我可以轻松做到这一点，但在做到这一点之前，我希望先确认这确实是问题所在。
的详细输出grub-install -v /dev/sda非常多，最后以同样的方式结束。我没发现其中有什么用处，但如果有人认为有必要，我会把它包括进去。
答案1
由于某种原因，grub 的大小是否增大了，现在无法容纳每个磁盘的前 63 个扇区？我知道现在的惯例是从 1MB 开始分区，但正如我所说，这是一个非常古老的安装，一直有效。
具体来说，Debian Buster 和 Bullseye 上的最新 grub2 包包括大量的变更日志补丁，其中很多涉及添加先前版本中缺少的检查（例如缓冲区溢出、NULL 取消引用）。
其中一些会影响配置解析器、grub.cfg 脚本执行器和分区表扫描器，所有这些都包含在安装在 MBR 后间隙中的核心映像中。这会稍微增加代码大小。
但是，由于幅度如此之小，您甚至可能会受到不同编译器对同一源输出不同代码的影响，或者受到分发更改编译器标志以添加运行时安全检查的影响。
如果您不断更新系统，这本身就意味着软件不断变化，而“它不能停止工作，因为它一直有效”的理念就会被抛到九霄云外。
这个 md 阵列有意具有元数据版本 0.90，以便它可以由 grub 启动，因为它诞生于 grub 不支持 md 的时代；0.90 元数据版本将元数据放在分区的末尾，因此 grub 应该能够读取每个分区，就好像它不是软件 RAID 一样。
但 GRUB 2 确实有 md 支持现在，这意味着如果它检测到 /boot 位于 mdraid 阵列上，那么它将在其核心映像中包含一个 mdraid 驱动程序 - 即使该阵列恰好是 0.90 RAID1。这会增加核心映像的大小。
（mdraid 支持不仅意味着能够跳过元数据 - 它还意味着能够从 raid0/5/6 阵列读取、识别备用磁盘等等。）
在当前的 Debian Buster 上，一个完全基本的 core.img（仅包含 GRUB 2 内核，没有模块和配置）有 39 个扇区1。使用默认的“biosdisk”、“part_msdos”、“search_fs_uuid”和“ext2”模块，则有 54 个扇区 – 如果在上面添加“mdraid09”模块，则已经有 64 个扇区，而您的磁盘只剩下 62 个扇区可用（不包括位置 0 处的 MBR 引导扇区）。
1使用 测量grub-mkimage -O i386-pc -p /boot [modules] | wc -c。
| 包裹 | 内核 + 5 个模块 | 磁盘大小 |
|---|---|---|
| 拉伸 2.02~beta3-5+deb9u2 | 31186 字节 | 61（~60.9）个扇区 |
| Buster 2.02+dfsg1-20+deb10u2 | 32 061 字节 | 63（~62.6）个扇区 |
| Buster 2.02+dfsg1-20+deb10u4 | 32729 字节 | 64（~63.9）个扇区 |
| 靶心 2.04-15 | 31902 字节 | 63（~62.3）个扇区 |
| 靶心 2.04-16 | 33 072 字节 | 65（~64.6）个扇区 |
| Arch Linux 2：2.04-10 | 32131 字节 | 63（~62.75）个扇区 |
grub-install 还需要添加一个简短的两行配置，将 GRUB 内核指向您的实际 /boot 位置，但我们假设它适合剩余的 1/4 个扇区。
在 BIOS 系统上，grub-install 还使用了一些额外的空间用于 Reed-Solomon 错误校正码，以便在其中一个扇区损坏时能够启动 - 我找不到有关它使用了多少空间的信息，但至少有几个扇区。
因此您有以下几种选择：
- 将 /boot 分区移动到另一个偏移量，例如扇区 1024 或 2048。
- 尝试安装
--no-rs-codes并希望结果会只是小到可以容纳。 - 构建一个不包含 mdraid09 的自定义 GRUB 核心映像（可能
grub-install --skip-fs-probe --modules=...，但更可能使用grub-mkimage），假装它仍然是 2006 年并且 GRUB 还没有 md 支持。