vg_name'... = This of > >>course assumes that the previous lv resided wholly on /dev/hdd2. = Then > >>try mounting the new lv and see what happens. > > > >Before you do that, try vgcfgrestore. > > >=20 > AJ, when he did the initial 'vgcreate' was part of the process to=20 > create a backup copy of the metadata? If so, vgcfgrestore could = work. =20 > But otherwise, I'm not sure were the old metadata would be stored,=20 > since this disk is from a different machine... Seems odd to me that = > vgcreate would blow over the old vg if it knew about it. If it did = not=20 > know (or detect the old vg), how would it know to backup the = metadata? Not sure, but if the reason the disk was moved was because a cpu went = out, i'm assuming the old root fs is also on that disk - hoping so anyway ;) = If so, the old root fs can be mounted and /etc/lvm/archive can be checked for = a valid copy of the metadata. (Assuming root wasn't on lvm...) As to why vgcreate didn't recognize the old VG...that's very odd - not = sure what went wrong there... ------=_NextPart_000_0119_01C596DF.93A69B10 Content-Type: text/html; charset="big5" Content-Transfer-Encoding: quoted-printable

Hi,

There is no backup information available in=20 /etc/lvm/archive to restore VG to original=20 configuration.

Unfortunately the root directory is also in LVM=20 partition.

So, "vgcfgrestore" did not solve the = problem.

I also tried to create new LV by "lvcreate" to match = with=20 the existing LV.

The problem is I have no idea about the size of old=20 LV.

I just gave a random size in "lvcreate" = command.

But, I could not mount the file system because of = bad=20 superblock.

I don't know what I missed. Maybe the size is = critical to do=20 the matching.

Is there any reverse procedure I can do to recover = VG by the=20 existing LV information?

It may just like to recover partition table by = scanning=20 cylinder data in hard disk.

Any idea? Thanks a lot.

Davis

> >On Wed, Jul 27, 2005 at 11:33:05AM -0500, Jonathan E = Brassow=20 wrote:
> >>I'm not familiar exactly with how the metadata = gets=20 laid on disk, but
> >>I would think you could just = 'vgcreate=20 vg_name /dev/hdd2' (you did
> >>this
> = >>already)=20 then 'lvcreate -n <lvname> -l <max size> vg_name'... = This=20 of
> >>course assumes that the previous lv resided wholly = on=20 /dev/hdd2. Then
> >>try mounting the new lv and see = what=20 happens.
> >
> >Before you do that, try=20 vgcfgrestore.
> >
>
> AJ, when he did the = initial=20 'vgcreate' was part of the process to
> create a backup copy of = the=20 metadata? If so, vgcfgrestore could work.
> But = otherwise,=20 I'm not sure were the old metadata would be stored,
> since = this disk=20 is from a different machine... Seems odd to me that
> = vgcreate=20 would blow over the old vg if it knew about it. If it did not =
>=20 know (or detect the old vg), how would it know to backup the=20 metadata?

Not sure, but if the reason the disk was moved was = because a=20 cpu went out, i'm
assuming the old root fs is also on that disk - = hoping so=20 anyway ;) If so,
the old root fs can be mounted and = /etc/lvm/archive=20 can be checked for a valid
copy of the metadata. (Assuming = root=20 wasn't on lvm...)

As to why vgcreate didn't recognize the old=20 VG...that's very odd - not sure
what went wrong=20 there...

------=_NextPart_000_0119_01C596DF.93A69B10--