[Gllug] still wondering about lvm

[Nix]

On Sun, 12 Mar 2006, nix at esperi.org.uk uttered the following:
> On Thu, 09 Mar 2006, Adrian McMenamin whispered secretively:
>> I asked this when I recounted my tail of woe/incompetence on Sunday but
>> nobody answered, so here I go again...
>> 
>> adrian at dragoneye:~$ sudo pvscan
>>   Incorrect metadata area header checksum
>>   Incorrect metadata area header checksum
>>   Incorrect metadata area header checksum
>>   Incorrect metadata area header checksum
>>   PV /dev/sda5   VG Ubuntu   lvm2 [186.07 GB / 0    free]
>>   PV /dev/hda5   VG Ubuntu   lvm2 [76.45 GB / 460.00 MB free]
>>   PV /dev/hda1               lvm2 [101.76 MB]
>>   Total: 3 [262.62 GB] / in use: 2 [262.52 GB] / in no VG: 1 [101.76 MB]
>> 
>> Firstly what does Incorrect metadata area header checksum mean and how
>> can I fix it (google gives no simple/straight answers afaics and the STN
>> is much better here :))
> 
> It means the metadata area's header checksum is incorrect. ;)))

I replicated this last night.

The way pvscan works (and many other LVM commands that do similar scans
work too) is to scan every applicable block device (generally, every
device in /dev, but you can add directories and regexp-exclude files
too) searching for those with a PV label. The precise location of this
depends upon the metadata format (there are three presently, lvm1, lvm2,
and `pool' for GFS), but it's always there. Creating this label is what
`pvcreate' does.

You get this message if you reuse a PV for something else without
vgreducing it from the VG, or if you reuse a PV for something else
without pvremoving it and the `something else' happens not to have
overwritten the label (which sometimes happens with md arrays).

The latter case is easy to fix: take whateveritis off the partition and
pvremove it. The former case is slightly harder: if the PV was empty, do
a `vgreduce --removemissing --test {your-vg-name}'; this will zap any
LVs that are on that PV, even in part, so take care!

(The vgreduce manpage has more info on how to get the surviving bits of
LVs back. If you haven't touched the removed PV, try a vgcfgrestore
(carefully!)

This is tricky stuff, but it *is* generally recoverable unless you've
actually overwritten the data.

-- 
`Come now, you should know that whenever you plan the duration of your
 unplanned downtime, you should add in padding for random management
 freakouts.'
-- 
Gllug mailing list  -  Gllug at gllug.org.uk
http://lists.gllug.org.uk/mailman/listinfo/gllug