主页 / server / 问题 / 1081651
Accepted
Will Roberts
Asked: 2021-10-26 09:54:22 +0800 CST

正确引导缺少驱动器或故障驱动器的基于软件的 RAID1

  • 772

tl;博士。 有没有办法在驱动器丢失或故障（不是用户首先失败）的情况下正确启动基于软件的 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 –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]all*在适当分区旁边的引导字段中 显示 a
- 和 -
grub2-install /dev/sd[a,b,c]（作为单独的命令，具有“成功安装”结果）。

复制问题：

  1. 在分配给 RAID 的所有驱动器和 RAID 完全可操作的情况下关闭系统。
  2. 卸下硬盘
  3. 电源系统启动

结果： 系统将通过 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 的系统。您会认为这应该是一个简单解决方案的简单问题，但事实并非如此。

任何帮助、输入或建议将不胜感激。

linux redhat boot mdadm software-raid

1 个回答

  1. Best Answer

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

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

    RHEL 7.6 dracut-iniqueue 脚本的默认值为 180 秒（在 RDRETRY 变量中定义），高于 systemd 根挂载服务（90 秒）。当 root 驻留在降级的软件 RAID1 设备上时，这可能导致系统无法启动（用户被丢弃到紧急外壳）。有关问题的示例，请参阅 https://bugzilla.redhat.com/show_bug.cgi?id=1451660# 。请注意，这只发生在 RAID 设备希望自己健康，但它意外地发现阵列在引导期间降级时。

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

    ...

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

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

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

    • 6

相关问题