![无法重新挂载本地文件系统以进行读写 (RAID1)](https://linux22.com/image/27778/%E6%97%A0%E6%B3%95%E9%87%8D%E6%96%B0%E6%8C%82%E8%BD%BD%E6%9C%AC%E5%9C%B0%E6%96%87%E4%BB%B6%E7%B3%BB%E7%BB%9F%E4%BB%A5%E8%BF%9B%E8%A1%8C%E8%AF%BB%E5%86%99%20(RAID1).png)
我在 Asus P9X79 主板上组装了一台新机器,使用其 RAID 控制器创建了两个 500Gb 驱动器的 RAID1 阵列。
当从外部驱动器启动 Arch 时,我能够正常使用与/dev/md126
阵列相对应的驱动器。通过这种方式,我在其上创建了分区和文件系统,然后在驱动器上进行了 chroot 并安装了 Arch Linux。
但是,我无法从 RAID 成功启动:/
,/boot
并且/home
无法以读写模式重新安装(mount
返回32
),并且我最终进入紧急控制台。尝试从那里重新安装也失败,并表示驱动器已被写保护。
我认为一些必要的内核模块在启动时没有加载并使用mkinitcpio.conf
.我有mdadm_udev
一个钩子(之后udev
,之前filesystems
)。据我了解,这应该足够了,但我也尝试添加raid1
, raid456
,ext2
和ext4
到MODULES
数组中,这没有改变任何东西。
mdadm_udev
由于挂钩(设备在那里),RAID1 本身在初始环境中被识别。raid1
我认为,也是由这个钩子自动加载的。
我仍然能够从外部驱动器启动并安装 RAID1 设备;所以我lsmod
在它上做了并与lsmod
“本地”系统进行了比较。我觉得没有什么可疑的:
$ diff <(sort lsmod.old | cut -f1 -d ' ') <(sort lsmod.new | cut -f1 -d ' ')
7a8,12
> async_memcpy
> async_pq
> async_raid6_recov
> async_tx
> async_xor
13a19,20
> drm
> drm_kms_helper
24a32
> i2c_algo_bit
43c51
< nvidia
---
> nouveau
48a57,58
> raid456
> raid6_pq
64a75,76
> ttm
> uas
71a84
> xor
old
是有效的。正如您所看到的,唯一以 开头的行<
是< nvidia
。因此,所有必要的模块都已加载(其中的一些附加模块new
是我尝试加载的依赖项raid456
)。
我在这里缺少什么?两个系统之间可能存在哪些差异?内核版本相同:3.6.8。 (顺便说一句,我第一次尝试使用的安装介质是 3.6.6,并且不适用于该阵列;所有操作最终都无休止地挂起)。
答案1
(列弗找到了解决方案,我正在做解释来解释它为什么有效。)
使用其 RAID 控制器创建 RAID1 阵列
这是一个坏兆头:你正在使用假袭击— RAID 实现,主要由 Windows 驱动程序实现,并需要固件的少量帮助。您既具有硬件 RAID 的所有缺点(依赖于固件),又具有软件 RAID 的所有缺点(无性能优势)。
RAID 元数据由固件处理。 (元数据是需要存储在某个地方的额外数据,它不属于存储在 RAID 设备上的文件系统或分区的一部分:例如每个数据块应该排序的位置、处理重新同步的额外数据等等。)实现(至少对于这个驱动程序),这不是由内核单独处理的,mdmon
公用事业也是需要的。
当你的系统启动时,首先只有内核和一个初始 RAM 驱动器(一个初始化文件系统)。此初始 RAM 驱动器必须包含挂载根文件系统所需的所有可加载模块和程序。因为它必须适合 RAM,所以大多数发行版都会根据系统所需的驱动程序按需生成 initramfs。这通常在每次内核升级时完成。
看来 Arch Linux 的 initramfs 生成脚本没有检测到您mdmon
在启动时需要该程序,因此生成了一个无法工作的 initramfs。强制mdmon
出现在 initramfs 中使 initramfs 工作。
答案2
我按照以下建议让它工作这里。也就是说,我添加到/sbin/mdmon
了数组BINARIES
中mkinitcpio.conf
。
对我来说,这看起来有点像黑魔法,所以无论如何,欢迎提供带有解释的详细答案。