From: HopNet <hne@inetnow.net>
To: linux-lvm@sistina.com
Subject: Re: [linux-lvm] Recovering PV's VG metadata
Date: Tue, 20 Mar 2001 18:06:11 +0900 [thread overview]
Message-ID: <3AB71D83.2000000@inetnow.net> (raw)
In-Reply-To: 20010319131456.C26986@sistina.com
Thanks to Heinz & Andreas for your suggestions. They are "almost" working. :-) I can activate the VG, but I'm getting "wrong major or minor number" from the mount of the lvol, so I'm thinking I have an offset that is not correct.
Heinz, you're assumptions (listed below) are correct. The PVs are identical models.
One thing I have a question about, and this may lead to resolving my offset problem, is where does the following pvdata info come from?
hda showed: (after LILO, which, I can see from the hex dump, was indeed the problem)
PV Size 12.14 GB / NOT usable 3.21 MB [LVM: 16.09 MB]
hdc showed:
PV Size 12.14 GB / NOT usable 3.24 MB [LVM: 242 KB]
After I copied the header over, they are the same (as hdc). Should they be the same? Or do I need to fudge some more numbers in the hda header.
Heinz, from your paragraph below: What should I be looking for to identify the first sector of "?" Is there a block diagram available with the metadata layout?
Andreas, this appears to be a v1 header, so no uuid. This confused the heck out of me for a while, until I finally deciphered part of lvm.h. Also, pvdata doesn't support -PU on this release.
If I can't get the offset fixed, I'll probably try creating the "lvrecover" that Andreas suggested.
One the bright side, I do have a backup I recovered! On the dark side, my backups have been flaky, and the only good one was two months old :-( Time to invest in a new tape drive. Well 12G of data is better than no data at all.
Heinz J. Mauelshagen wrote:
> I understand:
>
> - you are not booting from hda or hdc
>
> - hdc still holds a valid LVM VGDA
>
> - likely the first sector of hda got blown away (by lilo)
>
> - you don't have any /etc/lvmconf/ VGDA backup files on disk/tape
> (if not so use vgcfgrestore(8) in order to restore metadata to /dev/hda!)
>
>
> I'm assuming based on the data below:
>
> - your 2 physical volumes are equal in size
>
> - you had just 1 logical volume spread over both physical volumes using
> all of the VG's capacity
>
> - all of your VGDA with the exception of the physical volume structure,
> which was sitting at the very beginning of hda is still there and
> likely valid
>
>
> *If* the above assumptions are correct, your option is to copy the first
> sector of /dev/hdc over to /dev/hda with
> "dd if=/dev/hdc bs=512 count=1 of=/dev/hda" *and* change it with a hex editor.
>
> In order to find the correct offsets into the first sector on /dev/hda to
> change, look at lvm.h (of LVM 0.8final!) and the definition of pv_disk_t in
> that header file.
>
> At least you need to change the physical number (pv_number); set it to 1.
>
> In case the above assumptions are not correct for eg. the sizes of the PVs
> differ, you need to change pv_size, pe_total and pe_allocated as well.
>
> Please get back to me if this is the case.
>
>
> BTW: we are working on the enhancement of our LVM checker in order
> to support such repairs. Not very helpfull for you nor, I know :(
>
> Don't forget to check your /etc/lilo.conf to make sure, that lilo doesn't
> tamper with the first sector on /dev/hda again!
next prev parent reply other threads:[~2001-03-20 9:06 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-03-18 10:52 [linux-lvm] Recovering PV's VG metadata HopNet
2001-03-19 6:33 ` Andreas Dilger
2001-03-19 13:14 ` Heinz J. Mauelshagen
2001-03-20 9:06 ` HopNet [this message]
2001-03-20 10:40 ` Andreas Dilger
2001-03-20 12:25 ` Heinz J. Mauelshagen
2001-03-21 0:46 ` HopNet
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=3AB71D83.2000000@inetnow.net \
--to=hne@inetnow.net \
--cc=linux-lvm@sistina.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.