[linux-lvm] LVM2 Recovery after Filesystem Code Change

[linux-lvm] LVM2 Recovery after Filesystem Code Change

[meLon]

[-- Attachment #1: Type: text/plain, Size: 2645 bytes --]

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.

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.

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.


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 am hoping there is a way to assign this PV to a VG without destroying any
data on the disk so that I can decrypt it and export the data from the
drive.

I am currently dd'ing the drive to another drive so that any suggestions I
get from this mailing list can be executed without taking me further from
retrieving my data.

I appreciate you taking the time to read this email and thank you for any
input or suggestions you may have.


  "/dev/sda1" is a new physical volume of "1.36 TiB"
  --- NEW Physical volume ---
  PV Name               /dev/sda1
  VG Name
  PV Size               1.36 TiB
  Allocatable           NO
  PE Size               0
  Total PE              0
  Free PE               0
  Allocated PE          0
  PV UUID               ajtoix-aTPi-XXXX-XXXX-XXXX-XXXX-XXXXXX




-- 
- meLon

[-- Attachment #2: Type: text/html, Size: 3345 bytes --]

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

[meLon]

[-- Attachment #1: Type: text/plain, Size: 3716 bytes --]

I have been asked to include disktype information for the drive:

$ sudo disktype /dev/sda

--- /dev/sda
Block device, size 1.365 TiB (1500301910016 bytes)
DOS/MBR partition map
Partition 1: 3.725 GiB (3999268864 bytes, 7811072 sectors from 2048,
bootable)
  Type 0x83 (Linux)
  Ext2 file system
    UUID 728591A9-DDBF-XXXX-XXXX-XXXXXXXXXXXX (DCE, v4)
    Volume size 3.725 GiB (3999268864 bytes, 976384 blocks of 4 KiB)
  Linux LVM2 volume, version 001
    LABELONE label at sector 1
    PV UUID ajtoix-aTPi-6RoJ-XXXX-XXXX-XXXX-XXXXXX
    Volume size 1.365 TiB (1500300443648 bytes)
Partition 2: 1.361 TiB (1496300127232 bytes, 2922461186 sectors from
7815166)
  Type 0x8E (Linux LVM)
  Linux LVM2 volume, version 001
    LABELONE label at sector 3
    LABELONE data inconsistent, aborting analysis


Praying that this threads with my original e-mail.

Thanks again.



On Mon, May 20, 2013 at 12:09 PM, meLon <earthmelon@gmail.com> wrote:

>
> 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.
>
> 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.
>
> 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.
>
>
> 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 am hoping there is a way to assign this PV to a VG without destroying
> any data on the disk so that I can decrypt it and export the data from the
> drive.
>
> I am currently dd'ing the drive to another drive so that any suggestions I
> get from this mailing list can be executed without taking me further from
> retrieving my data.
>
> I appreciate you taking the time to read this email and thank you for any
> input or suggestions you may have.
>
>
>   "/dev/sda1" is a new physical volume of "1.36 TiB"
>   --- NEW Physical volume ---
>   PV Name               /dev/sda1
>   VG Name
>   PV Size               1.36 TiB
>   Allocatable           NO
>   PE Size               0
>   Total PE              0
>   Free PE               0
>   Allocated PE          0
>   PV UUID               ajtoix-aTPi-XXXX-XXXX-XXXX-XXXX-XXXXXX
>
>
>
>
> --
> - meLon
>



-- 
- meLon

[-- Attachment #2: Type: text/html, Size: 4906 bytes --]

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

[Zdenek Kabelac]

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