因此，在我的系统最近进行 dnf 更新期间，显然根据系统日志，selinux 在某个时刻突然禁止对内核进行写访问，然后将 raid 驱动器标记为“失败”。
我通过从 fstab 中取出有问题的 raid 驱动器来使系统重新运行（我重新启动，因为有一个新内核，并且不知道 raid 驱动器突然停止运行）。
所以，一切看起来都很好，但突袭驱动器不会“启动”，所以我做了一个
for x in a b c d e f; do
mdadm --examine /dev/sd${x}1 > mdstats.$x;
done
然后查看 mdstats.x 文件中每个 raid 元素的状态。这实际上是个好消息，因为所有设备都被标记为“干净”，并且所有设备都具有完全相同数量的“事件”。
从命令行查看 raid 设备的状态，我做了
% cat /proc/mdstat
Personalities :
md127 : inactive sdf1[3] sde1[0] sda1[6] sdb1[5] sdd1[1] sdc1[4]
17581198678 blocks super 1.2
unused devices: <none>
我将包括两个 mdadm --examine 输出，以防我错过了一些东西，但它们看起来都很相似，
% mdadm --examine /dev/sda1
/dev/sda1:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x1
Array UUID : e90d6691:7ad14e07:68ee7f2a:f5bbcfbc
Name : LostCreek:0
Creation Time : Wed Mar 25 11:56:03 2020
Raid Level : raid6
Raid Devices : 6
Avail Dev Size : 5860399104 sectors (2.73 TiB 3.00 TB)
Array Size : 11720531968 KiB (10.92 TiB 12.00 TB)
Used Dev Size : 5860265984 sectors (2.73 TiB 3.00 TB)
Data Offset : 131072 sectors
Super Offset : 8 sectors
Unused Space : before=130992 sectors, after=133120 sectors
State : clean
Device UUID : 100e1983:e323daa4:a28faf75:68afde64
Internal Bitmap : 8 sectors from superblock
Update Time : Fri Aug 5 03:45:48 2022
Bad Block Log : 512 entries available at offset 24 sectors
Checksum : f6f4c925 - correct
Events : 128119
Layout : left-symmetric
Chunk Size : 512K
Device Role : Active device 3
Array State : AAAAAA ('A' == active, '.' == missing, 'R' == replacing)
并进行比较：
% mdadm --examine /dev/sdf1
/dev/sdf1:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x1
Array UUID : e90d6691:7ad14e07:68ee7f2a:f5bbcfbc
Name : LostCreek:0
Creation Time : Wed Mar 25 11:56:03 2020
Raid Level : raid6
Raid Devices : 6
Avail Dev Size : 5860400015 sectors (2.73 TiB 3.00 TB)
Array Size : 11720531968 KiB (10.92 TiB 12.00 TB)
Used Dev Size : 5860265984 sectors (2.73 TiB 3.00 TB)
Data Offset : 131072 sectors
Super Offset : 8 sectors
Unused Space : before=130992 sectors, after=134031 sectors
State : clean
Device UUID : 8a99c085:51469860:99f42094:5dea9904
Internal Bitmap : 8 sectors from superblock
Update Time : Fri Aug 5 03:45:48 2022
Bad Block Log : 512 entries available at offset 24 sectors
Checksum : 73871a85 - correct
Events : 128119
Layout: left-symmetric
Chunk Size : 512K
Device Role : Active device 2
Array State : AAAAAA ('A' == active, '.' == missing, 'R' == replacing)
其中，所有 6 台设备之间唯一不同的行是
1. /dev/sda1
11. Avail Dev Size
16. Unused Space
18. Device UUID : 100e1983:e323daa4:a28faf75:68afde64
23. Checksum : f6f4c925 - correct
29. Device Role : Active device 3
前导数字是使用本文顶部的 for 循环创建的文件的行号，通过
vimdiff mdstat.?
“更新时间”、“事件”等都匹配。设备角色行（最后一项标记为不同）全部不同，从 0 到 5。
这一切看起来应该可以工作，但经过大量谷歌搜索后，我相信我需要使用以下命令使其恢复功能。
mdadm --create /dev/md127 --level=6 --raid-devices=6 --chunk=512 --name=LostCreek:0 /dev/sda1 /dev/sdb1 /dev/sdc1 /dev/sdd1 /dev/sde1 /dev/sdf1 --assume-clean
这部分来自以下问题/答案MDADM - 灾难恢复或继续前进..和mdadm 重新添加磁盘作为备用磁盘。
我正准备尝试这个，但想看看我是否遗漏了任何东西。我也没有看到任何类似的问题，其中没有实际发生故障的驱动器，而只是通过停止软件 raid 中的写入来“让我保存”selinux。 （我的 selinux 处于“许可”状态，并认为我是安全的，但现在我处于“禁用”状态）。
希望这对其他人有用，特别是如果它“有效”。这些问题似乎很少见，我希望回答我自己的问题，但我真的不想从一个月前的备份中恢复整个突袭。 （是的，一如既往，我应该更频繁地进行备份，但幸运的是，丢失它不会是世界末日）。
干杯
麦克风
答案1
呜呼！，我的意思是呜呼！
它回来了！还有frostchutz，如果我可以在某个时候给你买杯啤酒或晚餐，我很乐意这样做！
请参阅上面我的评论，了解事情的进展情况，但是使用frostshutz的答案以及我从 mdadm --examine 中得到的内容，我执行了以下操作，并且现在又回来了！
添加 --size 并将设备按照 mdadm --examine 输出的“Role”行指定的顺序放置的命令是
mdadm --stop /dev/md127
mdadm --create /dev/md42 --assume-clean \
--level=6 --chunk=512K --metadata=1.2 --data-offset=131072s \
--size=2930132992K \
--raid-devices=6 /dev/sde1 /dev/sdd1 /dev/sdf1 /dev/sda1 /dev/sdb1 /dev/sdc1
包含错误信息的 raid 位于 md127 中，我希望 /dev/md42 是我在所有这些旋转之前拥有的 raid 设备。该 raid 设备是一个加密磁盘，然后在此基础上进行格式化。我查看了 mdadm --examine 位（使用相同的 for 循环）并与我之前的内容进行了比较，它是金色的，或者看起来是金色的。 “角色”、大小等现在已匹配。显然，没有什么“事件”，但它看起来和我预期的一样好。那么，关键时刻
cryptsetup luksOpen /dev/md42 woot
你瞧，我有一个 /dev/mapper/woot 设备。它登上去了，世界上一切都美好了。
非常非常感谢。如果没有的话，就不可能走到这一步 霜舒茨非常清楚地描述了如何做到这一点。我真是太兴奋了！我正在开始新的备份。