我创建了一个带有 uefi 启动和加密 lvm 分区的服务器设置，如您在此处所见：
root@debian:~# lsblk -o name,uuid,type,size
NAME UUID TYPE SIZE
sda disk 52G
|-sda1 6EE2-5855 part 512M
|-sda2 2dcfe94a-3c21-e08f-805c-8ef32eabf50f part 954M
| `-md128 8e000041-b831-4aea-b46d-85efdcdd5371 raid1 953M
`-sda3 a6172091-d026-463f-ac1b-8edfe2419cb8 part 50.5G
`-md129 429397a0-8620-4b87-ac2d-aec37bd26b36 raid1 50.1G
`-md129_crypt YR7iyx-6ELU-Vg6F-bPtB-mSOA-LYJw-JQYPpK crypt 50G
|-vgroot-main ddf156a7-3b64-4c9e-a9cc-eb15755f1995 lvm 14G
|-vgroot-swap 0a1af000-c578-4d94-a90a-2cd685409f99 lvm 1.9G
`-vgroot-vm0 lvm 14G
sdb disk 52G
|-sdb1 03F8-4D52 part 512M
|-sdb2 2dcfe94a-3c21-e08f-805c-8ef32eabf50f part 954M
| `-md128 8e000041-b831-4aea-b46d-85efdcdd5371 raid1 953M
`-sdb3 a6172091-d026-463f-ac1b-8edfe2419cb8 part 50.5G
`-md129 429397a0-8620-4b87-ac2d-aec37bd26b36 raid1 50.1G
`-md129_crypt YR7iyx-6ELU-Vg6F-bPtB-mSOA-LYJw-JQYPpK crypt 50G
|-vgroot-main ddf156a7-3b64-4c9e-a9cc-eb15755f1995 lvm 14G
|-vgroot-swap 0a1af000-c578-4d94-a90a-2cd685409f99 lvm 1.9G
`-vgroot-vm0 lvm 14G
sdc disk 8G
`-sdc1 236c1834-cc33-9303-0905-1bd4de8c1399 part 8G
`-md127 25cdc3e1-d3cf-4592-9db9-538e0c9205bd raid1 8G
sdd disk 8G
`-sdd1 236c1834-cc33-9303-0905-1bd4de8c1399 part 8G
`-md127 25cdc3e1-d3cf-4592-9db9-538e0c9205bd raid1 8G
sr0 rom 1024M
基于Debian 10，分区挂载如下：
root@debian:~# df
Filesystem 1K-blocks Used Available Use% Mounted on
udev 2003472 0 2003472 0% /dev
tmpfs 404052 5564 398488 2% /run
/dev/mapper/vgroot-main 14647296 1041884 11566020 9% /
tmpfs 2020252 0 2020252 0% /dev/shm
tmpfs 5120 0 5120 0% /run/lock
tmpfs 2020252 0 2020252 0% /sys/fs/cgroup
/dev/md128 960504 51472 860240 6% /boot
/dev/sdb1 523248 10432 512816 2% /boot/efi
tmpfs 404048 0 404048 0% /run/user/0
根分区位于 vgroot-main。必须在启动时使用 luks 解密，并且还与 raid1 镜像。
root@debian:~# mdadm --detail /dev/md/129
/dev/md/129:
Version : 1.2
Creation Time : Thu Oct 3 18:53:03 2019
Raid Level : raid1
Array Size : 52487168 (50.06 GiB 53.75 GB)
Used Dev Size : 52487168 (50.06 GiB 53.75 GB)
Raid Devices : 2
Total Devices : 2
Persistence : Superblock is persistent
Update Time : Fri Oct 4 21:55:24 2019
State : clean
Active Devices : 2
Working Devices : 2
Failed Devices : 0
Spare Devices : 0
Consistency Policy : resync
Name : debian:129 (local to host debian)
UUID : a6172091:d026463f:ac1b8edf:e2419cb8
Events : 517
Number Major Minor RaidDevice State
3 8 3 0 active sync /dev/sda3
2 8 19 1 active sync /dev/sdb3
设置工作正常。但是当我移除一个磁盘时，系统无法挂载根文件系统。超时后，它会返回到 initramfs shell。令人惊讶的是，md129 随后显示为非活动状态并显示为 raid0。
是否有人知道为什么内核将 raid 组装为 0 级，除非分区 sda3 本身显示为 raid1？
答案1
这可能是本文中描述的同一问题的一个实例Bugzilla 报告。这是由于 dracut 与应该组装根阵列的系统单元之间的相互作用不良造成的。
请务必更新您的系统，因为该问题可以/应该通过 dracut 更新来解决。作为一种解决方法，请尝试传递rd.retry=30到内核命令行（在grub提示符下）。
来自 bugzill 的附加详细信息解释了事件序列：
- mdadm --incremental 不会启动/运行意外发现降级的阵列；
- dracut 应在超过 2/3 超时值后强制启动阵列。按照当前 RHEL 默认设置，该时间是 180/3*2 = 120 秒；
- systemctl 预计最多 90 秒内挂载根文件系统。如果不成功，它会中止 dracut 脚本并转到紧急 shell。90 秒低于 dracut 超时时间，这意味着 dracut 没有机会强制启动阵列。
降低 rd.retry 超时时间（按照手册页的建议进行设置）可使 dracut 强制启动阵列，从而使 systemctl 服务成功运行。
答案2
最后，我在 initramfs 中手动组装了 raid。退出 initramfs shell 后，内核继续启动。我找不到初始行为的修复方法，但现在我知道如何处理它了。