![设备缺少 LVM 元数据](https://linux22.com/image/614676/%E8%AE%BE%E5%A4%87%E7%BC%BA%E5%B0%91%20LVM%20%E5%85%83%E6%95%B0%E6%8D%AE.png)
情况是这样的。我有一个 MD 设备 /dev/md0,它功能齐全,但似乎没有 LVM 元数据。就我所知,它不是卷组的一部分,也不会显示为物理卷。另一方面,它是一个启动分区,它可以毫无问题地完成此功能。我还可以让其中一个设备发生故障,然后重新添加它们,它会毫无问题地重建阵列。那我为什么要关心呢?嗯,每次我更新 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
有什么方法可以解决这个问题还是我只能忍受它?
答案1
在设备上创建 PV 时,LVM 标签(默认情况下)位于第二个 512B 扇区中。如果设备是要安装 grub 的整个磁盘,那么这正是 grub 的 core.img 所在的位置。LVM 元数据(默认情况下每个磁盘有一个副本)位于标签之后,从第五个扇区开始。(可选的第二个元数据副本可以位于磁盘末尾。)该元数据大小默认为 255 个扇区。您可以使用选项将标签的默认位置更改为前 4 个扇区中的任何位置,--labelsector
但这pvcreate
似乎不够,因为 grub 的 core.img 似乎需要 MBR 之后的 62 个扇区。(MBR 占用第一个扇区并包含 grub 的 boot.img。)
可以链式加载 grub,使用 MBR 中的一个引导加载程序来加载位于磁盘上其他位置的 boot.img/core.img。通常“其他位置”是指卷引导记录中的第一个分区之前和 MBR 之后的空间 + 其他干扰数据。问题是 PV 的数据部分通常紧接着元数据部分开始。有一种--dataalignmentoffset
选择pvcreate
可以在这里腾出一些空间,但这种方法对读者来说可能是一种练习。
参见(grub2):http://en.m.wikipedia.org/wiki/GNU_GRUB
参见(lvm2):http://www.centos.org/docs/5/html/Cluster_Logical_Volume_Manager/physical_volumes.html
我建议解决这个问题的方法是,不要将整个设备用作 PV,而是在磁盘上创建一个分区。将其用作 LVM 的 PV。然后 PV/LVM 标签和元数据将位于分区的开头,而不是磁盘的开头。这样 MBR 之后(第一个分区之前)的 62 个扇区将可供 core.img 使用。
我要补充的是,GPT 给这些工作带来了麻烦,这一点我不太明白。[好吧,评论听起来很简单。]