正確引導缺少驅動器或故障驅動器的基於軟體的 RAID1

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 的系統。您會認為這應該是一個簡單解決方案的簡單問題，但事實並非如此。

任何幫助、輸入或建議將不勝感激。

啟動故障的 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作為核心引導選項傳遞。

引用自：https://serverfault.com/questions/1081651