設備中缺少 LVM 元數據
這是情況。我有一個 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有什麼方法可以解決這個問題，還是我應該忍受它？
在設備上創建 PV 時，LVM 標籤（預設情況下）位於第二個 512B 扇區中。如果設備是要安裝 grub 的整個磁碟，那麼這正是 grub 的 core.img 所在的位置。LVM 元數據（預設情況下每個磁碟有一個副本）位於標籤之後，從第五個扇區開始。（元數據的第二個可選副本可以位於磁碟的末尾。）元數據大小預設為 255 個扇區。
--labelsector您可以使用選項 to將標籤的預設位置更改為前 4 個扇區中的任何位置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 標籤和元數據將位於分區的開頭，而不是磁碟的開頭。這將為 core.img 保留 MBR 之後（以及第一個分區之前）的 62 個扇區。
我要補充一點，GPT 在這些作品中扔了一把扳手，我還沒有開始理解。
$$ Ok, the comment makes it sound easy enough. $$