[linux-lvm] Recovering PV's VG metadata

[linux-lvm] Recovering PV's VG metadata

[HopNet]

Hello all.  I would appreciate any help or pointers to recovering the VG
data on a "blown" PV.

My setup:
  Logical Volume Manager 0.8 by Heinz Mauelshagen  04/11/1999  (IOP 6)
  x86/OS SuSE 6.4 on system disk (scsi, non-LVM)
  data on VG00 on hda & hdc (whole disk, no partitions)
  only one LVol exists, and takes up whole VG.
  hda & hdc are identical models of hard drives.
  VG01 in examples is a NEW VG on scsi array and can be ignored.

Problem:
  OS disk got trashed & system wasn't bootable.
  Reinstalled OS.  I think at this point, LILO, thinking hda was the
boot drive, overwrote some of the VG data.
  no LVMtab or conf files to vgcfgrestore from. :-(

Now:
  pvdata sees partial data on hda, and everything on hdc

What I'm looking for:
  Is there anyway to take common data from hdc and write it back to
hda.  What tools are available for sector editing (LVM or general)?

zeus:~ # pvdata -a /dev/hda
--- Physical volume ---
PV Name
VG Name
ΦR
PV Size               12.14 GB / NOT usable 3.21 MB [LVM: 16.09 MB]
PV#                   0
PV Status             NOT available
Allocatable           yes (but full)
Cur LV                1
PE Size (KByte)       4096
Total PE              3106
Free PE               0
Allocated PE          3106

Segmentation fault
zeus:~ # pvdata -N -P /dev/hdc
--- Physical volume ---
PV Name               /dev/hdc
VG Name               vg00
PV Size               12.14 GB / NOT usable 3.24 MB [LVM: 242 KB]
PV#                   2
PV Status             available
Allocatable           yes (but full)
Cur LV                1
PE Size (KByte)       4096
Total PE              3106
Free PE               0
Allocated PE          3106

--- List of physical volumes ---

000: /dev/hda
001: /dev/hdc

zeus:~ # pvscan
pvscan -- reading all physical volumes (this may take a while...)
pvscan -- ACTIVE   PV "/dev/sdb1" of VG "vg01" [21.26 GB / 11.26 GB
free]
pvscan -- inactive PV "/dev/hdc"  is associated to an unknown VG (run
vgscan)
pvscan -- total: 2 [33.4 GB] / in use: 2 [33.4 GB] / in no VG: 0 [0]

zeus:~ #

  If there is any other info that might be helpful, please ask.

Thanks again,
  Keith@HopNet

Re: [linux-lvm] Recovering PV's VG metadata

[Andreas Dilger]

"Hopnet" writes:
>  OS disk got trashed & system wasn't bootable.
>  Reinstalled OS.  I think at this point, LILO, thinking hda was the
>boot drive, overwrote some of the VG data.
>  no LVMtab or conf files to vgcfgrestore from. :-(
>
>Now:
>  pvdata sees partial data on hda, and everything on hdc
>
>What I'm looking for:
>  Is there anyway to take common data from hdc and write it back to
>hda.  What tools are available for sector editing (LVM or general)?
>
>zeus:~ # pvdata -a /dev/hda
>--- Physical volume ---
>PV Name
>VG Name
>ΦR
>PV Size               12.14 GB / NOT usable 3.21 MB [LVM: 16.09 MB]
>PV#                   0
>PV Status             NOT available
>Allocatable           yes (but full)
>Cur LV                1
>PE Size (KByte)       4096
>Total PE              3106
>Free PE               0
>Allocated PE          3106
>
>Segmentation fault
>zeus:~ # pvdata -N -P /dev/hdc
>--- Physical volume ---
>PV Name               /dev/hdc
>VG Name               vg00
>PV Size               12.14 GB / NOT usable 3.24 MB [LVM: 242 KB]
>PV#                   2
>PV Status             available
>Allocatable           yes (but full)
>Cur LV                1
>PE Size (KByte)       4096
>Total PE              3106
>Free PE               0
>Allocated PE          3106

"pvdata -PP" will show you "pe_on_disk.base" and "pe_on_disk.size", e.g.

# pvdata -PP
...
pe_on_disk.base          184320
pe_on_disk.size          6385664

add numbers "(184320 + 6385664) / 1024 = 6416 kB".  This is the start
of the on-disk data for your LV, and if valid it should be < 1 PE in
size, normally 4MB (my system has 16MB PE size).  You could use "dd"
to back up from disk, for example:

dd if=/dev/hda bs=1k of=/dev/tape skip=6416
dd if=/dev/hdc bs=1k of=/dev/tape skip=6416

YOU SHOULD DO THIS BEFORE YOU DO ANYTHING ELSE, SO YOUR DATA IS SAFE.

If you have a disk or LV that is > 24GB in size, you could even dump the
whole LV into this backup disk, using:

dd if=/dev/hda bs=1k of=/dev/vgbackup/lvbackup skip=6416
dd if=/dev/hdc bs=1k of=/dev/vgbackup/lvbackup skip=6416 seek=(hda size)

The seek in the second "dd" will be the number of blocks written from the
first "dd" step.


You have two things you can try:

If it is LILO that wrote to the disk, it may only be the first 512 bytes
boot sector.  This would only overwrite the PV data on the disk, and not
any of the VG/LV info.  If your disks are both the same, you _could_ try:

dd if=/dev/hdc of=/dev/hda bs=512 count=1

which will copy the PV info over to /dev/hda, but it will be slightly wrong.
You then would need to fix the pv_number to be 0x00000001 (at byte offset
0x1b0), and the pv_uuid, 32 bytes at byte offset 2C.  You should be able
to get the correct UUID with:

pvdata -PU /dev/hdc

to list UUID of /dev/hdc, and UUID of both disks.  To write the correct
data to /dev/hda, you should be able to do this with (I'm assuming there
is "0x00000001" at offset 436, but you can use "od" to find this somewhere
else on the disk):

dd if=/dev/hdc of=/dev/hda bs=1 skip=436 seek=432 count=4
dd if=/dev/hdc of=/dev/hda bs=1 skip=<pv_uuidlist_on_disk.base> seek=44 count=32

This should allow you to use the disks as before.  If not, you can try the
second method, which is to create totally new PV/VG/LV data on the disk,
and then hope that it all works.  It will only work correctly if the first
PV was totally full before the second one was started, otherwise it is NOT
going to work.  IF IT DOESN'T WORK, IT WILL TOTALLY RUIN YOUR LVM CONFIG!!!

dd if=/dev/zero of=/dev/hda bs=1k count=1
dd if=/dev/zero of=/dev/hdc bs=1k count=1

pvcreate /dev/hda /dev/hdc
vgcreate  vgrecover /dev/hda /dev/hdc
lvcreate -n lvrecover -l 6212 vgrecover

You may then be able to mount /dev/vgrecover/lvrecover and access your
data.  If not, there is nothing else easy to do.  Try working with the
data you copied in step 1 above.

Cheers, Andreas

PS - Again and again, people have problems with LVM, and they HAVE NO BACKUP.
     Why, oh why, do people not make backups of their data?  It may be LVM
     that is causing some problems (obviously this is the list to report
     them), but your disk may also fail, you may run "rm -r" in the wrong
     place, you may get a lightening strike near your house, your house
     burns down, etc.  PEOPLE SHOULD MAKE BACKUPS!!!  Give a copy to your
     friend some time (especially one that doesn't know anything about
     Linux), so that they are safe in case of a house fire/flood/etc.  It
     WILL happen to YOU sooner or later, don't kid yourself.
-- 
Andreas Dilger  \ "If a man ate a pound of pasta and a pound of antipasto,
                 \  would they cancel out, leaving him still hungry?"
http://www-mddsp.enel.ucalgary.ca/People/adilger/               -- Dogbert

Re: [linux-lvm] Recovering PV's VG metadata

[Heinz J. Mauelshagen]

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!

-- 

Regards,
Heinz    -- The LVM Guy --


On Sun, Mar 18, 2001 at 07:52:21PM +0900, HopNet wrote:
> Hello all.  I would appreciate any help or pointers to recovering the VG
> data on a "blown" PV.
> 
> My setup:
>   Logical Volume Manager 0.8 by Heinz Mauelshagen  04/11/1999  (IOP 6)
>   x86/OS SuSE 6.4 on system disk (scsi, non-LVM)
>   data on VG00 on hda & hdc (whole disk, no partitions)
>   only one LVol exists, and takes up whole VG.
>   hda & hdc are identical models of hard drives.
>   VG01 in examples is a NEW VG on scsi array and can be ignored.
> 
> Problem:
>   OS disk got trashed & system wasn't bootable.
>   Reinstalled OS.  I think at this point, LILO, thinking hda was the
> boot drive, overwrote some of the VG data.
>   no LVMtab or conf files to vgcfgrestore from. :-(
> 
> Now:
>   pvdata sees partial data on hda, and everything on hdc
> 
> What I'm looking for:
>   Is there anyway to take common data from hdc and write it back to
> hda.  What tools are available for sector editing (LVM or general)?
> 
> zeus:~ # pvdata -a /dev/hda
> --- Physical volume ---
> PV Name
> VG Name
> ΦR
> PV Size               12.14 GB / NOT usable 3.21 MB [LVM: 16.09 MB]
> PV#                   0
> PV Status             NOT available
> Allocatable           yes (but full)
> Cur LV                1
> PE Size (KByte)       4096
> Total PE              3106
> Free PE               0
> Allocated PE          3106
> 
> Segmentation fault
> zeus:~ # pvdata -N -P /dev/hdc
> --- Physical volume ---
> PV Name               /dev/hdc
> VG Name               vg00
> PV Size               12.14 GB / NOT usable 3.24 MB [LVM: 242 KB]
> PV#                   2
> PV Status             available
> Allocatable           yes (but full)
> Cur LV                1
> PE Size (KByte)       4096
> Total PE              3106
> Free PE               0
> Allocated PE          3106
> 
> --- List of physical volumes ---
> 
> 000: /dev/hda
> 001: /dev/hdc
> 
> zeus:~ # pvscan
> pvscan -- reading all physical volumes (this may take a while...)
> pvscan -- ACTIVE   PV "/dev/sdb1" of VG "vg01" [21.26 GB / 11.26 GB
> free]
> pvscan -- inactive PV "/dev/hdc"  is associated to an unknown VG (run
> vgscan)
> pvscan -- total: 2 [33.4 GB] / in use: 2 [33.4 GB] / in no VG: 0 [0]
> 
> zeus:~ #
> 
>   If there is any other info that might be helpful, please ask.
> 
> Thanks again,
>   Keith@HopNet
> 
> 
> 
> 
> 
> _______________________________________________
> linux-lvm mailing list
> linux-lvm@sistina.com
> http://lists.sistina.com/mailman/listinfo/linux-lvm


*** Software bugs are stupid.
    Nevertheless it needs not so stupid people to solve them ***

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Heinz Mauelshagen                                 Sistina Software Inc.
Senior Consultant/Developer                       Am Sonnenhang 11
                                                  56242 Marienrachdorf
                                                  Germany
Mauelshagen@Sistina.com                           +49 2626 141200
                                                       FAX 924446
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Re: [linux-lvm] Recovering PV's VG metadata

[HopNet]

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!

Re: [linux-lvm] Recovering PV's VG metadata

[Andreas Dilger]

"Hopnet" writes:
> 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.

Is this a user message, or a kernel message?  Could you please give the
exact message, so I can find where it is coming from?

> hda showed: (after LILO, which 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.

Yes, for the same disks, the PV info should be the same.

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

Yes, I only noticed this after Heinz's post.

> If I can't get the offset fixed, I'll probably try creating the
> "lvrecover" that Andreas suggested.

I would avoid that, since it appears we are almost working.

Cheers, Andreas
-- 
Andreas Dilger  \ "If a man ate a pound of pasta and a pound of antipasto,
                 \  would they cancel out, leaving him still hungry?"
http://www-mddsp.enel.ucalgary.ca/People/adilger/               -- Dogbert

Re: [linux-lvm] Recovering PV's VG metadata

[Heinz J. Mauelshagen]

On Tue, Mar 20, 2001 at 06:06:11PM +0900, HopNet wrote:
> 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.
> 

As Andreas questioned in his answer: where does that message come from and
what is it exactly?


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

If the models are *exactly* equal there are none.

If there's firmware differences that could actually lead to slightly different
sizes beeing exposed to the OS.
This difference could eventually lead to an additional PE on one disk causing
an *additional* entry in the mapping table in the VGDA on disk which starts at
offset pv->pe_on_disk.base set in library functions
vg_setup_for_{create,extend}() calculated by macro LVM_PE_ON_DISK_BASE(pv)
defined in lvm.h.
Nevertheless the beginning offsets to the mapping tables should be
the same, because this macro was introduced in LVM 0.6 and hasn't changed
since then.

Explained that we still need the exact "wrong major or minor number" messages
in order to proceed ;-)


> 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?

See the pv_on_disk, vg_on_disk, pv_name_list_on_disk, lv_on_disk and pe_on_disk
structures beeing set in vg_setup_for_{create,extend}() and the macros defined
in lvm.h they use.

Structure layout from the beginning of the PV is:

 - PV
 - VG
 - NAMELIST (of all devices names used; changed to UUIDLIST in 0.9)
 - LVs
 - PEs

Regards,
Heinz    -- The LVM Guy --

> 
> 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!
> 
> 
> _______________________________________________
> linux-lvm mailing list
> linux-lvm@sistina.com
> http://lists.sistina.com/mailman/listinfo/linux-lvm

*** Software bugs are stupid.
    Nevertheless it needs not so stupid people to solve them ***

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Heinz Mauelshagen                                 Sistina Software Inc.
Senior Consultant/Developer                       Am Sonnenhang 11
                                                  56242 Marienrachdorf
                                                  Germany
Mauelshagen@Sistina.com                           +49 2626 141200
                                                       FAX 924446
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Re: [linux-lvm] Recovering PV's VG metadata

[HopNet]

The Majic message is:

zeus:~ # mount /dev/vg00/lvol1 /mnt/raid
mount: /dev/vg00/lvol1 has wrong major or minor number
zeus:~ #

Once upon a time, this msg originated in:
/*
  * A mount(8) for Linux 0.99.
  * mount.c,v 1.1.1.1 1993/11/18 08:40:51 jrs Exp *
....which I found by searching the web.  Needless to say, this probably isn't the same place as on my system...but, I can't find the same msg in the source on my system!

  It should be a ext2 fs, which is supported in the kernel.

so...
I eventually got around to doing
zeus:/lib/modules/2.2.14/fs # mount -v /dev/vg00/lvol1 /mnt/raid/
mount: you didn't specify a filesystem type for /dev/vg00/lvol1
        I will try all types mentioned in /etc/filesystems or /proc/filesystems
Trying vfat
Trying hfs
mount: /dev/vg00/lvol1 has wrong major or minor number
zeus:/lib/modules/2.2.14/fs # mount -v -t ext2 /dev/vg00/lvol1 /mnt/raid/
mount: wrong fs type, bad option, bad superblock on /dev/vg00/lvol1,
        or too many mounted file systems
zeus:/lib/modules/2.2.14/fs #

no dice...
   grabbed hexedit and examined lvol1 the hard way...ooh, lot's of zeros, not good.
   grabbed lde (linux disk editor) and had it look at lvol1.  It could not identify the filesystem.

So, I'm thinking my next plan of action will be to search /dev/hda for any recognizable data structures (i.e. the beginning of the lvol), and making sure the VG data is pointing to the right place.

Any other ideas?





other stuff follows:

zeus:~ # pvscan
pvscan -- reading all physical volumes (this may take a while...)
pvscan -- ACTIVE   PV "/dev/sdb1" of VG "vg01" [21.26 GB / 0 free]
pvscan -- inactive PV "/dev/hda"  of VG "vg00" [12.13 GB / 0 free]
pvscan -- inactive PV "/dev/hdc"  of VG "vg00" [12.13 GB / 0 free]
pvscan -- total: 3 [45.54 GB] / in use: 3 [45.54 GB] / in no VG: 0 [0]

zeus:~ # vgscan
vgscan -- reading all physical volumes (this may take a while...)
vgscan -- found active volume group "vg01"
vgscan -- found inactive volume group "vg00"
vgscan -- "/etc/lvmtab" and "/etc/lvmtab.d" successfully created
vgscan -- WARNING: you may not have an actual backup of your volume groups

zeus:~ # vgchange -a y vg00
vgchange -- volume group "vg00" successfully activated

zeus:~ # ll /dev/vg00
total 36
dr-xr-xr-x   2 root     root         4096 Mar 21 12:18 .
drwxr-xr-x   8 root     root        32768 Mar 21 12:18 ..
crw-r-----   1 root     root     109,   0 Mar 21 12:18 group
brw-r-----   1 root     root      58,   0 Mar 21 12:18 lvol1
zeus:~ # mount /dev/vg00/lvol1 /mnt/raid
mount: /dev/vg00/lvol1 has wrong major or minor number
zeus:~ #

and just as a sanity check...boot.msg

<6>Uniform Multi-Platform E-IDE driver Revision: 6.30
<4>ide: Assuming 40MHz system bus speed for PIO modes; override with idebus=xx
<4>ALI15X3: IDE controller on PCI bus 00 dev 78
<4>ALI15X3: not 100% native mode: will probe irqs later
<4>    ide0: BM-DMA at 0xb400-0xb407, BIOS settings: hda:pio, hdb:pio
<4>    ide1: BM-DMA at 0xb408-0xb40f, BIOS settings: hdc:pio, hdd:pio
<4>hda: Maxtor 91303D6, ATA DISK drive
<4>hdc: Maxtor 91303D6, ATA DISK drive
<4>ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
<4>ide1 at 0x170-0x177,0x376 on irq 15
<6>hda: Maxtor 91303D6, 12427MB w/512kB Cache, CHS=25249/16/63, UDMA(33)
<6>hdc: Maxtor 91303D6, 12427MB w/512kB Cache, CHS=25249/16/63, UDMA(33)

....

<4>Partition check:
<4> sda: sda1 sda2 sda3
<4> sdb: sdb1
<4> hda: hda1
<4> hdc: hdc1

Anyone know why this sees hda1 & hdc1?  There are no partition tables.

and fdisk appears to be confused (just like me most of the time)

zeus:~ # cat fdisk.out
Disk /dev/vg00/lvol1 doesn't contain a valid partition table
Disk /dev/vg01/lvol1 doesn't contain a valid partition table

Disk /dev/sda: 255 heads, 63 sectors, 1043 cylinders
Units = cylinders of 16065 * 512 bytes

    Device Boot    Start       End    Blocks   Id  System
/dev/sda1   *         1        17    136521   83  Linux
/dev/sda2            18        83    530145   82  Linux swap
/dev/sda3            84      1043   7711200   83  Linux

Disk /dev/sdb: 255 heads, 63 sectors, 2776 cylinders
Units = cylinders of 16065 * 512 bytes

    Device Boot    Start       End    Blocks   Id  System
/dev/sdb1             1      2776  22298188+  8e  Unknown

Disk /dev/hda: 16 heads, 63 sectors, 25249 cylinders
Units = cylinders of 1008 * 512 bytes

    Device Boot    Start       End    Blocks   Id  System

Disk /dev/vg00/lvol1: 64 heads, 32 sectors, 24848 cylinders
Units = cylinders of 2048 * 512 bytes


Disk /dev/vg01/lvol1: 64 heads, 32 sectors, 21772 cylinders
Units = cylinders of 2048 * 512 bytes


Disk /dev/hdc: 16 heads, 63 sectors, 25249 cylinders
Units = cylinders of 1008 * 512 bytes

    Device Boot    Start       End    Blocks   Id  System


Heinz J. Mauelshagen wrote:

> On Tue, Mar 20, 2001 at 06:06:11PM +0900, HopNet wrote:
> 
>> 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.
>> 
> 
> 
> As Andreas questioned in his answer: where does that message come from and
> what is it exactly?
> 
> 
> 
>> 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.
>> 
> 
> 
> If the models are *exactly* equal there are none.
> 
> If there's firmware differences that could actually lead to slightly different
> sizes beeing exposed to the OS.
> This difference could eventually lead to an additional PE on one disk causing
> an *additional* entry in the mapping table in the VGDA on disk which starts at
> offset pv->pe_on_disk.base set in library functions
> vg_setup_for_{create,extend}() calculated by macro LVM_PE_ON_DISK_BASE(pv)
> defined in lvm.h.
> Nevertheless the beginning offsets to the mapping tables should be
> the same, because this macro was introduced in LVM 0.6 and hasn't changed
> since then.
> 
> Explained that we still need the exact "wrong major or minor number" messages
> in order to proceed ;-)
> 
> 
> 
>> 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?
> 
> 
> See the pv_on_disk, vg_on_disk, pv_name_list_on_disk, lv_on_disk and pe_on_disk
> structures beeing set in vg_setup_for_{create,extend}() and the macros defined
> in lvm.h they use.
> 
> Structure layout from the beginning of the PV is:
> 
>  - PV
>  - VG
>  - NAMELIST (of all devices names used; changed to UUIDLIST in 0.9)
>  - LVs
>  - PEs
> 
> Regards,
> Heinz    -- The LVM Guy --
> 
> 
>> 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!
>> 
>> 
>> _______________________________________________
>> linux-lvm mailing list
>> linux-lvm@sistina.com
>> http://lists.sistina.com/mailman/listinfo/linux-lvm
> 
> 
> *** Software bugs are stupid.
>     Nevertheless it needs not so stupid people to solve them ***
> 
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> 
> Heinz Mauelshagen                                 Sistina Software Inc.
> Senior Consultant/Developer                       Am Sonnenhang 11
>                                                   56242 Marienrachdorf
>                                                   Germany
> Mauelshagen@Sistina.com                           +49 2626 141200
>                                                        FAX 924446
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> _______________________________________________
> linux-lvm mailing list
> linux-lvm@sistina.com
> http://lists.sistina.com/mailman/listinfo/linux-lvm