[linux-lvm] Partition table gone? Any way to restore?

[linux-lvm] Partition table gone? Any way to restore?

[oliver]

Hi,

I just moved my HDD's from the onboard IDE controller to a PCI 
controller, the HighPoint RocketRaid454. Since one of the harddisk once, 
a long time ago, was hooked up to an identical raid controller and had a 
raid created on it, the rocketraid for some reason found it. Even though 
it shouldn't have been there anymore to my knowlegde.

The raid controller complained about a corrupt volume and destroyed it. 
It was done within a blink of an eye. (So i don't think everything is wiped.

However LVM can't find my VG anymore. fdisk -l /dev/hde shows me that 
there simply isn't anything on it. Where as fdisk -l /dev/hdg tells me 
"Disk /dev/hdg doesn't contain a valid partition table" as I would have 
expected.

First thing came to mind was to check via vgcfgrestore if it could do 
anything. However I get this error:
root@enterprise:/etc/lvmconf# vgcfgrestore -l -n vg00
vgcfgrestore -- INFO: using backup file "/etc/lvmconf/vg00.conf"
vgcfgrestore -- ERROR: different structure size stored in 
"/etc/lvmconf/vg00.conf" than expected in file vg_cfgrestore.c [line 120]
vgcfgrestore -- ERROR "vg_cfgrestore(): read" restoring volume group "vg00"

I don't think I have ever changed the version installed so don't see 
where this error is coming from. (The *.conf files apprear to be from 
late last night, so are quite 'new')

I don't want to recreate the volume on /dev/hde because i don't want to 
loose the information on there. Since as mentioned the operation was 
over quite swiftly I doubt the entire disk is gone, only the partition 
table itself, or whatever LVM creates.

Thus my question, what can I do to restore my LVM!

Thanks a lot in advance,

oliver

Re: [linux-lvm] Partition table gone? Any way to restore?

[Jan-Benedict Glaw]

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

On Wed, 2005-03-02 18:45:44 +0100, oliver <oliver@are-b.org>
wrote in message <4225FBC8.9020904@are-b.org>:
> The raid controller complained about a corrupt volume and destroyed it. 
> It was done within a blink of an eye. (So i don't think everything is wiped.
> 
> However LVM can't find my VG anymore. fdisk -l /dev/hde shows me that 
> there simply isn't anything on it. Where as fdisk -l /dev/hdg tells me 
> "Disk /dev/hdg doesn't contain a valid partition table" as I would have 
> expected.

gpart could possibly help by guessing a partition table. This helped me
several times getting some friend's broken Windoze machines to work
again. (@gpart author: if we ever meet IRL, I owe you a beer!)

MfG, JBG

-- 
Jan-Benedict Glaw       jbglaw@lug-owl.de    . +49-172-7608481             _ O _
"Eine Freie Meinung in  einem Freien Kopf    | Gegen Zensur | Gegen Krieg  _ _ O
 fuer einen Freien Staat voll Freier Bürger" | im Internet! |   im Irak!   O O O
ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [linux-lvm] Partition table gone? Any way to restore?

[oliver]

When i do a less -f /dev/hde I can see a lot of data.

E.g. I see a string looking a lot like ReiserFS and scrolling down 
further I see /dev/vg00/<nameofparts created> so I'm sure a LOT is still 
there. I'll give it a shot. Any other ideas are still welcome!

Jan-Benedict Glaw wrote:

>On Wed, 2005-03-02 18:45:44 +0100, oliver <oliver@are-b.org>
>wrote in message <4225FBC8.9020904@are-b.org>:
>  
>
>>The raid controller complained about a corrupt volume and destroyed it. 
>>It was done within a blink of an eye. (So i don't think everything is wiped.
>>
>>However LVM can't find my VG anymore. fdisk -l /dev/hde shows me that 
>>there simply isn't anything on it. Where as fdisk -l /dev/hdg tells me 
>>"Disk /dev/hdg doesn't contain a valid partition table" as I would have 
>>expected.
>>    
>>
>
>gpart could possibly help by guessing a partition table. This helped me
>several times getting some friend's broken Windoze machines to work
>again. (@gpart author: if we ever meet IRL, I owe you a beer!)
>
>MfG, JBG
>
>  
>
>------------------------------------------------------------------------
>
>_______________________________________________
>linux-lvm mailing list
>linux-lvm@redhat.com
>https://www.redhat.com/mailman/listinfo/linux-lvm
>read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
>

Re: [linux-lvm] Partition table gone? Any way to restore?

[Jan-Benedict Glaw]

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

On Wed, 2005-03-02 18:58:20 +0100, oliver <oliver@are-b.org>
wrote in message <4225FEBC.2060505@are-b.org>:
> When i do a less -f /dev/hde I can see a lot of data.
> 
> E.g. I see a string looking a lot like ReiserFS and scrolling down 
> further I see /dev/vg00/<nameofparts created> so I'm sure a LOT is still 
> there. I'll give it a shot. Any other ideas are still welcome!

So let gpart guess and re-install a partition record. Though, you'd
better prepare a backup of that given HDD...

MfG, JBG

-- 
Jan-Benedict Glaw       jbglaw@lug-owl.de    . +49-172-7608481             _ O _
"Eine Freie Meinung in  einem Freien Kopf    | Gegen Zensur | Gegen Krieg  _ _ O
 fuer einen Freien Staat voll Freier Bürger" | im Internet! |   im Irak!   O O O
ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [linux-lvm] Partition table gone? Any way to restore?

[oliver]

I do have an empty 120GB hdd available to dump the entire contence on. I 
guess dd will do the trick?

Jan-Benedict Glaw wrote:

>On Wed, 2005-03-02 18:58:20 +0100, oliver <oliver@are-b.org>
>wrote in message <4225FEBC.2060505@are-b.org>:
>  
>
>>When i do a less -f /dev/hde I can see a lot of data.
>>
>>E.g. I see a string looking a lot like ReiserFS and scrolling down 
>>further I see /dev/vg00/<nameofparts created> so I'm sure a LOT is still 
>>there. I'll give it a shot. Any other ideas are still welcome!
>>    
>>
>
>So let gpart guess and re-install a partition record. Though, you'd
>better prepare a backup of that given HDD...
>
>MfG, JBG
>
>  
>
>------------------------------------------------------------------------
>
>_______________________________________________
>linux-lvm mailing list
>linux-lvm@redhat.com
>https://www.redhat.com/mailman/listinfo/linux-lvm
>read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
>

Re: [linux-lvm] Partition table gone? Any way to restore?

[Jan-Benedict Glaw]

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

On Wed, 2005-03-02 20:08:11 +0100, oliver <oliver@are-b.org>
wrote in message <42260F1B.2030803@are-b.org>:
> I do have an empty 120GB hdd available to dump the entire contence on. I 
> guess dd will do the trick?

It will.

MfG, JBG

-- 
Jan-Benedict Glaw       jbglaw@lug-owl.de    . +49-172-7608481             _ O _
"Eine Freie Meinung in  einem Freien Kopf    | Gegen Zensur | Gegen Krieg  _ _ O
 fuer einen Freien Staat voll Freier Bürger" | im Internet! |   im Irak!   O O O
ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [linux-lvm] Partition table gone? Any way to restore?

[Jean-Luc Coulon (f5ibh)]

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

Le 02.03.2005 20:08:11, oliver a écrit :
> I do have an empty 120GB hdd available to dump the entire contence  
> on. I guess dd will do the trick?

ddrescue the weapon of the last chance ...

J-L

> 
> Jan-Benedict Glaw wrote:


> 
>> On Wed, 2005-03-02 18:58:20 +0100, oliver <oliver@are-b.org>
>> wrote in message <4225FEBC.2060505@are-b.org>:
>> 
>>> When i do a less -f /dev/hde I can see a lot of data.
>>> 
>>> E.g. I see a string looking a lot like ReiserFS and scrolling down  
>>> further I see /dev/vg00/<nameofparts created> so I'm sure a LOT is  
>>> still there. I'll give it a shot. Any other ideas are still welcome!
>>> 
>> 
>> So let gpart guess and re-install a partition record. Though, you'd
>> better prepare a backup of that given HDD...
>> 
>> MfG, JBG
>> 
>> 
>> ------------------------------------------------------------------------
>> 
>> _______________________________________________
>> linux-lvm mailing list
>> linux-lvm@redhat.com
>> https://www.redhat.com/mailman/listinfo/linux-lvm
>> read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
>> 
> 
> _______________________________________________
> linux-lvm mailing list
> linux-lvm@redhat.com
> https://www.redhat.com/mailman/listinfo/linux-lvm
> read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
> 
> 

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [linux-lvm] Partition table gone? Any way to restore?

[oliver]

Thanks! However the partition is fine and fit so I should be able to dd 
everything off of it.

The output of gpart was the following:
root@enterprise:~# gpart -w hmlvm,1.5 /dev/hde

Begin scan...
Possible partition(ReiserFS filesystem), size(50431mb), offset(14mb)

* Warning: short read near sector(120103011), 64512 bytes instead of 
66048. Skipp
ing...
End scan.

Checking partitions...
Partition(Linux ext2 filesystem): primary
Ok.

Guessed primary partition table:
Primary partition(1)
   type: 131(0x83)(Linux ext2 filesystem)
   size: 50431mb #s(103284656) s(29799-103314454)
   chs:  (29/9/1)-(1023/15/63)d (29/9/1)-(102494/7/62)r

Primary partition(2)
   type: 000(0x00)(unused)
   size: 0mb #s(0) s(0-0)
   chs:  (0/0/0)-(0/0/0)d (0/0/0)-(0/0/0)r
<snip> part 3 and 4 where 'unused'.

Now gpart found something, however not the missing LVM PV i was hoping. 
Or atleast, I don't think so. I will google around to see how to make a 
1 on 1 copy of this disk, and then try to write it. I'll report back. In 
the mean time, keep those ideas comming : )



Jean-Luc Coulon (f5ibh) wrote:

> Le 02.03.2005 20:08:11, oliver a �crit :
>
>> I do have an empty 120GB hdd available to dump the entire contence  
>> on. I guess dd will do the trick?
>
>
> ddrescue the weapon of the last chance ...
>
> J-L
>
>>
>> Jan-Benedict Glaw wrote:
>
>
>
>>
>>> On Wed, 2005-03-02 18:58:20 +0100, oliver <oliver@are-b.org>
>>> wrote in message <4225FEBC.2060505@are-b.org>:
>>>
>>>> When i do a less -f /dev/hde I can see a lot of data.
>>>>
>>>> E.g. I see a string looking a lot like ReiserFS and scrolling down  
>>>> further I see /dev/vg00/<nameofparts created> so I'm sure a LOT is  
>>>> still there. I'll give it a shot. Any other ideas are still welcome!
>>>>
>>>
>>> So let gpart guess and re-install a partition record. Though, you'd
>>> better prepare a backup of that given HDD...
>>>
>>> MfG, JBG
>>>
>>>
>>> ------------------------------------------------------------------------ 
>>>
>>>
>>> _______________________________________________
>>> linux-lvm mailing list
>>> linux-lvm@redhat.com
>>> https://www.redhat.com/mailman/listinfo/linux-lvm
>>> read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
>>>
>>
>> _______________________________________________
>> linux-lvm mailing list
>> linux-lvm@redhat.com
>> https://www.redhat.com/mailman/listinfo/linux-lvm
>> read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
>>
>>
>
>------------------------------------------------------------------------
>
>_______________________________________________
>linux-lvm mailing list
>linux-lvm@redhat.com
>https://www.redhat.com/mailman/listinfo/linux-lvm
>read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
>

Re: [linux-lvm] Partition table gone? Any way to restore?

[Jean-Luc Coulon (f5ibh)]

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

Le 02.03.2005 20:26:22, oliver a écrit :
> Thanks! However the partition is fine and fit so I should be able to  
> dd everything off of it.
> 
> The output of gpart was the following:
> root@enterprise:~# gpart -w hmlvm,1.5 /dev/hde
> 
> Begin scan...
> Possible partition(ReiserFS filesystem), size(50431mb), offset(14mb)
> 
> * Warning: short read near sector(120103011), 64512 bytes instead of  
> 66048. Skipp
> ing...
> End scan.
> 
> Checking partitions...
> Partition(Linux ext2 filesystem): primary
> Ok.
> 
> Guessed primary partition table:
> Primary partition(1)
>   type: 131(0x83)(Linux ext2 filesystem)
>   size: 50431mb #s(103284656) s(29799-103314454)
>   chs:  (29/9/1)-(1023/15/63)d (29/9/1)-(102494/7/62)r
> 
> Primary partition(2)
>   type: 000(0x00)(unused)
>   size: 0mb #s(0) s(0-0)
>   chs:  (0/0/0)-(0/0/0)d (0/0/0)-(0/0/0)r
> <snip> part 3 and 4 where 'unused'.
> 
> Now gpart found something, however not the missing LVM PV i was  
> hoping. Or atleast, I don't think so. I will google around to see how  
> to make a 1 on 1 copy of this disk, and then try to write it. I'll  
> report back. In the mean time, keep those ideas comming : )
> 

Just an idea, be careful, it is not the *truth* as I have not tested it  
yet.

Here is what I *think* :
The partition type is no matter for lvm.
Recover the partition as you like then do a fdisk to change the  
partition type to 8E ... and see (or pray)

J-L

( ... ]

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [linux-lvm] Partition table gone? Any way to restore?

[oliver]

Well that's one of the things I need to know. How do I recover the 
partition. Only the first few bytes are missing from what I can tell.

'normally' an LVM disk would say that it didn't contain a valid 
partition.  That part is missing from the disk and needs to be recoverd.

I've read that one could try pvcreate; vgcfgrestore.

I'm firstly making a backup of the disk with dd if=/dev/hde 
of=/mnt/hd/hde_raw_dump to ensure i can always 'go back' when I mess up.

gpart found my reiserfs partition (from the VG) so I suspect that all 
the data is still AOK. I'm just a little 'scared' to run pvcreate; 
vgcgrestore because when I want to 'list' my vgcgrestore I get the 
following error:

root@enterprise:/mnt/hd# vgcfgrestore -n vg00 -l
vgcfgrestore -- INFO: using backup file "/etc/lvmconf/vg00.conf"
vgcfgrestore -- ERROR: different structure size stored in 
"/etc/lvmconf/vg00.conf" than expected in file vg_cfgrestore.c [line 120]
vgcfgrestore -- ERROR "vg_cfgrestore(): read" restoring volume group "vg00"

I suppose this could be because of the missing PV and it won't work 
untill I have all three PV's up again. However 'listing' should be fine?

Jean-Luc Coulon (f5ibh) wrote:

> Le 02.03.2005 20:26:22, oliver a �crit :
>
>> Thanks! However the partition is fine and fit so I should be able to  
>> dd everything off of it.
>>
>> The output of gpart was the following:
>> root@enterprise:~# gpart -w hmlvm,1.5 /dev/hde
>>
>> Begin scan...
>> Possible partition(ReiserFS filesystem), size(50431mb), offset(14mb)
>>
>> * Warning: short read near sector(120103011), 64512 bytes instead of  
>> 66048. Skipp
>> ing...
>> End scan.
>>
>> Checking partitions...
>> Partition(Linux ext2 filesystem): primary
>> Ok.
>>
>> Guessed primary partition table:
>> Primary partition(1)
>>   type: 131(0x83)(Linux ext2 filesystem)
>>   size: 50431mb #s(103284656) s(29799-103314454)
>>   chs:  (29/9/1)-(1023/15/63)d (29/9/1)-(102494/7/62)r
>>
>> Primary partition(2)
>>   type: 000(0x00)(unused)
>>   size: 0mb #s(0) s(0-0)
>>   chs:  (0/0/0)-(0/0/0)d (0/0/0)-(0/0/0)r
>> <snip> part 3 and 4 where 'unused'.
>>
>> Now gpart found something, however not the missing LVM PV i was  
>> hoping. Or atleast, I don't think so. I will google around to see 
>> how  to make a 1 on 1 copy of this disk, and then try to write it. 
>> I'll  report back. In the mean time, keep those ideas comming : )
>>
>
> Just an idea, be careful, it is not the *truth* as I have not tested 
> it  yet.
>
> Here is what I *think* :
> The partition type is no matter for lvm.
> Recover the partition as you like then do a fdisk to change the  
> partition type to 8E ... and see (or pray)
>
> J-L
>
> ( ... ]
>
>------------------------------------------------------------------------
>
>_______________________________________________
>linux-lvm mailing list
>linux-lvm@redhat.com
>https://www.redhat.com/mailman/listinfo/linux-lvm
>read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
>

Re: [linux-lvm] Partition table gone? Any way to restore?

[Dan Stromberg]

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

On Wed, 2005-03-02 at 19:17 +0000, Jean-Luc Coulon (f5ibh) wrote:
> Le 02.03.2005 20:08:11, oliver a écrit :
> > I do have an empty 120GB hdd available to dump the entire contence  
> > on. I guess dd will do the trick?
> 
> ddrescue the weapon of the last chance ...

I wouldn't even call it the last chance.

If you're doing anything you suspect might toast your drive even
further, it's a very good idea to run dd_rescue on it first, so you have
a 2nd copy of the data to fall back on if something goes kerflooey.

Anyway, dd_rescue does appear to have advantages for data recovery,
relative to the more traditional "dd conv=noerror,sync".


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [linux-lvm] Partition table gone? Any way to restore?

[oliver]

Small update. Using a hex editor i was able to more closley examine my 
disk(s). Since I have 2 LVM setups I was somewhat able to compare what I 
have to what I should have. I do still need some insite however.

 From what I can tell, pvcreate only modifies the first few k's of the 
disk, followed by information stored from the vgcreate.
Then the lvcreate adds some more information after this. (vg00/lv basicly).

I hope i got it right so far : )

Now, the vgcreate information is identical on the two surviving parts 
except for a 'hostname<someserialnumber>' part around address 0x00012c.

Then at 0x0001000 we see the UUID of the VG passing by followed by some 
data (which is identical on all three vgs.

I don't think i have to look beyond this point in space/address.

Assuming that none of the tools (besides pvcreate) write anything before 
0x0001000, I should be able to pvcreate /dev/hde edit the UUID of that 
specific PV (to the same stored in the other two PV's so the three match 
up again) and have a fully workable LVM set again.

The only thing that might worry me is crc information stored somewhere 
after 0x0001000 (However it appears to me that there isn't a whole bunch 
of data stored before 0x0001000 and the data created by pvcreate is 
identical on all 3 drives with the exception of the UUID so the crc 
value should match again) and the string 'vg00'at 0x0000ac i see on all 
disks (the name of the vg.

What my question is (without spending days reading the sourcecode : ) is 
am I correct? Assuming that all the 'important' metadata and such is 
stored 'after' 0x0001000 hex, is there a good chance of it working?

I'm thinking of running a pvcreate, change the UUID of the PV to what I 
expect it to be, add 'vg00' at 0x000ac and be happy?

I could simply try, I know, but some feedback first would be appreciated 
; ) I really don't want to loose my data.

Thanks a lot.

Oliver

[linux-lvm] Internal Knowlegde required. Please help me recover this sucker.

[oliver]

WAS: Re: [linux-lvm] Partition table gone? Any way to restore?

After further examination the 'hostname<someserialnumber>' I've mention 
that worried me at first appears to be a unix timestamp. I don't think 
that it matters much. I've noticed that on my other LVM setup where I 
most likley did a pvcreate /dev/hdg /dev/hdi (to create them 
simultaniously) since the timestamps are 100% identical.

So I think I can be pretty safe by using the timestamp on my hde that I 
have on my hdg. I did create them the same day, I'm sure of that. (I am 
using LVM to span across multipledisks after all) The 3rd disk was added 
later, hence the different timestamp. So all I really need to know if 
some kind of crc/hash is computed after 0x0001000 so that I can try this.

Oliver.

oliver wrote:

> Small update. Using a hex editor i was able to more closley examine my 
> disk(s). Since I have 2 LVM setups I was somewhat able to compare what 
> I have to what I should have. I do still need some insite however.
>
> From what I can tell, pvcreate only modifies the first few k's of the 
> disk, followed by information stored from the vgcreate.
> Then the lvcreate adds some more information after this. (vg00/lv 
> basicly).
>
> I hope i got it right so far : )
>
> Now, the vgcreate information is identical on the two surviving parts 
> except for a 'hostname<someserialnumber>' part around address 0x00012c.
>
> Then at 0x0001000 we see the UUID of the VG passing by followed by 
> some data (which is identical on all three vgs.
>
> I don't think i have to look beyond this point in space/address.
>
> Assuming that none of the tools (besides pvcreate) write anything 
> before 0x0001000, I should be able to pvcreate /dev/hde edit the UUID 
> of that specific PV (to the same stored in the other two PV's so the 
> three match up again) and have a fully workable LVM set again.
>
> The only thing that might worry me is crc information stored somewhere 
> after 0x0001000 (However it appears to me that there isn't a whole 
> bunch of data stored before 0x0001000 and the data created by pvcreate 
> is identical on all 3 drives with the exception of the UUID so the crc 
> value should match again) and the string 'vg00'at 0x0000ac i see on 
> all disks (the name of the vg.
>
> What my question is (without spending days reading the sourcecode : ) 
> is am I correct? Assuming that all the 'important' metadata and such 
> is stored 'after' 0x0001000 hex, is there a good chance of it working?
>
> I'm thinking of running a pvcreate, change the UUID of the PV to what 
> I expect it to be, add 'vg00' at 0x000ac and be happy?
>
> I could simply try, I know, but some feedback first would be 
> appreciated ; ) I really don't want to loose my data.
>
> Thanks a lot.
>
> Oliver
>
> _______________________________________________
> linux-lvm mailing list
> linux-lvm@redhat.com
> https://www.redhat.com/mailman/listinfo/linux-lvm
> read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/

Re: [linux-lvm] Internal Knowlegde required. Follow up.

[oliver]

I couldn't figure out what was written at first onto this disk. The 
first few bytes made sense, text strings about Missing operation system 
and such. However 0x1fe and 0x1ff it said '55 AA'. Looking at my 
'normal' partitioned hda it made perfect sense however. That's the exact 
point where all the 'data' e.g. partition table? stops. So unless this 
raid controller wrote data anywhere else (got an e-mail to highpoint and 
waiting for answer on that) I can even say that only the first 0x200 
addresses (512 bytes DOH) are foobared.

So the re-ask and re-phrase my question. Does pvcreate write 'different' 
data each run in the first 512 bytes. Not counting the UUID and the 
timestamp. Does vgcreate write anything else in the first 512 besides 
the volume name on 0xac?

I hope some one can answer me that. If not by tomorrow round 3ish, I 
might get bold and try it anyhow! HA! And then, all I can ask for is 
lots of luck.


(The plan then, for those interested, and future archive readers is to:
    pvcreate on hde
    dd the first 512 bytes, edit the UUID and the timestamp (timestamp 
will match hdg, 'just in case it needs to be older'
    restore the backup I still have of hde (while I sleep as it takes 2 
hours or so with just dd if=/mnt/hd/backupfile of=/dev/hde atleast the 
other way around did)
    dd the first 512 bytes from above with the new UUID back onto hde.
    Party!, I hope.
)


oliver wrote:

> WAS: Re: [linux-lvm] Partition table gone? Any way to restore?
>
> After further examination the 'hostname<someserialnumber>' I've 
> mention that worried me at first appears to be a unix timestamp. I 
> don't think that it matters much. I've noticed that on my other LVM 
> setup where I most likley did a pvcreate /dev/hdg /dev/hdi (to create 
> them simultaniously) since the timestamps are 100% identical.
>
> So I think I can be pretty safe by using the timestamp on my hde that 
> I have on my hdg. I did create them the same day, I'm sure of that. (I 
> am using LVM to span across multipledisks after all) The 3rd disk was 
> added later, hence the different timestamp. So all I really need to 
> know if some kind of crc/hash is computed after 0x0001000 so that I 
> can try this.
>
> Oliver.
>
> oliver wrote:
>
>> Small update. Using a hex editor i was able to more closley examine 
>> my disk(s). Since I have 2 LVM setups I was somewhat able to compare 
>> what I have to what I should have. I do still need some insite however.
>>
>> From what I can tell, pvcreate only modifies the first few k's of the 
>> disk, followed by information stored from the vgcreate.
>> Then the lvcreate adds some more information after this. (vg00/lv 
>> basicly).
>>
>> I hope i got it right so far : )
>>
>> Now, the vgcreate information is identical on the two surviving parts 
>> except for a 'hostname<someserialnumber>' part around address 0x00012c.
>>
>> Then at 0x0001000 we see the UUID of the VG passing by followed by 
>> some data (which is identical on all three vgs.
>>
>> I don't think i have to look beyond this point in space/address.
>>
>> Assuming that none of the tools (besides pvcreate) write anything 
>> before 0x0001000, I should be able to pvcreate /dev/hde edit the UUID 
>> of that specific PV (to the same stored in the other two PV's so the 
>> three match up again) and have a fully workable LVM set again.
>>
>> The only thing that might worry me is crc information stored 
>> somewhere after 0x0001000 (However it appears to me that there isn't 
>> a whole bunch of data stored before 0x0001000 and the data created by 
>> pvcreate is identical on all 3 drives with the exception of the UUID 
>> so the crc value should match again) and the string 'vg00'at 0x0000ac 
>> i see on all disks (the name of the vg.
>>
>> What my question is (without spending days reading the sourcecode : ) 
>> is am I correct? Assuming that all the 'important' metadata and such 
>> is stored 'after' 0x0001000 hex, is there a good chance of it working?
>>
>> I'm thinking of running a pvcreate, change the UUID of the PV to what 
>> I expect it to be, add 'vg00' at 0x000ac and be happy?
>>
>> I could simply try, I know, but some feedback first would be 
>> appreciated ; ) I really don't want to loose my data.
>>
>> Thanks a lot.
>>
>> Oliver
>>
>> _______________________________________________
>> linux-lvm mailing list
>> linux-lvm@redhat.com
>> https://www.redhat.com/mailman/listinfo/linux-lvm
>> read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
>
>
> _______________________________________________
> linux-lvm mailing list
> linux-lvm@redhat.com
> https://www.redhat.com/mailman/listinfo/linux-lvm
> read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/

[linux-lvm] Help! CRC Calculation how and where?

[oliver]

So I went ahead and did as I said in my previous post. Everything looks 
good. I was missing some header information however. I'm guessing the 
'HM' parts are the PV information, and the 'HI' parts are the VG parts. 
Eitherway I 'copied' the missing bytes from my other two disks. I did 
this because on my other LVM setup these first few bytes where identical 
on all three disks aswell.

The data between 0x1a0 and 0x1cf is the last cruelpit however. There 
appears to be some CRC value or checksum calculated. I did not notice it 
at first, as pvcreate did create something there aswell which looked 
very similar. However it is not. Now I checked on my other LVM setup, 
and there also three different data sets. So I'm guessing it's a 
generated checksum or something the like.

I'm kinda lost here now however. What to do, what to do. Since it's late 
here I'm going to sleep. However I was thinking about the following, A) 
go through the LVM 1.08 source tree and find the checksum/crc algorithm 
and find out over wich area it is performed.
B) take a look at fix UUID. A contributated tool that would fix UUID's 
in older version. Now I don't really need that I don't think as it might 
mess up things more then it fixes, however it does most likley contain 
the oh so wanted insight on where and what to checksum/hash/whatever.

If somebody knows where to look, or better yet, what to do that would be 
greatly appreciated.

Oliver.


oliver wrote:

> I couldn't figure out what was written at first onto this disk. The 
> first few bytes made sense, text strings about Missing operation 
> system and such. However 0x1fe and 0x1ff it said '55 AA'. Looking at 
> my 'normal' partitioned hda it made perfect sense however. That's the 
> exact point where all the 'data' e.g. partition table? stops. So 
> unless this raid controller wrote data anywhere else (got an e-mail to 
> highpoint and waiting for answer on that) I can even say that only the 
> first 0x200 addresses (512 bytes DOH) are foobared.
>
> So the re-ask and re-phrase my question. Does pvcreate write 
> 'different' data each run in the first 512 bytes. Not counting the 
> UUID and the timestamp. Does vgcreate write anything else in the first 
> 512 besides the volume name on 0xac?
>
> I hope some one can answer me that. If not by tomorrow round 3ish, I 
> might get bold and try it anyhow! HA! And then, all I can ask for is 
> lots of luck.
>
>
> (The plan then, for those interested, and future archive readers is to:
>    pvcreate on hde
>    dd the first 512 bytes, edit the UUID and the timestamp (timestamp 
> will match hdg, 'just in case it needs to be older'
>    restore the backup I still have of hde (while I sleep as it takes 2 
> hours or so with just dd if=/mnt/hd/backupfile of=/dev/hde atleast the 
> other way around did)
>    dd the first 512 bytes from above with the new UUID back onto hde.
>    Party!, I hope.
> )
>
>
> oliver wrote:
>
>> WAS: Re: [linux-lvm] Partition table gone? Any way to restore?
>>
>> After further examination the 'hostname<someserialnumber>' I've 
>> mention that worried me at first appears to be a unix timestamp. I 
>> don't think that it matters much. I've noticed that on my other LVM 
>> setup where I most likley did a pvcreate /dev/hdg /dev/hdi (to create 
>> them simultaniously) since the timestamps are 100% identical.
>>
>> So I think I can be pretty safe by using the timestamp on my hde that 
>> I have on my hdg. I did create them the same day, I'm sure of that. 
>> (I am using LVM to span across multipledisks after all) The 3rd disk 
>> was added later, hence the different timestamp. So all I really need 
>> to know if some kind of crc/hash is computed after 0x0001000 so that 
>> I can try this.
>>
>> Oliver.
>>
>> oliver wrote:
>>
>>> Small update. Using a hex editor i was able to more closley examine 
>>> my disk(s). Since I have 2 LVM setups I was somewhat able to compare 
>>> what I have to what I should have. I do still need some insite however.
>>>
>>> From what I can tell, pvcreate only modifies the first few k's of 
>>> the disk, followed by information stored from the vgcreate.
>>> Then the lvcreate adds some more information after this. (vg00/lv 
>>> basicly).
>>>
>>> I hope i got it right so far : )
>>>
>>> Now, the vgcreate information is identical on the two surviving 
>>> parts except for a 'hostname<someserialnumber>' part around address 
>>> 0x00012c.
>>>
>>> Then at 0x0001000 we see the UUID of the VG passing by followed by 
>>> some data (which is identical on all three vgs.
>>>
>>> I don't think i have to look beyond this point in space/address.
>>>
>>> Assuming that none of the tools (besides pvcreate) write anything 
>>> before 0x0001000, I should be able to pvcreate /dev/hde edit the 
>>> UUID of that specific PV (to the same stored in the other two PV's 
>>> so the three match up again) and have a fully workable LVM set again.
>>>
>>> The only thing that might worry me is crc information stored 
>>> somewhere after 0x0001000 (However it appears to me that there isn't 
>>> a whole bunch of data stored before 0x0001000 and the data created 
>>> by pvcreate is identical on all 3 drives with the exception of the 
>>> UUID so the crc value should match again) and the string 'vg00'at 
>>> 0x0000ac i see on all disks (the name of the vg.
>>>
>>> What my question is (without spending days reading the sourcecode : 
>>> ) is am I correct? Assuming that all the 'important' metadata and 
>>> such is stored 'after' 0x0001000 hex, is there a good chance of it 
>>> working?
>>>
>>> I'm thinking of running a pvcreate, change the UUID of the PV to 
>>> what I expect it to be, add 'vg00' at 0x000ac and be happy?
>>>
>>> I could simply try, I know, but some feedback first would be 
>>> appreciated ; ) I really don't want to loose my data.
>>>
>>> Thanks a lot.
>>>
>>> Oliver
>>>
>>> _______________________________________________
>>> linux-lvm mailing list
>>> linux-lvm@redhat.com
>>> https://www.redhat.com/mailman/listinfo/linux-lvm
>>> read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
>>
>>
>>
>> _______________________________________________
>> linux-lvm mailing list
>> linux-lvm@redhat.com
>> https://www.redhat.com/mailman/listinfo/linux-lvm
>> read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
>
>
> _______________________________________________
> linux-lvm mailing list
> linux-lvm@redhat.com
> https://www.redhat.com/mailman/listinfo/linux-lvm
> read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/

Re: [linux-lvm] Help! PV Size calculation etc

[oliver]

So just before going to bed i wanted to take a quick peek at the output 
of pvdata /dev/hd[egi]

The good niews is Volume Group part appears to be Ok. Same on all three, 
only thing that worried me was 'NOT available/resizable' But since that 
is on my other LVM also the case (even with vgchange -an) i belive this 
is normal.

The list of logical volume is idenitcal on all 3 aswell, so that's a 
good sign too.

However what I belived to be CRC or checksum data, appears to be PV 
information. For instance. The two 'old' PV's are just Physical Volumes. 
/dev/hde however is a 'NEW Physical Volume' So I belive this to be one byte.
Then the PV Size. It gives me the full size of the disk. This appears to 
be odd aswell, as the other two drives have both some 32mb of NOT usable 
data on it. (with LVM beeing 142kb vs 134kb respct.) So I have NO clue 
what value would go here on my new PV.
The PV# is 0. This should be 1 I guess, since on the other two it is 2 
resp. 3.
The Cur LV  is 0 whereas the others are 1 and 2. That sounds reasonable, 
but would make more sense it would be 1, 2 and 3.
The PE Size (KByte) is 0. The others have an identical value of 32768. 
So i could copy that value as it is mostlikly the same.
The total PE size is unknown, but since i have a Total PE of the VG this 
number should be calculatable.
The Free PE is going to remain 0 as it is on the others.
Allocated PE is most lkley going to be the same als calculated PE.

But that, really, is for tomorrow. So if someone could give me an idea 
how to calculate the PV Size I'd be done I think.

oliver

oliver wrote:

> So I went ahead and did as I said in my previous post. Everything 
> looks good. I was missing some header information however. I'm 
> guessing the 'HM' parts are the PV information, and the 'HI' parts are 
> the VG parts. Eitherway I 'copied' the missing bytes from my other two 
> disks. I did this because on my other LVM setup these first few bytes 
> where identical on all three disks aswell.
>
> The data between 0x1a0 and 0x1cf is the last cruelpit however. There 
> appears to be some CRC value or checksum calculated. I did not notice 
> it at first, as pvcreate did create something there aswell which 
> looked very similar. However it is not. Now I checked on my other LVM 
> setup, and there also three different data sets. So I'm guessing it's 
> a generated checksum or something the like.
>
> I'm kinda lost here now however. What to do, what to do. Since it's 
> late here I'm going to sleep. However I was thinking about the 
> following, A) go through the LVM 1.08 source tree and find the 
> checksum/crc algorithm and find out over wich area it is performed.
> B) take a look at fix UUID. A contributated tool that would fix UUID's 
> in older version. Now I don't really need that I don't think as it 
> might mess up things more then it fixes, however it does most likley 
> contain the oh so wanted insight on where and what to 
> checksum/hash/whatever.
>
> If somebody knows where to look, or better yet, what to do that would 
> be greatly appreciated.
>
> Oliver.
>
>
> oliver wrote:
>
>> I couldn't figure out what was written at first onto this disk. The 
>> first few bytes made sense, text strings about Missing operation 
>> system and such. However 0x1fe and 0x1ff it said '55 AA'. Looking at 
>> my 'normal' partitioned hda it made perfect sense however. That's the 
>> exact point where all the 'data' e.g. partition table? stops. So 
>> unless this raid controller wrote data anywhere else (got an e-mail 
>> to highpoint and waiting for answer on that) I can even say that only 
>> the first 0x200 addresses (512 bytes DOH) are foobared.
>>
>> So the re-ask and re-phrase my question. Does pvcreate write 
>> 'different' data each run in the first 512 bytes. Not counting the 
>> UUID and the timestamp. Does vgcreate write anything else in the 
>> first 512 besides the volume name on 0xac?
>>
>> I hope some one can answer me that. If not by tomorrow round 3ish, I 
>> might get bold and try it anyhow! HA! And then, all I can ask for is 
>> lots of luck.
>>
>>
>> (The plan then, for those interested, and future archive readers is to:
>>    pvcreate on hde
>>    dd the first 512 bytes, edit the UUID and the timestamp (timestamp 
>> will match hdg, 'just in case it needs to be older'
>>    restore the backup I still have of hde (while I sleep as it takes 
>> 2 hours or so with just dd if=/mnt/hd/backupfile of=/dev/hde atleast 
>> the other way around did)
>>    dd the first 512 bytes from above with the new UUID back onto hde.
>>    Party!, I hope.
>> )
>>
>>
>> oliver wrote:
>>
>>> WAS: Re: [linux-lvm] Partition table gone? Any way to restore?
>>>
>>> After further examination the 'hostname<someserialnumber>' I've 
>>> mention that worried me at first appears to be a unix timestamp. I 
>>> don't think that it matters much. I've noticed that on my other LVM 
>>> setup where I most likley did a pvcreate /dev/hdg /dev/hdi (to 
>>> create them simultaniously) since the timestamps are 100% identical.
>>>
>>> So I think I can be pretty safe by using the timestamp on my hde 
>>> that I have on my hdg. I did create them the same day, I'm sure of 
>>> that. (I am using LVM to span across multipledisks after all) The 
>>> 3rd disk was added later, hence the different timestamp. So all I 
>>> really need to know if some kind of crc/hash is computed after 
>>> 0x0001000 so that I can try this.
>>>
>>> Oliver.
>>>
>>> oliver wrote:
>>>
>>>> Small update. Using a hex editor i was able to more closley examine 
>>>> my disk(s). Since I have 2 LVM setups I was somewhat able to 
>>>> compare what I have to what I should have. I do still need some 
>>>> insite however.
>>>>
>>>> From what I can tell, pvcreate only modifies the first few k's of 
>>>> the disk, followed by information stored from the vgcreate.
>>>> Then the lvcreate adds some more information after this. (vg00/lv 
>>>> basicly).
>>>>
>>>> I hope i got it right so far : )
>>>>
>>>> Now, the vgcreate information is identical on the two surviving 
>>>> parts except for a 'hostname<someserialnumber>' part around address 
>>>> 0x00012c.
>>>>
>>>> Then at 0x0001000 we see the UUID of the VG passing by followed by 
>>>> some data (which is identical on all three vgs.
>>>>
>>>> I don't think i have to look beyond this point in space/address.
>>>>
>>>> Assuming that none of the tools (besides pvcreate) write anything 
>>>> before 0x0001000, I should be able to pvcreate /dev/hde edit the 
>>>> UUID of that specific PV (to the same stored in the other two PV's 
>>>> so the three match up again) and have a fully workable LVM set again.
>>>>
>>>> The only thing that might worry me is crc information stored 
>>>> somewhere after 0x0001000 (However it appears to me that there 
>>>> isn't a whole bunch of data stored before 0x0001000 and the data 
>>>> created by pvcreate is identical on all 3 drives with the exception 
>>>> of the UUID so the crc value should match again) and the string 
>>>> 'vg00'at 0x0000ac i see on all disks (the name of the vg.
>>>>
>>>> What my question is (without spending days reading the sourcecode : 
>>>> ) is am I correct? Assuming that all the 'important' metadata and 
>>>> such is stored 'after' 0x0001000 hex, is there a good chance of it 
>>>> working?
>>>>
>>>> I'm thinking of running a pvcreate, change the UUID of the PV to 
>>>> what I expect it to be, add 'vg00' at 0x000ac and be happy?
>>>>
>>>> I could simply try, I know, but some feedback first would be 
>>>> appreciated ; ) I really don't want to loose my data.
>>>>
>>>> Thanks a lot.
>>>>
>>>> Oliver
>>>>
>>>> _______________________________________________
>>>> linux-lvm mailing list
>>>> linux-lvm@redhat.com
>>>> https://www.redhat.com/mailman/listinfo/linux-lvm
>>>> read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> linux-lvm mailing list
>>> linux-lvm@redhat.com
>>> https://www.redhat.com/mailman/listinfo/linux-lvm
>>> read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
>>
>>
>>
>> _______________________________________________
>> linux-lvm mailing list
>> linux-lvm@redhat.com
>> https://www.redhat.com/mailman/listinfo/linux-lvm
>> read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
>
>
> _______________________________________________
> linux-lvm mailing list
> linux-lvm@redhat.com
> https://www.redhat.com/mailman/listinfo/linux-lvm
> read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/