☰

“/etc/fstab”中的“PARTUUID”和（硬件）RAID0 不能很好地协同工作，是吗？

tag-icon • tag-icon arch-linux boot fstab gpt raid0
“/etc/fstab”中的“PARTUUID”和（硬件）RAID0 不能很好地协同工作，是吗？

新的 Arch Linux 安装在（硬件）上RAID064位以下UEFI系统与GPT分区。必须添加

MODULES="ext4 dm_mod raid0"

HOOKS="base udev autodetect modconf block mdadm_udev filesystems keyboard fsck"

以便/etc/mkinitcpio.conf在启动时正确识别 RAID0 上的分区。否则，

ERROR: device 'UUID=<uuid>' not found. Skipping fsck.
ERROR: Unable to find root device 'UUID=<uuid>'.
...

将被发行。

然而有一个特殊之处，我不知道如何解释。一方面，当/etc/fstab包含/dev/*或UUID=*源时，Arch Linux 会正常启动。另一方面，当它包含PARTUUID=*源时，启动时会发生一堆相应的Dependency failed错误（关于从 挂载这些源/etc/fstab）并且挂起。

你能解释一下在这种情况下PARTUUID=*有什么问题吗？/etc/fstab这和RAID0有关系吗？

$ cat /proc/mdstat
Personalities : [raid0] 
md126 : active raid0 sda[1] sdb[0]
      976768000 blocks super external:/md127/0 128k chunks

md127 : inactive sda[1](S) sdb[0](S)
      4904 blocks super external:imsm

unused devices: <none>

$ dmsetup table
No devices found

$ lsblk
NAME          MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINT
sda             8:0    0 465.8G  0 disk  
└─md126         9:126  0 931.5G  0 raid0 
  ├─md126p1   259:0    0     1G  0 md    /boot/efi
  ├─md126p2   259:1    0     1G  0 md    
  ├─md126p3   259:2    0     1G  0 md    
  ├─md126p4   259:3    0   256G  0 md    
  ├─md126p102 259:4    0    16G  0 md    [SWAP]
  ├─md126p103 259:5    0    16G  0 md    /
  ├─md126p104 259:6    0    16G  0 md    /var
  └─md126p105 259:7    0   256G  0 md    /home
sdb             8:16   0 465.8G  0 disk  
└─md126         9:126  0 931.5G  0 raid0 
  ├─md126p1   259:0    0     1G  0 md    /boot/efi
  ├─md126p2   259:1    0     1G  0 md    
  ├─md126p3   259:2    0     1G  0 md    
  ├─md126p4   259:3    0   256G  0 md    
  ├─md126p102 259:4    0    16G  0 md    [SWAP]
  ├─md126p103 259:5    0    16G  0 md    /
  ├─md126p104 259:6    0    16G  0 md    /var
  └─md126p105 259:7    0   256G  0 md    /home
sr0            11:0    1  1024M  0 rom

$ blkid
/dev/sda: TYPE="isw_raid_member"
/dev/sdb: TYPE="isw_raid_member"
/dev/md126p1: LABEL="EFI" UUID="722E-E4AB" TYPE="vfat" PARTLABEL="EFI system partition" PARTUUID="a8e94657-e6ea-4712-be06-ac9ffe6e2258"
/dev/md126p3: LABEL="Windows PE 5.0 (x64)" UUID="181C2F991C2F7144" TYPE="ntfs" PARTLABEL="Basic data partition" PARTUUID="15848c79-1456-418b-a243-830d0db894ce"
/dev/md126p4: LABEL="Windows 8.1 (x64)" UUID="AAB83149B83114F3" TYPE="ntfs" PARTLABEL="Basic data partition" PARTUUID="7d3a06f5-4c67-4299-80b0-029501e14f18"
/dev/md126p102: UUID="6a2d4998-3ac8-4135-9d72-47960b201d5d" TYPE="swap" PARTLABEL="Swap" PARTUUID="d418edd6-44eb-4058-921f-c68aa191c5ac"
/dev/md126p103: UUID="2c241730-a076-48d9-8d1f-6e10573a994f" TYPE="ext4" PARTLABEL="Arch Linux" PARTUUID="37200e1e-dea4-435a-a873-427e3ee8c494"
/dev/md126p104: UUID="8d4eff47-3a2b-46b4-9263-7bbf00d8d0db" TYPE="ext4" PARTLABEL="Variable" PARTUUID="cd15b1f0-e948-4975-9218-591efa5b9b95"
/dev/md126p105: UUID="e0b15e56-3846-4e75-96f8-4f75058b4a6b" TYPE="ext4" PARTLABEL="Home" PARTUUID="54e85323-522c-415a-b7bd-2eb83b6b4ee6"
/dev/md126: PTUUID="e4e1b9b8-c26f-416d-82d9-e9350d0b5ac2" PTTYPE="gpt"
/dev/md126p2: PARTLABEL="Microsoft reserved partition" PARTUUID="6e9264fd-da04-4966-b8e0-8f3124f47050"

答案1

既然现在很清楚您正在运行软件 raid（“假 raid”，其中固件/BIOS 也有一个软件 RAID 实现，可以更轻松地启动 Windows — 在本例中为英特尔矩阵存储），您可能会看到Arch 的 initramfs w/r/t 分区 md 数组中的一些错误。

真正的硬件raid对于操作系统来说几乎是完全透明的；例如，您只能看到一个设备（RAID 阵列），而不是每个磁盘一个设备。对于操作系统来说，硬件 RAID 阵列看起来就像一个普通磁盘，至少在安装了 RAID 驱动程序后（如果没有它，操作系统根本看不到它）。

很长一段时间，您根本无法对 md 数组进行分区（在它们之上使用 LVM 或创建多个数组很常见，现在仍然如此）；后来，您可以设置一个可分区的分区，但这不是默认的；现在它们都可以被分区。但可能仍然有一些关于它们不可分区的假设，并且正在物理磁盘上而不是 RAID 阵列上寻找该partuuid。

就我个人而言，我并不担心这个问题，只需使用 UUID 即可。另外，一般来说，对于仅支持 Linux 的机器，通常最好根本不使用“fake raid”，而直接使用 Linux mdraid 及其本机格式。有了 RAID-0，我相信您很快就有机会重建盒子......

相关内容