这是情况。 我有一个MD设备/ dev / md0，它function完全，但似乎没有LVM元数据。 就我所知道的所有事情而言，它不是卷组的一部分，也不会显示为物理卷。 另一方面，它是一个启动分区，它填充这个function没有问题。 我也可以使其中的一个设备失效，重新添加它们，并重buildarrays没有问题。 为什么那么我在乎呢？ 那么，每次我更新grub，我都会遇到一堆“错误：未知的LVM元数据头”消息。 这不是一个问题，但它正在窃听我。
这里有一些细节：
# uname -a Linux redacted 3.9-1-amd64 #1 SMP Debian 3.9.6-1 x86_64 GNU/Linux # pvck /dev/md0 Could not find LVM label on /dev/md0 # mdadm --detail --scan ARRAY /dev/md/0 metadata=1.2 name=redacted:0 UUID=Stuff ARRAY /dev/md/1 metadata=1.2 name=redacted:1 UUID=Stuff ARRAY /dev/md/2 metadata=1.2 name=redacted:2 UUID=Stuff # lvscan -v Finding all logical volumes ACTIVE '/dev/vg01/home' [232.83 GiB] inherit ACTIVE '/dev/vg01/storage' [3.87 TiB] inherit ACTIVE '/dev/vg00/root' [59.53 GiB] inherit # pvdisplay -v Scanning for physical volume names --- Physical volume --- PV Name /dev/md2 VG Name vg01 PV Size 4.09 TiB / not usable 512.00 KiB Allocatable yes (but full) PE Size 4.00 MiB Total PE 1073097 Free PE 0 Allocated PE 1073097 PV UUID Stuff --- Physical volume --- PV Name /dev/md1 VG Name vg00 PV Size 59.53 GiB / not usable 4.93 MiB Allocatable yes (but full) PE Size 4.00 MiB Total PE 15239 Free PE 0 Allocated PE 15239 PV UUID Stuff # cat /proc/mdstat Personalities : [raid1] [raid6] [raid5] [raid4] md2 : active raid5 sdc1[0] sdf1[3] sde1[2] sdd1[1] 4395406848 blocks super 1.2 level 5, 512k chunk, algorithm 2 [4/4] [UUUU] md1 : active raid1 sda2[0] sdb2[1] 62423992 blocks super 1.2 [2/2] [UU] md0 : active raid1 sda1[2] sdb1[1] 96244 blocks super 1.2 [2/2] [UU] unused devices: <none> # mount sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime) proc on /proc type proc (rw,nosuid,nodev,noexec,relatime) udev on /dev type devtmpfs (rw,relatime,size=10240k,nr_inodes=1011774,mode=755) devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000) tmpfs on /run type tmpfs (rw,nosuid,noexec,relatime,size=810888k,mode=755) /dev/mapper/vg00-root on / type ext4 (rw,relatime,errors=remount-ro,data=ordered) tmpfs on /run/lock type tmpfs (rw,nosuid,nodev,noexec,relatime,size=5120k) tmpfs on /run/shm type tmpfs (rw,nosuid,nodev,noexec,relatime,size=1621760k) fusectl on /sys/fs/fuse/connections type fusectl (rw,relatime) /dev/md0 on /boot type ext4 (rw,relatime,data=ordered) /dev/mapper/vg01-home on /home type ext4 (rw,relatime,stripe=384,data=ordered) /dev/mapper/vg01-storage on /storage type ext4 (rw,relatime,stripe=384,data=ordered) rpc_pipefs on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw,relatime) # file -k -s /dev/md0 /dev/sda1 /dev/sdb1 /dev/md0: sticky Linux rev 1.0 ext4 filesystem data, UUID=redacted (needs journal recovery) (extents) (huge files) /dev/sda1: sticky Linux Software RAID version 1.2 (1) UUID=redacted name=redacted:0 level=1 disks=2 /dev/sdb1: sticky Linux Software RAID version 1.2 (1) UUID=redacted name=redacted:0 level=1 disks=2 任何方法来解决这个问题，或者我应该只是住在一起吗？
在设备上创buildPV时，LVM标签位于第二个512B扇区（默认情况下）。 如果设备是要安装grub的整个磁盘，那么这正是grub的core.img所在的位置。 LVM元数据（默认情况下每个磁盘有一个副本）位于标签之后，从第五个扇区开始。 （元数据的可选第二副本可以位于磁盘末尾。）该元数据大小默认为255个扇区。 您可以将标签的默认位置更改为前4个扇区中的任意位置，使用--labelsector选项来创buildpvcreate ，但这看起来不够，因为grub的core.img似乎需要MBR之后的62个扇区。 （MBR占用第一个扇区并包含grub的boot.img）
可以使用MBR中的一个引导加载程序链接加载grub，以加载位于磁盘上其他位置的boot.img / core.img。 通常“其他地方”意味着在卷引导logging中，第一个分区之前和MBR +其他干扰数据之后的空间。 问题在于，PV的数据部分通常在元数据部分之后立即开始。 有一个--dataalignmentoffset选项可以在这里打开一些空间，但是这个方法可能是读者的一个练习。
参见（grub2）： http ： //en.m.wikipedia.org/wiki/GNU_GRUB
请参阅（lvm2）： http ： //www.centos.org/docs/5/html/Cluster_Logical_Volume_Manager/physical_volumes.html
我会build议解决这个问题的方法，而不是将整个设备作为PV使用，就是在磁盘上创build一个分区。 用它作为LVM的PV。 然后，PV / LVM标签和元数据将位于分区的开始处，而不是在磁盘的开始处。 这将使MBR之后的62个扇区（以及第一个分区之前）可用于core.img。
我会补充一点，GPT会把一个扳手放到这些作品中，我不明白。 [好吧，评论使听起来很容易。]