总结 有没有办法正确启动丢失或发生故障的基于软件的 RAID1（不是由用户首先导致的故障）？
需要明确的是，无需硬盘即可启动基于软件的 RAID1如果在重新启动之前，您正确地使驱动器失效。我知道这很主观，但这似乎不是一个合理的解决方案，也不是一个可接受的答案。例如：一个设施断电，硬盘驱动器在断电的同时发生故障。尝试使用未“正确”故障的降级硬盘驱动器进行启动将导致系统进入紧急模式。
我已经阅读了这里和其他论坛的许多帖子，它们都建议您在所有分区上安装 grub，或者手动重建 grub、添加nofail选项/etc/fstab或其他看似简单的解决方案；但事实是，这些建议都没有起作用。
虽然我已经接受了这个不可能的事实，但这件事还是有些不太容易解决。所以，我想看看是否有其他人遇到过这个问题或有解决方案。
我的环境：
我有一块较旧的主板，不支持 UEFI，所以我必须启动传统模式/MBR。
操作系统：
cat /etc/redhat-release
Red Hat Enterprise Linux Workstation release 7.6 (Maipo)
核心：
uname –r
3.10.0-957.el7.x86_64
mdadm：
mdadm –version
mdadm – v4.1-rc1 2018-03-22
我的 RAID 是跨三个驱动器的 RAID1。（sda,sdb,sdc）并且有 4 个分区
md1 - /boot
md2 - /home
md3 - /
md4 - swap
我已经在所有分区上安装了 grub，并确保所有启动分区都有启动标志。 所有在相应分区旁边的启动字段中
fdisk /dev/sd[a,b,c]显示-- 和 -- （作为单独的命令，结果为“成功安装”）。*
grub2-install /dev/sd[a,b,c]
复制问题：
- 关闭系统电源，将所有驱动器分配给 RAID，并使 RAID 完全正常运行。
- 移除硬盘
- 电源系统启动
结果：
系统将通过 grub 启动。Gdm 将尝试显示登录屏幕，但大约 20 秒后，它将失败并进入紧急控制台。“正常”系统缺少许多部分。例如，/boot 和 /etc 不存在。似乎没有显示任何内核崩溃消息或问题dmesg。
再次强调，这里的关键是：RAID 必须完全组装，关闭电源并移除驱动器。如果您正确故障驱动器并将其从 RAID 中移除，那么您可以在没有驱动器的情况下启动。
例子：
mdadm --manage /dev/md[1,2,3,4] --fail /dev/sda[1,2,3,4]（作为单独的命令）
mdadm --manage /dev/md[1,2,3,4] --remove /dev/sda[1,2,3,4]（作为单独的命令）
我知道这似乎微不足道，但我还没有找到一个可行的解决方案来启动具有降级 RAID1 的系统。您可能会认为这应该是一个简单的问题，有一个简单的解决方案，但事实并非如此。
任何帮助、意见或建议都将不胜感激。
答案1
启动发生故障的 MD RAID1 阵列肯定是可能的 - 至少如果 BIOS 跳过发生故障的磁盘（如果没有，您可以简单地从幸存的磁盘手动启动）。
对于您的具体问题，您可能会遇到此问题漏洞。摘录（但阅读所有错误报告是个好主意）：
RHEL 7.6 dracut-iniqueue 脚本的默认值为 180 秒（如 RDRETRY 变量中所定义），高于 systemd 根挂载服务（90 秒）。当根位于降级的软件 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。90 秒低于 dracut 超时，这意味着 dracut 没有机会强制启动阵列。降低 rd.retry 超时（按照手册页的建议设置）可使 dracut 强制启动阵列，从而使 systemctl 服务成功。
作为错误应该在最近的 RHEL/CentOS 7 版本中已修复，我强烈建议您更新系统（如果可以）。否则，请尝试将其rd.retry=30作为内核启动选项传递。