在驱动器丢失或出现异常故障的情况下正确启动基于软件的 RAID1

Question

长话短说；博士。 有没有办法在驱动器丢失或发生故障（不是用户首先发生故障）的情况下正确启动基于软件的 RAID1？

\n

需要明确的是，如果您在重新启动之前正确地使驱动器出现故障，则可以在没有硬盘的情况下启动基于软件的 RAID1 。我知道这是主观的，但这似乎不是一个合理的解决方案，也不是一个可接受的答案。例如; 设施停电，硬盘驱动器在断电的同时发生故障。尝试使用\xe2\x80\x99t \xe2\x80\x9cproperly\xe2\x80\x9d 的降级硬盘启动失败将导致系统进入紧急模式。

\n

我\xe2\x80\x99已经阅读了这里和其他论坛上的许多帖子，都建议您在所有分区上安装grub，或手动重建grub，添加nofail到/etc/fstab选项，或其他看似简单的解决方案；但现实是这些建议都没有奏效。

\n

虽然我\xe2\x80\x99已经接受了这是不可能的，但关于这件事\xe2\x80\x99并不轻松。所以，我\xe2\x80\x99m看看其他人是否有这个问题或有这个问题的解决方案。

\n

我的环境：

\n

我有一个不支持 UEFI 的旧主板，所以我启动传统模式/MBR。
\n操作系统：

\n

cat /etc/redhat-release\nRed Hat Enterprise Linux Workstation release 7.6 (Maipo)\n

\n

核心：

\n

uname \xe2\x80\x93r\n3.10.0-957.el7.x86_64\n

\n

妈妈：

\n

mdadm \xe2\x80\x93version\nmdadm \xe2\x80\x93 v4.1-rc1 2018-03-22\n

\n

我的 RAID 是跨三个驱动器的 RAID1。( sda,sdb,sdc) 有 4 个分区

\n

md1 - /boot\nmd2 - /home\nmd3 - /\nmd4 - swap\n

\n

我已在所有分区上安装了 grub，并确保所有引导分区都有引导标志。\n 所有分区都在相应分区旁边的引导字段中fdisk /dev/sd[a,b,c]显示 a \n -- 和 -- \n （作为单独的命令，使用 \xe2\ x80\x98安装成功\xe2\x80\x99结果）。*

grub2-install /dev/sd[a,b,c]

\n

复制问题：

\n

\n
1. 在分配给 RAID 的所有驱动器和 RAID 完全运行的情况下关闭系统电源。
\n
2. 移除硬盘
\n
3. 电源系统启动
\n

\n

结果： \n系统将通过 grub 启动。Gdm 将尝试显示登录屏幕，但大约 20 秒后，它将失败并转到紧急控制台。\xe2\x80\x9cnormal\xe2\x80\x9d 系统缺少许多部分。例如; /boot 和 /etc 不存在。似乎没有显示任何内核恐慌消息或问题dmesg。

\n

再说一次，这里的关键是；RAID 必须完全组装、断电并移除驱动器。如果您正确地将驱动器故障并将其从 RAID 中删除，那么您可以在没有驱动器的情况下启动。

\n

示例：
\n mdadm --manage /dev/md[1,2,3,4] --fail /dev/sda[1,2,3,4]（作为单独的命令）
\n mdadm --manage /dev/md[1,2,3,4] --remove /dev/sda[1,2,3,4]（作为单独的命令）

\n

我知道这看起来微不足道，但我尚未找到可行的解决方案来启动具有降级 RAID1 的系统。您可能会认为这应该是一个简单的问题，有一个简单的解决方案，但事实似乎并非如此。

\n

任何帮助、意见或建议将不胜感激。

\n

Answer 1

启动发生故障的 MD RAID1 阵列肯定是可能的 - 至少如果 BIOS 跳过发生故障的磁盘（如果没有，您可以简单地从幸存的磁盘手动启动）。

对于您的具体问题，您可能遇到了这个错误。摘录（但阅读所有错误报告是个好主意）：

RHEL 7.6 dracut-iniqueue 脚本的默认值为 180 秒（如 RDRETRY 变量中所定义），该值高于 systemd 根挂载服务（90 秒）。当 root 驻留在降级的软件 RAID1 设备上时，这可能会导致系统无法启动（用户被置于紧急 shell）。有关问题的示例，请参阅 https://bugzilla.redhat.com/show_bug.cgi?id=1451660# 。请注意，只有当 RAID 设备预期自身正常，但意外发现阵列在启动过程中降级时，才会发生这种情况。

在启动时传递“rd.retry=30”可以修复阵列启动降级的问题，因为阵列在 systemctl root mount 服务超时之前被强制启动。此外，长 dracut rd.retry 超时与 dracut.cmdline(7) 手册页不一致，其中规定超时应为 30 秒。

...

附加信息：我将问题追溯到 mdadm --incremental、dracut 超时（rd.retry）和 systemctl 默认超时如何交互：

• mdadm --incremental 将不会启动/运行意外发现降级的阵列；
• dracut 应在超时值经过 2/3 后强制启动数组。使用当前 RHEL 默认值，这相当于 180/3*2 = 120 秒；
• systemctl 期望最多在 90 秒内挂载根文件系统。如果不成功，它将中止 dracut 脚本并转到紧急 shell。比 dracut 超时低 90 秒，这意味着 dracut 没有机会强制启动阵列。降低 rd.retry 超时（按照手册页建议进行设置）使 dracut 能够强制启动阵列，从而使 systemctl 服务能够成功。

由于该错误应该在最近的 RHEL/CentOS 7 点版本中得到修复，因此我强烈建议您尽可能更新您的系统。否则，尝试rd.retry=30作为内核启动选项传递。