☰

在 GPT 磁盘上构建并迁移到软件 raid (mdadm)，现在无法组装阵列

tag-icon • tag-icon mdadm gpt
在 GPT 磁盘上构建并迁移到软件 raid (mdadm)，现在无法组装阵列

mdadm、gpt 问题、无法识别的分区。

简化的问题：如何让 mdadm 识别 GPT 分区？

我一直在尝试将我的 Ubuntu 11.10 操作系统从单个驱动器转换/复制到软件 raid 1。我过去也做过类似的事情，但在这种情况下，我添加了一个已配置为 GPT 的驱动器，并且我尝试使用它而没有完全考虑其含义。

目前，我有一个非启动 mdadm RAID 1 阵列 /dev/md127（操作系统分配了该阵列，并且一直在恢复）。我正在从实时 USB 密钥启动，目前是从 sysresccd 启动系统救援 CD。虽然 gdisk 和 parted 可以看到所有分区，但大多数操作系统实用程序都看不到，包括 mdadm。我的主要目标只是使 raid 阵列可访问，以便我可以提取数据并重新开始（不使用 GPT）。

/dev/md127

/dev/sda
 /dev/sda1 <- GPT type partition
  /dev/sda1 <- exists within the GPT part, member of md127
  /dev/sda2 <- exists within the GPT part, empty

/dev/sdb
 /dev/sdb1 <- GPT type partition
  /dev/sdb1 <- exists within the GPT part, member of md127

历史：

要点 A：原始操作系统安装在 sda（实际上是 /dev/sda6）上。我使用 Ubuntu live usb 添加 sdb。我从 fdisk 收到有关 GPT 的警告，因此我使用 gdisk 创建 raid 分区（sdb1），并使用 mdadm 创建缺少驱动器的 raid1 镜像。我遇到了很多问题（包括无法安装 grub），但最终我使用 sda 上的 grub 和 sdb 上的 /dev/md127 启动了它。因此在要点 A，我已将操作系统从 sda6 复制到 sdb 上的 md127。然后我启动到救援模式并尝试将引导加载程序安装到 sdb 上，但失败了。然后我发现了我的错误：我将 raid 安装在 sdb 上而不是 sdb1 上，本质上覆盖了 sdb1 分区。

要点 B：我现在有两份数据副本 - 一份在 md127/sdb 上，一份在 sda 上。我销毁了 sda 上的数据并在 sda 上创建了一个新的 GPT 表。然后我为 raid 阵列创建了 sda1，为暂存分区创建了 sda2。我将 sda1 添加到 raid 阵列并让它重建。md127 现在已将 /dev/sdb 和 /dev/sda1 覆盖为完全活动和同步。

要点 C：我再次重新启动 Linux 救援，仍然可以访问 RAID 阵列。然后我从阵列中删除 /dev/sdb，并为 RAID 创建 /dev/sdb1。我将 sdb1 添加到阵列并让其同步。我能够毫无问题地挂载和访问 /dev/md127。完成后，/dev/sda1 和 /dev/sdb1 都是 GPT 分区并正在主动同步。

要点 D（当前）：我再次重新启动以测试阵列是否能够启动，但 grub 加载失败。我从正在使用的拇指驱动器启动，发现无法再组装 raid 阵列。mdadm 看不到所需的分区。

--
root@freshdesk /root % uname -a
Linux freshdesk 3.0.24-std251-amd64 #2 SMP Sat Mar 17 12:08:55 UTC 2012 x86_64 AMD Athlon(tm) II X4 645 Processor AuthenticAMD GNU/Linux



===
/proc/partitions and parted look good:
root@freshdesk /root % cat /proc/partitions
major minor  #blocks  name

   7        0     301788 loop0
   8        0  976762584 sda
   8        1  732579840 sda1
   8        2  244181703 sda2
   8       16  732574584 sdb
   8       17  732573543 sdb1
   8       32    7876607 sdc
   8       33    7873349 sdc1


(parted) print all
Model: ATA ST31000528AS (scsi)
Disk /dev/sda: 1000GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt

Number  Start   End     Size   File system  Name                Flags
 1      1049kB  750GB   750GB  ext4
 2      750GB   1000GB  250GB               Linux/Windows data


Model: ATA SAMSUNG HD753LJ (scsi)
Disk /dev/sdb: 750GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt

Number  Start   End    Size   File system  Name        Flags
 1      1049kB  750GB  750GB  ext4         Linux RAID  raid


Model: SanDisk SanDisk Cruzer (scsi)
Disk /dev/sdc: 8066MB
Sector size (logical/physical): 512B/512B
Partition Table: msdos

Number  Start   End     Size    Type     File system  Flags
 1      31.7kB  8062MB  8062MB  primary  fat32        boot, lba


===
# no sda2, and I double the sdb1 is the one shown in parted
root@freshdesk /root % blkid
/dev/loop0: TYPE="squashfs"
/dev/sda1: UUID="75dd6c2d-f0a8-4302-9da4-792cc7d72355" TYPE="ext4"
/dev/sdc1: LABEL="PENDRIVE" UUID="1102-3720" TYPE="vfat"
/dev/sdb1: UUID="2dd89f15-65bb-ff88-e368-bf24bd0fce41" TYPE="linux_raid_member"

root@freshdesk /root % mdadm -E /dev/sda1
mdadm: No md superblock detected on /dev/sda1.

# this is probably a result of me attempting to force the array up, putting superblocks on the GPT partition
root@freshdesk /root % mdadm -E /dev/sdb1
/dev/sdb1:
          Magic : a92b4efc
        Version : 0.90.00
           UUID : 2dd89f15:65bbff88:e368bf24:bd0fce41
  Creation Time : Fri Mar 30 19:25:30 2012
     Raid Level : raid1
  Used Dev Size : 732568320 (698.63 GiB 750.15 GB)
     Array Size : 732568320 (698.63 GiB 750.15 GB)
   Raid Devices : 2
  Total Devices : 2
Preferred Minor : 127

    Update Time : Sat Mar 31 12:39:38 2012
          State : clean
 Active Devices : 1
Working Devices : 2
 Failed Devices : 1
  Spare Devices : 1
       Checksum : a7d038b3 - correct
         Events : 20195


      Number   Major   Minor   RaidDevice State
this     2       8       17        2      spare   /dev/sdb1

   0     0       8        1        0      active sync   /dev/sda1
   1     1       0        0        1      faulty removed
   2     2       8       17        2      spare   /dev/sdb1


===

root@freshdesk /root % mdadm -A /dev/md127 /dev/sda1 /dev/sdb1
mdadm: no recogniseable superblock on /dev/sda1
mdadm: /dev/sda1 has no superblock - assembly aborted
    root@freshdesk /root % mdadm -A /dev/md127  /dev/sdb1
mdadm: cannot open device /dev/sdb1: Device or resource busy
mdadm: /dev/sdb1 has no superblock - assembly aborted

答案1

mdadm 无法识别分区，而 Linux 内核可以识别。软件 RAID 阵列不需要知道或关心磁盘使用哪种类型的分区，因为它只使用内核为分区提供的块设备。我在几台计算机上的 GPT 磁盘上使用 mdadm 阵列，它们运行良好。

您描述的分区布局没有意义：

/dev/sda
 /dev/sda1 <- GPT type partition
  /dev/sda1 <- exists within the GPT part, member of md127
  /dev/sda2 <- exists within the GPT part, empty

/dev/sdb
 /dev/sdb1 <- GPT type partition
  /dev/sdb1 <- exists within the GPT part, member of md127

具体来说，您似乎在说sda2位于 内sda1。分区不存在于其他分区内，并且 GPT 是整个磁盘设备的特征，而不是分区。我认为您的实际意思是：

/dev/sda <- GPT disk
 /dev/sda1 <- member of md127
 /dev/sda2 <- empty

/dev/sdb <- GPT disk
 /dev/sdb1 <- member of md127

但是，您的blkid输出表明/dev/sda1当前包含一个 Ext4 文件系统，而不是 RAID 超级块 — 它是不是的成员md127。由于您说您将其用作 RAID 组件，因此不清楚该文件系统是如何到达那里的，但由于您的故事很长且充满曲折，我怀疑可能存在一些您没有意识到发生的事情。我目前的建议是：

  • 使用 以降级模式组装阵列/dev/sdb1。检查它是否包含您的数据；如果不包含，请检查是否/dev/sda1以某种方式包含带有您的数据的完整文件系统，否则我希望您有一个备份。
  • 如果您尚未备份所有数据，请备份。
  • 完全擦除/dev/sda： dd if=/dev/zero of=/dev/sda bs=1M。然后使用gdisk重新创建分区。
  • 仅使用 上的分区创建一个新的降级阵列sda。在其中创建文件系统，并将数据复制到其中。
  • 拆卸正在使用的阵列sdb1，并彻底擦除/dev/sdb： dd if=/dev/zero of=/dev/sdb bs=1M。然后使用gdisk重新创建分区。
  • 添加/dev/sdb1到新数组并让其同步。

至于安装 GRUB，这取决于您的机器是否支持 EFI（以及您是否使用它进行引导）。如果您使用 EFI，则需要在某处创建一个 EFI 系统分区；它应该大约 100MB，格式为 FAT32。然后您将安装 EFI 版本的 GRUB。我不会对此进行过多的详细介绍；EFI 引导是另一个问题的主题。

如果你是不是使用 EFI 启动，您需要在要安装 GRUB 的磁盘上创建一个“BIOS 启动”分区。（这是ef02中的分区类型代码gdisk。）该分区可以很小；1MB 就足够了。GRUB 将使用它来存储它要安装的启动代码。会已写入 MBR 磁盘上的 1 至 62 扇区。（在 MBR 磁盘上，这些扇区通常未分配，因为第一个分区通常从 63 扇区开始，但在 GPT 磁盘上，分区表位于该区域。）GRUB 应该会自动注意到您要安装它的磁盘包含 BIOS 启动分区，并将其启动代码放在那里，而不是 1-62 扇区中。

相关内容