From: oliver <oliver@are-b.org>
To: LVM general discussion and development <linux-lvm@redhat.com>
Subject: Re: [linux-lvm] Internal Knowlegde required. Follow up.
Date: Fri, 04 Mar 2005 00:04:39 +0100 [thread overview]
Message-ID: <42279807.60501@are-b.org> (raw)
In-Reply-To: <42279465.8090009@are-b.org>
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/
next prev parent reply other threads:[~2005-03-03 23:04 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-03-02 17:45 [linux-lvm] Partition table gone? Any way to restore? oliver
2005-03-02 17:48 ` Jan-Benedict Glaw
2005-03-02 17:58 ` oliver
2005-03-02 18:05 ` Jan-Benedict Glaw
2005-03-02 19:08 ` oliver
2005-03-02 19:15 ` Jan-Benedict Glaw
2005-03-02 19:17 ` Jean-Luc Coulon (f5ibh)
2005-03-02 19:26 ` oliver
2005-03-02 19:33 ` Jean-Luc Coulon (f5ibh)
2005-03-02 20:09 ` oliver
2005-03-02 20:44 ` Dan Stromberg
2005-03-03 22:28 ` oliver
2005-03-03 22:49 ` [linux-lvm] Internal Knowlegde required. Please help me recover this sucker oliver
2005-03-03 23:04 ` oliver [this message]
2005-03-04 0:18 ` [linux-lvm] Help! CRC Calculation how and where? oliver
2005-03-04 0:37 ` [linux-lvm] Help! PV Size calculation etc oliver
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=42279807.60501@are-b.org \
--to=oliver@are-b.org \
--cc=linux-lvm@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.