Debian 上 /boot/efi 分区的 RAID 1

Debian 上 /boot/efi 分区的 RAID 1

我安装了 CentOS 8,其中分区和 RAID 1 配置是使用 CentOS 安装程序的自动分区完成的。这是输出lsblk

sda         8:0    0 558.9G  0 disk
├─sda1      8:1    0    50G  0 part
│ └─md127   9:127  0    50G  0 raid1 /
├─sda2      8:2    0    20G  0 part
│ └─md126   9:126  0    20G  0 raid1 [SWAP]
├─sda3      8:3    0     1G  0 part
│ └─md125   9:125  0  1022M  0 raid1 /boot
├─sda4      8:4    0   600M  0 part
│ └─md124   9:124  0   600M  0 raid1 /boot/efi
└─sda5      8:5    0 487.3G  0 part
  └─md123   9:123  0 487.2G  0 raid1 /home
sdb         8:16   0 558.9G  0 disk
├─sdb1      8:17   0    50G  0 part
│ └─md127   9:127  0    50G  0 raid1 /
├─sdb2      8:18   0    20G  0 part
│ └─md126   9:126  0    20G  0 raid1 [SWAP]
├─sdb3      8:19   0     1G  0 part
│ └─md125   9:125  0  1022M  0 raid1 /boot
├─sdb4      8:20   0   600M  0 part
│ └─md124   9:124  0   600M  0 raid1 /boot/efi
└─sdb5      8:21   0 487.3G  0 part
  └─md123   9:123  0 487.2G  0 raid1 /home

如您所见,/boot/efi 分区与任何其他分区一样在 RAID 1 中镜像。现在,我尝试在安装 Debian 时重新创建相同的设置,但无法继续。如果我以这种方式设置分区和 RAID 1,我会在 grub 安装过程中收到安装程序的失败消息(没有其他错误消息,只是“某些安装步骤失败”一般消息)。

截屏:

错误

如果我不镜像 ESP 分区,该错误就会消失。

我意识到镜像 ESP 分区听起来不太可行,环顾四周似乎每个人都同意。但 CentOS 安装程序设法以某种方式做到了这一点。

我需要做什么才能在 Debian 上重新创建相同的设置?

答案1

感谢@cas 的评论,我已经完成了这项工作。

步骤主要是:

  1. 我安装了 Debian,但没有为 ESP 分区设置 RAID。在分区过程中,我已经创建了两个相同的分区,标记为 ESP 分区。它们分别/dev/sda1位于/dev/sdb1
  2. /boot/efi我已经复制了其他地方的内容( /boot/eficopy)。
  3. umount /boot/efi
  4. mdadm --create --verbose /dev/md3 --level=1 --raid-devices=2 --metadata=1.0 /dev/sda1 /dev/sdb1。当然,如果已经是活动的 MD 设备,请更改/dev/md3为其他设备/dev/md3
  5. mkfs.vfat /dev/md3
  6. 找到分区的 UUID/dev/disk/by-uuid
  7. 使用新的 UUID更改/boot/efi条目/etc/fstab
  8. mount /boot/efi
  9. 将备份中的数据/boot/efi再次复制到

重启成功了。

编辑: 似乎不是备份/boot/efi分区,而是

grub-install --efi-directory=/boot/efi

执行恢复其内容的工作(在上面的步骤 9),尽管我收到了很多我无法理解的警告。

编辑2:根据 wiki 页面,人们可能应该考虑使用元数据版本 1.0 而不是 0.9mdadm 指南

版本 1.0 仍然要求(对于此用例)将超级块放置在设备的末尾,但还包括“mdadm 的现代功能”,使用通用布局格式如 1.1 和 1.2。

答案2

在遇到无数问题后技嘉的解决方案,我放弃了并发明了一个完全不同的解决方案。

问题:

  • 文件系统需要对齐
  • fsck.msdos 实际上并不处理 SSD 上 FAT 的失败写入(由于写入过程中断电)。
  • mdraid1.0 技巧似乎仅在您不使用写入意图时才起作用,这是一个坏主意。
  • Linux 内核不知道有序写入;如果中途断电,写入 /boot/efi 仍然可以禁用启动。太糟糕了; DOS 内核(偶然)正确地做到了这一点。

我对最后一个问题的解决方案是最终放弃实际镜像,并保留第二个 SSD 以及升级后从已知良好状态同步的 EFI 备份副本。我从各个部分组装了一个完整的解决方案。

我只有 16 位汇编所需的工具;所以这个解决方案就像它看起来一样疯狂。我很遗憾我没有更好的工具,但坦率地说,我不会为了在 stackexchange 上获得声誉而将这些工具移植到 x64。无论如何,我需要 16 位工具来处理我存档的旧 DOS 游戏。我们这里使用的是 FreeDOS 在现代系统上进行维护工作;这既令人着迷又令人恐惧。

你会需要:

  1. 8086小https://github.com/ecm-pushbx/8086tiny

(如果您有一个可用的 SDL 控制台,Dosbox-x 也能正常工作;但您还需要 SHUTDOWN.EXE)

  1. FreeDOS(实际上包含在 8086tiny 中,所以没有更多的软件包)

  2. 我的SSDFMT,它实际上发出一个对齐的文件系统

  3. 我的flushbuf,因为我无法使用的模拟器实际上会强制写入磁盘。我可以轻松地修补 8086tiny 来做到这一点,但这是权宜之计。flushbuf只是打开它的论点并呼吁fdatasync它。

begin-base64 755 /boot/flushbuf
f0VMRgIBAQMAAAAAAAAAAAIAPgABAAAAeAAgAAAAAABAAAAAAAAAAHgAAAAA
AAAAAAAAAEAAOAABAAAAAAAAAAEAAAAFAAAAAAAAAAAAAAAAACAAAAAAAAAA
AAAAAAAA/gAAAAAAAAD+AAAAAAAAAAAQAAAAAAAAWEiD+AJ1QV9fSDH2uAIA
AAAPBUiFwHwJSJe4SwAAAA8F99h0G1C/AgAAAEiNNCX3ACAAugcAAAC4AQAA
AA8FWJe4PAAAAA8FvwIAAABIjTQl4AAgALoXAAAAuAEAAAAPBb8OAAAA69lV
c2FnZTogZmx1c2hidWYgZGV2aWNlCkVycm9yIQo=
====

(是的,这是一个完整的 Linux x64 二进制文件。)

  1. 能够在出现问题时启动可移动媒体。

配置

这个答案是使用/dev/sda1/dev/sda2作为设备编写的。如果你没有这样一个系统,其中/dev/sda和的身份/dev/sdb是稳定的,那么你必须使用/dev/disk/by-id/...值代替。/dev/disk/by-uuid行不通的。相信我。您还应该为所有事情编写脚本,因为/dev/disk/by-id/...每次打字设备都是一剂药。我发现保存脚本的最佳位置是/boot.

  1. 将 SSDFMT.COM 加载到 8086tiny 上fd.imgmtools或者mount -o loop可以使用

  2. 正如 root 所做的那样

   (cd /boot/efi && tar -zcf /boot/efi-bak.tgz *)
   umount /boot/efi
   STTY_SAVE=`stty -g` 
   stty cols 80 rows 25
   ./8086tiny bios.bin fd.img hd.img
   SSDFMT
  1. 在 SSDFMT 中,选择磁盘 1(唯一可见的磁盘)、SSD 上的实际扇区大小,然后选择兼容性 5。强制 LBA 不适用于 8086tiny。

  2. 为了避免以后出现楔形控制台,我们需要在硬盘上安装 FreeDOS。

    QUITEMU
   ./8086tiny bios.bin fd.img hd.img
    SYS C:
    XCOPY /e *.* C:\
    QUITEMU
    /boot/flushbuf /dev/sda1
    stty `$STTY_SAVE`
  1. 这会安装,但CONFIG.SYS仍然AUTOEXEC.BAT指向软盘上的文件。让我们解决这个问题。
    mount /boot/efi
    sed -i 's/A:\\/C:\\/g' /boot/efi/CONFIG.SYS
    sed -i 's/A:\\/C:\\/g' /boot/efi/AUTOEXEC.BAT
  1. 是时候恢复 EFI 了:
    (cd /boot/efi && tar -zxf /boot/efi-bak.tgz)
  1. 创建脚本以在升级和重新启动后同步镜像(以验证启动是否正常)
#!/bin/sh -x
umount /boot/efi
/boot/flushbuf /dev/sda1 # replace sda1 and sdb1 with your devices
cat /dev/sda1 > /dev/sdb1
/boot/flushbuf /dev/sdb1
mount /boot/efi
  1. 创建反向脚本(用于文件系统无法修复时)
#!/bin/sh -x
[ -d /boot/efi/EFI ] && umount /boot/efi # probably won't be mounted
/boot/flushbuf /dev/sda2 # replace sda1 and sdb1 with your devices
cat /dev/sdb1 > /dev/sda1
/boot/flushbuf /dev/sda1
mount /boot/efi
  1. 运行步骤 7 中给出的脚本

请注意,第二个磁盘尚未完全注册为作为 EFI 磁盘启动。我很确定我在 BIOS 设置中修复了这个问题,而不是在我的操作系统中。

如果fsck.msdos在启动时发现错误,它可能无法修复它们。如果发现重要错误,则需要首先运行 SSDFMT 的撕裂写入修复程序。如何?通过在模拟器中启动 EFI 分区(!)。

应保存启动器脚本:

#!/bin/sh -x
umount /boot/efi # making sure
./8086tiny bios.bin /dev/null @/dev/sda1
fsck.msdos /dev/sda1
/boot/flushbuf /dev/sda1
mount /boot/efi

请注意,在执行损坏的写入检查/修复过程后,运行此脚本会让您进入 DOS 提示符。您可以运行 QUITEMU 返回。我很确定对于是否CHDKSK在模拟器中运行存在着诚实的意见分歧。我没有足够的经验,不知道哪个更好。

额外奖励:我发现如果您在 debian 主要更新后对 EFI 分区进行碎片整理,您可以获得更快的启动速度(据我所知,这是启动徽标导致的)。您可以从 grep DEFRAG.EXE书目并将其复制到您的 EFI 分区并稍后运行。

相关内容