Re: [linux-lvm] LVM2 Recovery after Filesystem Code Change

[Zdenek Kabelac <zdenek.kabelac@gmail.com>]

Dne 20.5.2013 19:09, meLon napsal(a):
>
> After noticing warnings saying "Incorrect metadata area header checksum" when
> using pv/lv commands I looked into what could be causing the issue and
> attempted to fix the issue.  I had a HDD with an ext2 /boot partition and an
> LVM containing an encrypted volume.  I ran sfdisk to change the second
> partition's filesystem code to 8e and rebooted.

I think you've made a lot a of mistakes - and probably you've not started with 
the first one you've made here.

"Incorrect metadata area header checksum" usually happens (at least what I've 
seen so far) when multiple machines are playing with LVM2 metadata - i.e.
you export disk into virtual guest - and both - guest and host have the full 
access to metadata (no locking daemon, no clvmd....)

You cannot fix lvm2 reported bug with non-lvm tools i.e. sfdisk.
The 'easy' way for recovery (if you know what you are doing, and you've 
analysed the fault) is to use  vgcfgrestore.


> After rebooting, I was shown an error when I would normally type in my
> encrypted volume's passphrase.  I cannot remember the exact error, but I was
> unable to recover.  I pulled the HDD and installed Linux onto another HDD.
>
> I put the old HDD containing data I would like to recover in another machine
> and tried to see what I could do.  pvscan and lvscan would show a pv, but
> would report the Incorrect metadata area header checksum warning.  I tried to
> mount my /boot partition, but it said something along the lines of "Unknown
> filesystem type LVM.....".  However, if I used *-t ext2*, the /boot partition
> would mount without a problem.  I ran fsck.ext4 (big mistake) on the /boot
> partition which destroyed all of the data on that partition.  The destruction
> of /boot is not important to me, but the steps I took to do it may give some
> insight on my LVM issue.

Running such tools is really bad idea if you do not know what happened.

> At this point, I believe that I accidentally told sfdisk that my /boot was an
> LVM partition which was why I was unable to boot into my os.

The partition type is not really important here for recovery.

> Now I have the HDD  set up and when running pvdisplay I see the HDD, but it
> does not show a VG name and reports it as a "new physical volume".  Because
> it's not assigned to a VG, it does not get placed in /dev/mapper, which means
> I cannot run cryptsetup to unlock the drive.
>
> Any recovery/backup information that I see being used by other people to
> rectify similar situations resided on the drive I am having problems with,
> which makes it impossible for me to use such data for recovery.

I'm not sure how your cryptosetup has looked before - but for 'PV' - you 
always could access metadata are (typically <1MB partition header).
For lvm2 recovery you have to be able to access you PV in unencrypted form,
thus the following suggestion is not handling your encrypted disk.


Metadata are stored in the plain text form - so you could just 'dd' the first 
1MB and then look for the last valid metadata you could find there.
( vgname {  seqno = highest_you_could_find .... }  )
(If the PV would be encrypted you will not be able to find readable text in 
the partition header, so you will know, you need to setup your decryption 
properly first)

If you could find there 'valid' text for reasonable metadata, you could cut 
valid piece i.e. in 'vi' and you may try to use this for:

pvcreate --restorefile mdafile --uuid  pv_uuid_in_mda   /dev/your_hdd
vgcfgrestore --file  mdafile   vgname_you_want_to_restore

However before you start to do this recovery - you should be sure, you know
what you are doing and what you are trying to recover -
so think twice, cut once....

Zdenek

PS: you could try to reach for more interactive help on  freenode  #lvm