[linux-lvm] uuid already in use

[linux-lvm] uuid already in use

[Thomas Krichel]

  Hi,

  I have a disk /dev/hdb that appears to be physically
  damaged. It is in a volume group vg1. At some 
  stage it was so bad that I could not see it

raneb:# fdisk /dev/hdb

Unable to open /dev/hdb

  I ran 

raneb:# vgreduce vg1 --removemissing

  but could not restore the volume group to run,
  it kept complaing that /dev/hdb was missing.

  I read 

http://www.novell.com/communities/node/1502/recovering+lost+lvm+volume+disk

  and tried to apply the procedure described in the
  section "disk permanently removed". I first had
  to order a new disk. A new 500G disk arrived today.

  After a long shutdown, today the disk appears
  visible again, miraculously. 

raneb:/etc/lvm/archive# fdisk -l /dev/hdb

Disk /dev/hdb: 200.0 GB, 200049647616 bytes
255 heads, 63 sectors/track, 24321 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0x00000000

   Device Boot      Start         End      Blocks   Id  System
/dev/hdb1               1       24321   195358401   83  Linux

  So I try to see it in lvm

raneb:/etc/lvm/archive# pvdisplay 
  Warning: Volume Group vg1 is not consistent
  --- Physical volume ---
  PV Name               /dev/hdd1
  VG Name               vg1
  PV Size               186.31 GB / not usable 3.69 MB
  Allocatable           yes 
  PE Size (KByte)       4096
  Total PE              47694
  Free PE               47694
  Allocated PE          0
  PV UUID               vy3MOc-47sl-zUal-nhdO-FFX3-ispO-Rl0h8p
   
  --- Physical volume ---
  PV Name               /dev/hdc
  VG Name               vg1
  PV Size               465.76 GB / not usable 4.02 MB
  Allocatable           yes 
  PE Size (KByte)       4096
  Total PE              119234
  Free PE               119234
  Allocated PE          0
  PV UUID               NxRIE1-ROxx-pfjJ-QHzh-7B80-F7wt-kRCmSK
   

  I try to recover the metadata. The correct one is in 
  vg1_00026.vg, because this is the version before the
  "vgreduce vg1 --removemissing". But

raneb:/etc/lvm/archive# pvcreate --uuid v3HXpi-d5QN-OGiW-VFBG-TNIY-qTun-bFhlVd  --restorefile vg1_00026.vg /dev/hdb
  uuid v3HXpi-d5QN-OGiW-VFBG-TNIY-qTun-bFhlVd already in use on "/dev/hdb1"

  I am puzzled. pvdisplay does not see the uuid value but
  pvcreate says it is is use?? What am I missing here?



  Cheers,

  Thomas Krichel                    http://openlib.org/home/krichel
                                RePEc:per:1965-06-05:thomas_krichel
                                               skype: thomaskrichel

Re: [linux-lvm] uuid already in use

[Bryn M. Reeves]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Thomas Krichel wrote:
> raneb:/etc/lvm/archive# pvcreate --uuid v3HXpi-d5QN-OGiW-VFBG-TNIY-qTun-bFhlVd  --restorefile vg1_00026.vg /dev/hdb
>   uuid v3HXpi-d5QN-OGiW-VFBG-TNIY-qTun-bFhlVd already in use on "/dev/hdb1"
> 
>   I am puzzled. pvdisplay does not see the uuid value but
>   pvcreate says it is is use?? What am I missing here?

If the command above is exactly what you ran, I'd guess that it is
complaining because you are trying to create the new PV on *hdb* (whole
disk), but there is already a PV with that UUID present on *hdb1*
(partition).

Regards,
Bryn.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iD8DBQFHg7ss6YSQoMYUY94RAqEwAKCuoqxWBo7EYyae+z/whaa+zBF46wCg0zne
7C9kKnMr8lyk2CYSZ+0LkCQ=
=5qF0
-----END PGP SIGNATURE-----

Re: [linux-lvm] uuid already in use

[Thomas Krichel]

  Bryn M. Reeves writes

> If the command above is exactly what you ran, I'd guess that it is
> complaining because you are trying to create the new PV on *hdb* (whole
> disk), but there is already a PV with that UUID present on *hdb1*
> (partition).

  Ahh!

raneb:/etc/lvm/archive# pvcreate --uuid v3HXpi-d5QN-OGiW-VFBG-TNIY-qTun-bFhlVd  --restorefile vg1_00026.vg /dev/hdb1
  Warning: Volume group vg1 is not consistent
  Physical volume "/dev/hdb1" successfully created

  BTW, I never understood if I should use disks or
  partitions is lvms.

raneb:/etc/lvm/archive# pvcreate --uuid v3HXpi-d5QN-OGiW-VFBG-TNIY-qTun-bFhlVd  --restorefile vg1_00026.vg /dev/hdb1
  Warning: Volume group vg1 is not consistent
  Physical volume "/dev/hdb1" successfully created
raneb:/etc/lvm/archive# pvdisplay 
  --- Physical volume ---
  PV Name               /dev/hdd1
  VG Name               vg1
  PV Size               186.31 GB / not usable 3.69 MB
  Allocatable           yes 
  PE Size (KByte)       4096
  Total PE              47694
  Free PE               47694
  Allocated PE          0
  PV UUID               vy3MOc-47sl-zUal-nhdO-FFX3-ispO-Rl0h8p
   
  --- Physical volume ---
  PV Name               /dev/hdc
  VG Name               vg1
  PV Size               465.76 GB / not usable 4.02 MB
  Allocatable           yes 
  PE Size (KByte)       4096
  Total PE              119234
  Free PE               119234
  Allocated PE          0
  PV UUID               NxRIE1-ROxx-pfjJ-QHzh-7B80-F7wt-kRCmSK
   
  --- NEW Physical volume ---
  PV Name               /dev/hdb1
  VG Name               
  PV Size               186.31 GB
  Allocatable           NO
  PE Size (KByte)       0
  Total PE              0
  Free PE               0
  Allocated PE          0
  PV UUID               v3HXpi-d5QN-OGiW-VFBG-TNIY-qTun-bFhlVd
   
raneb:/etc/lvm/archive# vgdisplay 
  --- Volume group ---
  VG Name               vg1
  System ID             
  Format                lvm2
  Metadata Areas        2
  Metadata Sequence No  17
  VG Access             read/write
  VG Status             resizable
  MAX LV                0
  Cur LV                0
  Open LV               0
  Max PV                0
  Cur PV                2
  Act PV                2
  VG Size               652.06 GB
  PE Size               4.00 MB
  Total PE              166928
  Alloc PE / Size       0 / 0   
  Free  PE / Size       166928 / 652.06 GB
  VG UUID               Hm2mZH-jACj-gxQI-tbZM-H6pm-ovfr-TVgurC
   
raneb:/etc/lvm/archive# lvdisplay 
raneb:/etc/lvm/archive#

  I presume I have to restore the lv somehow. But this
  has got me a step foward.

  Big thank and cheers,

  Thomas Krichel                    http://openlib.org/home/krichel
                                RePEc:per:1965-06-05:thomas_krichel
                                               skype: thomaskrichel

Re: [linux-lvm] uuid already in use

[Thomas Krichel]

  Thomas Krichel writes
>    
> raneb:/etc/lvm/archive# vgdisplay 
>   --- Volume group ---
>   VG Name               vg1
>   System ID             
>   Format                lvm2
>   Metadata Areas        2
>   Metadata Sequence No  17
>   VG Access             read/write
>   VG Status             resizable
>   MAX LV                0
>   Cur LV                0
>   Open LV               0
>   Max PV                0
>   Cur PV                2
>   Act PV                2
>   VG Size               652.06 GB
>   PE Size               4.00 MB
>   Total PE              166928
>   Alloc PE / Size       0 / 0   
>   Free  PE / Size       166928 / 652.06 GB
>   VG UUID               Hm2mZH-jACj-gxQI-tbZM-H6pm-ovfr-TVgurC
>    
> raneb:/etc/lvm/archive# lvdisplay 
> raneb:/etc/lvm/archive#
> 
>   I presume I have to restore the lv somehow. But this
>   has got me a step foward.


  I could not see how I would restore the lv, 
  so I created a new one, with the same size and
  name as the previous one

raneb:~# lvcreate -n lv1 -L 652.06G vg1

  However, checking the volume fails

raneb:~# e2fsck /dev/mapper/vg1-lv1 
e2fsck 1.40.2 (12-Jul-2007)
Couldn't find ext2 superblock, trying backup blocks...
e2fsck: Bad magic number in super-block while trying to open /dev/mapper/vg1-lv1

The superblock could not be read or does not describe a correct ext2
filesystem.  If the device is valid and it really contains an ext2
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
    e2fsck -b 8193 <device>


  Alternative superblocks, gleaned from

raneb:~# mke2fs -n /dev/mapper/vg1-lv1 
mke2fs 1.40.2 (12-Jul-2007)
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
85475328 inodes, 170934272 blocks
8546713 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=0
5217 block groups
32768 blocks per group, 32768 fragments per group
16384 inodes per group
Superblock backups stored on blocks: 
        32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208, 
        4096000, 7962624, 11239424, 20480000, 23887872, 71663616, 78675968, 
        102400000


  also fail. I presume all superblocks where on disk /dev/hdb,
  and now that disk is gone, it is not possible to recover
  data from /dev/hdc and /dev/hdd, the two other disks 
  in the vg. Thus, a failure on the first disk spills onto
  the other disks because that disk hold vital information
  for all.

  Is that assessment correct?

  Note I am desparate to recover data here because I destroyed
  the backup through a mistake of mine 10 hours before disk
  /dev/hdb crashed. The data represents about 10 years of
  work of mine. 

  Conclusion: next time two backups.

  Cheers,

  Thomas Krichel                    http://openlib.org/home/krichel
                                RePEc:per:1965-06-05:thomas_krichel
                                               skype: thomaskrichel