我有一台小型服务器（HP ProLiant MicroServer Gen8），运行 Ubuntu 18.04 64 位最新的 HWE 通用内核（5.4.0.74.83~18.04.67）；它有两个 SATA 驱动器，GPT 分区，但以传统 BIOS 模式启动。两个驱动器的分区如下：
- 分区 1 (1 MB)：“影子”启动分区，用于 GRUB 代码；
- 分区 2（几个 TB）：BtrFS，包含 的
@子卷/和@home的子卷/home；/boot确实位于/@/boot - 分区 3 (4 GB)：交换
两个驱动器的 BtrFS 分区在 BtrFS 镜像配置中绑定在一起。
几天前，电源断了，NAS 再也没有恢复。在启动时，我只得到了可怕的“grub 救援”，说它找不到目标分区（我认为是用 BtrFS 卷 GUID 指定的）。尝试执行ls (hd0,gpt2)（或者实际上，任何其他分区）告诉我“未知文件系统”（即使insmod btrfs似乎工作正常）。
我认为 GRUB 出了问题，因此我使用 Ubuntu 18.04 服务器安装密钥进行启动，并尝试修复 GRUB，如下所示：
mount /dev/sda2 /mnt（/dev/sda2是 BtrFS 分区）；我可以看到所有数据仍然在那里；mount --bind /dev /mnt/@/dev；对于/dev/pts、/proc、/sys、也一样/run（否则，由 resolvconf 在实时系统和“损坏”系统中管理的 DNS 将不会运行）chroot /mnt/@- 在 chroot 内部，我这样做了，
mount /dev/sda2 / -o subvol=@否则grub-probe会grub-install感到困惑；在 chroot 之外，重新执行了绑定操作，因为它被 remount 所掩盖； mount -a
然后（经过多次尝试）我尝试了几件事：
- 重新安装 GRUB 至
/dev/sda(grub-install /dev/sda)；尝试过有--recheck和没有，都试过了grub-mkdevicemap（从生成的文件中手动删除 USB 密钥设备device.map）； - 重新创建 GRUB 配置（
update-grub）； - 升级了内核，其实并不认为这是内核版本的问题，而是为了确保（1）我尝试启动的程序肯定没有损坏，并且（2）有新制作的 initrd
- 检查内核/initrd 文件是否都可以读取（例如使用
sha1sum /boot/*），因为有关该信息的 GRUB 消息很可怕 - 请参阅下文； - 将 GRUB（存储库中最新的 2.02 版本）降级到几个补丁版本之前，因为我怀疑断电与此没有太大关系，但反而是一些升级破坏了它
- 运行
btrfs check /dev/sda2和btrfs check /dev/sdb2；都运行无错误，唯一的问题（两者都报告）是在单个块的可用空间缓存中（我后来使用/dev/sda2/选项挂载clear_cache以确保万无一失）
所有这些事情的结果都远非令人鼓舞：如果做得正确，这些事情总是会再次引导我grub rescue，但这次有一个更有趣的转折：
- 它能读取一些 BtrFS 卷，但是，可以这么说，几乎没有；执行
ls (hd0,gpt2)/显示子卷，但ls (hd0,gpt2)/@都ls (hd0,gpt2)/@home显示空目录（这就是为什么它找不到(hd0,gpt2)/@/boot/进入正常模式所需的所有内容）； - 最有意思的是，还有其他子卷，分别是Ubuntu版本升级脚本做的三个快照；那些改为使用子卷能被 GRUB 读取；不仅如此：如果我调整
prefix，root等 以指向快照子卷内部，我就可以设法进入“正常” GRUB 模式，再次调整菜单项中的路径，启动快照中的旧内核（唯一的问题是它找不到模块，因为我正在加载不再安装在当前根文件系统中的旧内核版本，但鉴于它们并未真正使用，因此可以正常启动）。
有一次（我可能在上述mountchroot 舞蹈中搞砸了一些东西）我设法重新启动并直接进入正常模式，但 GRUB 总是在启动菜单的所有条目中发现一些错误：特别是，对于每个条目，它都无法加载内核或 initrd，给出一个可怕的“未找到 inode”错误消息（或者，在另一种情况下，“找不到块描述符”；除了 GRUB 源本身之外，这两个信息在 Google 中都没有匹配项，这始终是一个不好的迹象）；请注意，正如我上面所说的，在实时 USB 会话中它们都是可读的。
额外的想法：
- 服务器主板的 SATA 控制器有点奇怪的问题 - 磁盘枚举似乎需要很多时间，这导致我在升级到 18.04 时出现此错误https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1752961；唯一（令人难过的）解决办法是
sleep 5在 initrd 之前添加一个btrfs scan；这也导致第二个磁盘/dev/sdc出现一些实时 USB 运行，但这似乎并不重要（当它发生时，我还调整了文件名/dev，但这似乎与结果不是特别相关）； - 我想到的是 RAM 有问题，尽管感觉不太可能，因为 (1) 一旦启动系统就会正常运行，并且 (2) 它是 ECC RAM，我预计至少会出现某种错误消息；无论如何，我启动了 MemTest，它运行了几个小时都没有出现错误；
iLO 在启动时报告自检错误，但这似乎无关。后来，升级到最新固件版本并清除其 NVRAM 后，错误得以解决；正如预期的那样，这没有任何区别，但至少 POST 屏幕更清晰一些
我目前的猜测是这样的：HWE 内核使用的 BtrFS 版本具有一些与“常规”Ubuntu 18.04 GRUB 版本不兼容的功能，因此所有“现在”写入的文件/目录对于 GRUB 来说都可能存在读取问题；事实上，我看到在 GRUB 2.02 和当前版本 (2.06) 之间对 BtrFS 进行了一些改进，尽管对于 zstd 压缩，我的磁盘上没有启用。也许尝试更新的 GRUB 可以解决这个问题？但是是否有一些适用于 18.04 的打包 GRUB 2.06 版本？
长话短说：您知道问题可能是什么以及如何解决它吗？
答案1
知道可能是什么问题吗
事实并非如此，尽管我和你一样怀疑 grub 和 btrfs 可能无法很好地协同工作。
以及如何修复它？
您是否考虑过省去这个麻烦并移到/bootbtrfs 的外部？
你可以划出一点空间（将交换分区缩小 1G -无论如何，交换被高估了) 并为自己创建一个/boot由这额外的 1G 组成的新分区。
对于磁盘冗余，您可以使用软件 raid1 - grub 对其支持很好。
您将失去的快照功能/boot，尽管/boot它足够小，可以通过其他方式恢复它。