uuid already in use
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-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Quoted 5 lines · Thomas Krichel
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-----
Bryn M. Reeves writes
Quoted 4 lines
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: thomaskrichelThomas Krichel writes
Quoted 23 lines
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
Quoted 5 lines
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