☰

周日 17 日

tag-icon • tag-icon linux boot raid1 systemd udev
周日 17 日

首先，我想说的是，我发现并读过这。

我正在运行带有标准 3.16 内核的 D​​ebian Jessie。我手动定义了一个 RAID1 阵列。但它不会在启动时自动组装。因此，在尝试安装 /etc/fstab 中描述的 FS 后，systemd 会退回到某个降级的 shell。如果 fstab 中的该行被注释掉，则启动过程将结束，但 RAID 阵列不可用。手动组装它不会触发任何错误。然后安装 FS 就很简单了。

手动组装时，数组如下所示：

root@tinas:~# cat /proc/mdstat 
Personalities : [raid1] 
md0 : active (auto-read-only) raid1 sdc1[0] sdd1[1]
      1953382464 blocks super 1.2 [2/2] [UU]
      bitmap: 0/15 pages [0KB], 65536KB chunk

unused devices: <none>

以下是 blkid 命令的摘录：

/dev/sdd1: UUID="c8c2cb23-fbd2-4aae-3e78-d9262f9e425b" UUID_SUB="8647a005-6569-c76f-93ee-6d4fedd700c3" LABEL="tinas:0" TYPE="linux_raid_member" PARTUUID="81b1bbfe-fad7-4fd2-8b73-554f13fbb26b"
/dev/sdc1: UUID="c8c2cb23-fbd2-4aae-3e78-d9262f9e425b" UUID_SUB="ee9c2905-0ce7-2910-2fed-316ba20ec3a9" LABEL="tinas:0" TYPE="linux_raid_member" PARTUUID="11d681e5-9021-42c0-a858-f645c8c52708"
/dev/md0: UUID="b8a72591-040e-4ca1-a663-731a5dcbebc2" UUID_SUB="a2d4edfb-876a-49c5-ae76-da5eac5bb1bd" TYPE="btrfs"

来自 fdisk 的信息：

root@tinas:~# fdisk -l /dev/sdc

Disque /dev/sdc : 1,8 TiB, 2000398934016 octets, 3907029168 secteurs
Unités : secteur de 1 × 512 = 512 octets
Taille de secteur (logique / physique) : 512 octets / 4096 octets
taille d'E/S (minimale / optimale) : 4096 octets / 4096 octets
Type d'étiquette de disque : gpt
Identifiant de disque : C475BEB1-5452-4E87-9638-2E5AA29A3A73

Device     Start        End    Sectors  Size Type
/dev/sdc1   2048 3907029134 3907027087  1,8T Linux RAID

在这里，我不确定类型值是否是正确的“Linux RAID”，因为我读到预期的是 0xFD，但是该值似乎无法通过带有 GPT 分区表的 fdisk 获得。

感谢您的帮助

编辑 ：

从journalctl-xb我能找到一个痕迹：

Apr 14 15:14:46 tinas mdadm-raid[211]: Generating udev events for MD arrays...done.
Apr 14 15:35:03 tinas kernel: [ 1242.505742] md: md0 stopped.
Apr 14 15:35:03 tinas kernel: [ 1242.513200] md: bind<sdd1>
Apr 14 15:35:03 tinas kernel: [ 1242.513545] md: bind<sdc1>
Apr 14 15:35:04 tinas kernel: [ 1242.572177] md: raid1 personality registered for level 1
Apr 14 15:35:04 tinas kernel: [ 1242.573369] md/raid1:md0: active with 2 out of 2 mirrors
Apr 14 15:35:04 tinas kernel: [ 1242.573708] created bitmap (15 pages) for device md0
Apr 14 15:35:04 tinas kernel: [ 1242.574869] md0: bitmap initialized from disk: read 1 pages, set 0 of 29807 bits
Apr 14 15:35:04 tinas kernel: [ 1242.603079] md0: detected capacity change from 0 to 2000263643136
Apr 14 15:35:04 tinas kernel: [ 1242.607065]  md0: unknown partition table
Apr 14 15:35:04 tinas kernel: [ 1242.665646] BTRFS: device fsid b8a72591-040e-4ca1-a663-731a5dcbebc2 devid 1 transid 8 /dev/md0

/proc/mdstat 我刚刚意识到启动后 raid1 模块没有加载！

root@tinas:~# cat /proc/mdstat 
Personalities : 
unused devices: <none>
root@tinas:~#

因此，我将raid1模块添加到/etc/模块，发布了update-initramfs -u。

以下是相应的日志：

avril 15 12:23:21 tinas mdadm-raid[204]: Generating udev events for MD arrays...done.
avril 15 12:23:22 tinas systemd-modules-load[186]: Inserted module 'raid1'
avril 15 12:23:22 tinas kernel: md: raid1 personality registered for level 1

但阵列仍未组装：

root@tinas:~# cat /proc/mdstat 
Personalities : [raid1] 
unused devices: <none>

这是因为 raid1 模块似乎是在 udev 事件生成后加载的吗？

有趣的链接，但太笼统

我试过了dpkg-reconfigure mdadm：没什么新的……

如果有人知道如何从 udev 获取一些跟踪信息，那就太好了。我取消了注释udev_log = info，/etc/udev/udev.conf但没有看到任何新内容……

搜索 fr raid 加载的模块

root@tinas:~# grep -E 'md_mod|raid1' /proc/modules
raid1 34596 0 - Live 0xffffffffa01fa000
md_mod 107672 1 raid1, Live 0xffffffffa0097000

raid1 已加载，因为我已将其添加到/etc/modules，否则，之前它已加载。

uname -r

root@tinas:~# uname -r 
3.16.0-4-amd64

/etc/mdadm/mdadm.conf

root@tinas:~# cat /etc/mdadm/mdadm.conf
# mdadm.conf
#
# Please refer to mdadm.conf(5) for information about this file.
#

# by default (built-in), scan all partitions (/proc/partitions) and all
# containers for MD superblocks. alternatively, specify devices to scan, using
# wildcards if desired.
#DEVICE partitions containers

# auto-create devices with Debian standard permissions
CREATE owner=root group=disk mode=0660 auto=yes

# automatically tag new arrays as belonging to the local system
HOMEHOST <system>

# instruct the monitoring daemon where to send mail alerts
MAILADDR root

# definitions of existing MD arrays
ARRAY /dev/md/0  metadata=1.2 UUID=a930b085:1e1a615b:93e209e6:08314607 name=tinas:0

# This configuration was auto-generated on Fri, 15 Apr 2016 11:10:41 +0200 by mkconf

我刚刚注意到一些奇怪的事情：/etc/mdadm/madm.conf 的最后一行是由命令自动生成的mdadm -Es，并显示一个名为/dev/md/0当我手动组装阵列时，我得到了/dev/md0我在创建数组时使用了它mdadm --create...

此外，我还从详细信息中获得了这些信息update-initramsfs：

Adding module /lib/modules/3.16.0-4-amd64/kernel/drivers/md/raid10.ko
I: mdadm: using configuration file: /etc/mdadm/mdadm.conf
I: mdadm: will start all available MD arrays from the initial ramdisk.
I: mdadm: use `dpkg-reconfigure --priority=low mdadm` to change this.

因此我尝试了，但还是失败了：重启后没有阵列。
在 /etc/mdadm/madm.conf 中，我将 ARRAY 设备名称从 /dev/md/0 更改为 ARRAY /dev/md0
我还注意到，在 initramfs busybox 中，发出 mdadm --assemble --scan 后，ARRAY 被创建为 /dev/md0 并被标记为活动（自动只读）

周日 17 日

我刚刚意识到初始化内存文件系统东西。我知道内核正在使用一些 ram-disk，但不知道更多。我现在的理解是，这个 initramfs 应该包含所需的所有数据集合在用户空间启动时，RAID 阵列会更新。因此，更新此静态文件 /boot/initrd.img 非常重要。版本来反映所有重要的变化。

所以我怀疑我的 /boot/initrd.img-3.16.0-4-amd64 文件很乱，并尝试创建一个新的文件，发出以下命令：
# update-initramfs -t -c -v -k 3.16.0-4-amd64
请注意，那里只有一个内核，因此只有一个相应的 initramfs。

但重新启动后，我再次面临 initramfs shell，因为内核无法挂载 /etc/fstab 中使用的 /dev/md0 FS。

周三 20 日

我已经在 busybox 中检查过服务器的状态：

  • raid1模块已加载
  • dmesg 中没有什么有趣的东西
  • /run/mdadm/map 存在但是为空
  • journalctl -xb 显示：
    • systemd 报告尝试在尚未组装的阵列上挂载 FS 时超时
    • 当 systemd 尝试 fsck 该 FS 时，它会报告依赖失败

以下是我的手动干预：

mdadm --assemble --scan

/proc/mdstat声称设备 /dev/md0 是积极的和自动只读.因此我发出：

mdadm --readwrite /dev/md0

退出 busybox 之前。

答案1

您可以使用 btrfs 本身镜像驱动器，而不是在软件 raid 之上创建该 fs： mkfs.btrfs -d raid1 /dev/sdc /dev/sdd

否则尝试：

    umount /dev/md0 if mounted
    mdadm --stop /dev/md0
    mdadm --assemble --scan
    mv /etc/mdadm/mdadm.conf /etc/mdadm/mdadm.conf.bak
    /usr/share/mdadm/mkconf > /etc/mdadm/mdadm.conf

如果cat /proc/mdstat现在显示正确的输出，则创建文件系统并挂载它，用于blkid获取 /dev/md0 的 UUID 并相应地编辑 /etc/fstab。

如果您仍然遇到问题，您可以在继续上述说明之前尝试此操作：

    mdadm --zero-superblock /dev/sdc /dev/sdd
    mdadm --create /dev/md0 --level=1 --raid-devices=2 /dev/sdc1 /dev/sdd1

我在运行 Debian Jessie 的系统上测试了这一点，内核为 3.16.0-4-amd64，我将 gpt 分区表写入了我镜像在一起的两个块设备。阵列在启动时正确组装并按指定方式挂载。

答案2

我也遇到了同样的问题。就我而言，我的 中有两个相同驱动器的阵列定义/etc/mdadm/mdadm.conf。

这导致系统在启动时无法正确组装驱动器。

当然，你应该确保所有需要的模块都在其中/etc/initramfs-tools/modules，并且不要忘记做一个update-initramfs -u -k all

答案3

27日星期三

好吧，我本来想找到一个解决方案，但服务器已经停机 10 天了，我决定升级它，删除了所有内容犯罪证据。首先尝试从 jessie 迁移到 testing。失败了。所以我最终全新安装了 Debian Testing。
不知道问题出在哪里，但几乎可以肯定是在一些更新之后出现的。几个论坛帖子让我认为它与内核 3.16.0-4-amd64 有关，但这只是猜测。

我不知道如何将问题标记为已关闭...

答案4

我刚刚遇到了类似的问题，尽管我的分区类型是 MBR（又名“DOS”）而不是 GPT。所以我不确定这与您自己的问题有多密切相关。我想在这里发布它作为答案，因为我在尝试解决自己的问题时仔细阅读了您的问题。

我的症状非常相似，/boot 位于 mdadm RAID1 上，/ 位于另一个 mdadm RAID1 上的 LVM 上，内核启动正常，但无法挂载根文件系统，因为找不到包含它的卷组。结果发现，这是因为两个 RAID1 设备实际上都没有运行，尽管加载了正确的内核模块。

就我的情况而言，问题在于我将 RAID1 设备底层设备的分区类型设置为 FD（“Linux RAID 自动检测”）。将类型更改为 DA（“非 FS 数据”）即可解决问题。

我的想法来自https://raid.wiki.kernel.org/index.php/Partition_Types

出现这种情况的原因是，我之前在 Debian 安装过程中手动进行了分区，并选择了该分区类型（当我第一次开始使用 Linux RAID 时，在初始 ramdisk 还不存在的时候，这是正确的选择）。

相关内容