Partition table gone? Any way to restore?

linux-lvm oliver 4 participants 16 messages Mar 2, 2005 – Mar 4, 2005

Share & tools

oliver

author

2005-03-02 17:45 UTC #0 lore raw

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

Jan-Benedict Glaw

2005-03-02 17:48 UTC #1 lore raw

On Wed, 2005-03-02 18:45:44 +0100, oliver <[email protected]> wrote in message <[email protected]>:

Quoted 7 lines

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

Signature · 4 lines

Jan-Benedict Glaw       [email protected]    . +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));

oliver

author

2005-03-02 17:58 UTC #2 lore raw

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!

Quoted 26 lines · Jan-Benedict Glaw

On Wed, 2005-03-02 18:45:44 +0100, oliver <[email protected]> wrote in message <[email protected]>:
Quoted 5 lines
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
[email protected]
https://www.redhat.com/mailman/listinfo/linux-lvm
read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/

Jan-Benedict Glaw

2005-03-02 18:05 UTC #3 lore raw

On Wed, 2005-03-02 18:58:20 +0100, oliver <[email protected]> wrote in message <[email protected]>:

Quoted 5 lines

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

Signature · 4 lines

Jan-Benedict Glaw       [email protected]    . +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));

oliver

author

2005-03-02 19:08 UTC #4 lore raw

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

Quoted 25 lines · Jan-Benedict Glaw

On Wed, 2005-03-02 18:58:20 +0100, oliver <[email protected]> wrote in message <[email protected]>:
Quoted 5 lines
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
[email protected]
https://www.redhat.com/mailman/listinfo/linux-lvm
read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/

Jan-Benedict Glaw

2005-03-02 19:15 UTC #5 lore raw

On Wed, 2005-03-02 20:08:11 +0100, oliver <[email protected]> wrote in message <[email protected]>:

Quoted 2 lines

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

Signature · 4 lines

Jan-Benedict Glaw       [email protected]    . +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));

Jean-Luc Coulon (f5ibh)

2005-03-02 19:17 UTC #6 lore raw

In reply to oliver

Le 02.03.2005 20:08:11, oliver a écrit :

Quoted 1 line

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

Quoted 35 lines

Quoted 14 lines · Jan-Benedict Glaw
On Wed, 2005-03-02 18:58:20 +0100, oliver <[email protected]> wrote in message <[email protected]>:
Quoted 4 lines
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
Quoted 8 lines
------------------------------------------------------------------------
_______________________________________________
linux-lvm mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/linux-lvm
read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
_______________________________________________
linux-lvm mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/linux-lvm
read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/

oliver

author

2005-03-02 19:26 UTC #7 lore raw

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 : )

Quoted 55 lines · Jean-Luc Coulon (f5ibh) wrote:

Le 02.03.2005 20:08:11, oliver a ï¿½crit :
Quoted 1 line
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
Quoted 30 lines
Quoted 14 lines · Jan-Benedict Glaw
On Wed, 2005-03-02 18:58:20 +0100, oliver <[email protected]> wrote in message <[email protected]>:
Quoted 4 lines
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
Quoted 9 lines
------------------------------------------------------------------------
_______________________________________________
linux-lvm mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/linux-lvm
read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
Quoted 7 lines
_______________________________________________
linux-lvm mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/linux-lvm
read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
------------------------------------------------------------------------
_______________________________________________
linux-lvm mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/linux-lvm
read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/

Jean-Luc Coulon (f5ibh)

2005-03-02 19:34 UTC #8 lore raw

Le 02.03.2005 20:26:22, oliver a écrit :

Quoted 22 lines

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

Quoted 8 lines

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

( ... ]

oliver

author

2005-03-02 20:10 UTC #9 lore raw

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?

Quoted 51 lines · Jean-Luc Coulon (f5ibh) wrote:

Le 02.03.2005 20:26:22, oliver a ï¿½crit :
Quoted 22 lines
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
Quoted 8 lines
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
[email protected]
https://www.redhat.com/mailman/listinfo/linux-lvm
read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/

Dan Stromberg

2005-03-02 20:44 UTC #10 lore raw

In reply to Jean-Luc Coulon (f5ibh)

Quoted 5 lines · On Wed, 2005-03-02 at 19:17 +0000, Jean-Luc Coulon (f5ibh) wrote:

Quoted 2 lines · oliver
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".

oliver

author

2005-03-03 22:28 UTC #11 lore raw

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

oliver

author

2005-03-03 22:49 UTC #12 lore raw

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

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.

Quoted 32 lines · 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 mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/linux-lvm
read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/

oliver

author

2005-03-03 23:04 UTC #13 lore raw

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

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.
)

Quoted 49 lines · 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.
Quoted 25 lines · 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.
Quoted 7 lines
Oliver
_______________________________________________
linux-lvm mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/linux-lvm
read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
_______________________________________________
linux-lvm mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/linux-lvm
read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/

oliver

author

2005-03-04 00:18 UTC #14 lore raw

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

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.

Quoted 77 lines · 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.
)
Quoted 45 lines · 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.
Quoted 25 lines · 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.
Quoted 7 lines
Oliver
_______________________________________________
linux-lvm mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/linux-lvm
read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
Quoted 5 lines
_______________________________________________
linux-lvm mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/linux-lvm
read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
_______________________________________________
linux-lvm mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/linux-lvm
read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/

oliver

author

2005-03-04 00:37 UTC #15 lore raw

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

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

Quoted 100 lines · 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.
Quoted 74 lines · 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.
)
Quoted 46 lines · 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.
Quoted 25 lines · 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.
Quoted 7 lines
Oliver
_______________________________________________
linux-lvm mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/linux-lvm
read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
Quoted 5 lines
_______________________________________________
linux-lvm mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/linux-lvm
read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
Quoted 5 lines
_______________________________________________
linux-lvm mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/linux-lvm
read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
_______________________________________________
linux-lvm mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/linux-lvm
read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/