Re: Recover Partition Table - vgdisplay/vgscan fails

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



We tested out the below steps and they appeared to work.

First you need to remove the partition table on /dev/sd01. So issue the "fdisk /dev/sdo1" then delete the partition table and write out the changes.

A reboot is required since most of the lvm command fail due to the VDGA being inconsistent with what is in the kernel. All of the filesystems, that are in datavg, need to be commented out of /etc/fstab to avoid having the OS try and mount them on reboot. When the system comes back up all the volume groups, logical volumes and filesystem should be up except for datavg, and its logical volumes and file-systems. The LVM commands no longer will error out.

Once the system is back up a VGDA needs to be created on /dev/sdo1. "pvcreate -v /dev/sdo1"
Recover the old VGDA data, for /dev/sdo1. "vgcfgrestore -v -n datavg /dev/sdo1"

Scan for volume groups, "vgscan"
Activate the "newly" found datavg volume group, "vgchange -a y datavg"

At this point we were able to see datavg, all of the logical volumes, under datavg, and mount the filesystems. We un-commented the filesystems entries, in /etc/fstab, rebooted a few times and verified that the filesystem
were available on the reboot.

Len Smith


On 9/23/05, paul.stein@thomson.com <paul.stein@thomson.com > wrote:
Additional information explaining what caused the below errors:
 
+++++++++++++++ start +++++++++++++++++++++++++++++++++++++++++++++
 
<root@paxton:~># fdisk /dev/sdo1
Device contains neither a valid DOS partition table, nor Sun, SGI or OSF disklabel
Building a new DOS disklabel. Changes will remain in memory only,
until you decide to write them. After that, of course, the previous
content won't be recoverable.
 

The number of cylinders for this disk is set to 3541.
There is nothing wrong with that, but this is larger than 1024,
and could in certain setups cause problems with:
1) software that runs at boot time (e.g., old versions of LILO)
2) booting and partitioning software from other OSs
   (e.g., DOS FDISK, OS/2 FDISK)
Warning: invalid flag 0x0000 of partition table 4 will be corrected by w(rite)
 
Command (m for help): o
Building a new DOS disklabel. Changes will remain in memory only,
until you decide to write them. After that, of course, the previous
content won't be recoverable.
 

The number of cylinders for this disk is set to 3541.
There is nothing wrong with that, but this is larger than 1024,
and could in certain setups cause problems with:
1) software that runs at boot time (e.g., old versions of LILO)
2) booting and partitioning software from other OSs
   (e.g., DOS FDISK, OS/2 FDISK)
Warning: invalid flag 0x0000 of partition table 4 will be corrected by w(rite)
 
Command (m for help): m
Command action
   a   toggle a bootable flag
   b   edit bsd disklabel
   c   toggle the dos compatibility flag
   d   delete a partition
   l   list known partition types
   m   print this menu
   n   add a new partition
   o   create a new empty DOS partition table
   p   print the partition table
   q   quit without saving changes
   s   create a new empty Sun disklabel
   t   change a partition's system id
   u   change display/entry units
   v   verify the partition table
   w   write table to disk and exit
   x   extra functionality (experts only)
 
Command (m for help): n
Command action
   e   extended
   p   primary partition (1-4)
p
Partition number (1-4): 1
First cylinder (1-3541, default 1):
Using default value 1
Last cylinder or +size or +sizeM or +sizeK (1-3541, default 3541):
Using default value 3541
 
Command (m for help): t
Selected partition 1
Hex code (type L to list codes): 8e
Changed system type of partition 1 to 8e (Linux LVM)
 
Command (m for help): m
Command action
   a   toggle a bootable flag
   b   edit bsd disklabel
   c   toggle the dos compatibility flag
   d   delete a partition
   l   list known partition types
   m   print this menu
   n   add a new partition
   o   create a new empty DOS partition table
   p   print the partition table
   q   quit without saving changes
   s   create a new empty Sun disklabel
   t   change a partition's system id
   u   change display/entry units
   v   verify the partition table
   w   write table to disk and exit
   x   extra functionality (experts only)
 
Command (m for help): p
 
Disk /dev/sdo1: 29.1 GB, 29133909504 bytes
255 heads, 63 sectors/track, 3541 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
 
     Device Boot    Start       End    Blocks   Id  System
/dev/sdo1p1             1      3541  28443051   8e  Linux LVM
 
Command (m for help): v
62 unallocated sectors
 
Command (m for help): v
62 unallocated sectors
 
Command (m for help): w
The partition table has been altered!
 
Calling ioctl() to re-read partition table.
 
WARNING: Re-reading the partition table failed with error 16: Device or resource busy.
The kernel still uses the old table.
The new table will be used at the next reboot.
Syncing disks.
 
+++++++++++++++++++++++++++++ end ++++++++++++++++++++++++++++++++++++++

From: linux-lvm-bounces@redhat.com [mailto:linux-lvm-bounces@redhat.com] On Behalf Of Stein, Paul (TLR Corp)
Sent: Friday, September 23, 2005 11:20 AM
To: linux-lvm@redhat.com
Subject: Recover Partition Table - vgdisplay/vgscan fails

I inadvertantly blew away the partition table on /dev/sdo that was in use. While the system is still running and no errors have occured...yet, I need
to get the partition table restored and  be able to vgdisplay the datavg. Below is the sampling of error messages.
 
<root@paxton:/proc/lvm># vgdisplay datavg
vgdisplay -- ERROR: VGDA in kernel and lvmtab are NOT consistent; please run vgscan
<root@paxton:/proc/lvm># vgscan
vgscan -- reading all physical volumes (this may take a while...)
vgscan -- found active volume group "rootvg"
vgscan -- found active volume group "localvg"
vgscan -- found active volume group "datavg"
vgscan -- ERROR "vg_read_with_pv_and_lv(): current PV" can't get data of volume group "datavg" from physical volume(s)
vgscan -- "/etc/lvmtab" and "/etc/lvmtab.d" successfully created
vgscan -- WARNING: This program does not do a VGDA backup of your volume groups
 
 
 
Is it safe to clear VGDA using the "dd if=/dev/zero of=PhysicalVolume bs=512 count=1"  shown in the pvcreate man pages and the come back and
recreate the VGDA  using pvcreate, or use pvcreate outright not using the dd method? Or, is there a better method to get /dev/sdo back into the datavg
group while recreating the partition table?
 
Paul Stein
 

_______________________________________________
linux-lvm mailing list
linux-lvm@redhat.com
https://www.redhat.com/mailman/listinfo/linux-lvm
read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/


_______________________________________________
linux-lvm mailing list
linux-lvm@redhat.com
https://www.redhat.com/mailman/listinfo/linux-lvm
read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/

[Index of Archives]     [Gluster Users]     [Kernel Development]     [Linux Clusters]     [Device Mapper]     [Security]     [Bugtraq]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]

  Powered by Linux