- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - HP-UX
- >
- Taming of the Shrew (Ghost Disk)
Categories
Company
Local Language
Forums
Discussions
Forums
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
Discussions
Discussions
Discussions
Forums
Forums
Discussions
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
- BladeSystem Infrastructure and Application Solutions
- Appliance Servers
- Alpha Servers
- BackOffice Products
- Internet Products
- HPE 9000 and HPE e3000 Servers
- Networking
- Netservers
- Secure OS Software for Linux
- Server Management (Insight Manager 7)
- Windows Server 2003
- Operating System - Tru64 Unix
- ProLiant Deployment and Provisioning
- Linux-Based Community / Regional
- Microsoft System Center Integration
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Community
Resources
Forums
Blogs
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО08-03-2004 12:28 AM
тАО08-03-2004 12:28 AM
I lost a mirror root/boot disk from vg00 on an ole' D-Class.
This must have upset the the system so much that it paniced and could hardly be convinced to reboot in normal runlevel even when selecting alternate boot device, and checking things in maintenace mode with no VGs activatet (e.g. it didn't want to mount /stand).
Anyway, I brought the system back to - so somewhat impaired - normal operation.
Now I encounter the usual trouble derriving from descrepencies between kernel and lvmtab meta data.
So when I got back from the console to my PC where I had access to the HP-UX Software Recovery Cookbook (i.e. Chpt. 16 LVM) I did so as outlined in the "Removing A Ghost Disk" section.
All the first hand hacks didn't help.
I was only to lvreduce the mirrors by the PV key hack (described therein).
lvdisplay isn't reporting the failed PV to be in the LVs anymore.
# lvdisplay -v /dev/vg00/lvol[1-9] 2>/dev/null|grep c1t0d0
#
The errors I swept under the carpet by redirection above all relate to the ghost disk and are repeatedly like this:
lvdisplay: Warning: couldn't query physical volume "/dev/dsk/c1t0d0":
The specified path does not correspond to physical volume attached to
this volume group
lvdisplay: Warning: couldn't query all of the physical volumes.
As there are no more LEs occupied from c1t0d0 even for LVM, thanks to the successful lvreduce, now I should be able (according to theory) to run "vgreduce -f vg00".
But this doesn't work, instead
# vgreduce -f vg00
vgreduce: Couldn't query physical volume "/dev/dsk/c1t0d0":
The specified path does not correspond to physical volume attached to
this volume group
I also tried in vain to have a new lvmtab created through vgscan.
But it won't get rid of c1t0d0.
I supplied a new disk for the failed one (hotswappable) and tried things like
pvcreate -f -B /dev/rdsk/c1t0d0
or
vgcfgrestore -n vg00 /dev/rdsk/c1t0d0
But these don't change a thing.
Any other hacks I could try?
Rgds.
Ralph
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО08-03-2004 12:35 AM
тАО08-03-2004 12:35 AM
Re: Taming of the Shrew (Ghost Disk)
what does the following command says?
strings /etc/lvmtab
Once again, do a lvdisplay on each of the lvs in vg00 and check if any of them list the faulty disk.
Anil
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО08-03-2004 12:42 AM
тАО08-03-2004 12:42 AM
Re: Taming of the Shrew (Ghost Disk)
meanwhile I'm a step farther.
I had to completely mv or remove the /etc/lvmtab, and rerun vgscan.
This led to a new lvmtab with no c1t0d0 in vg00
# strings /etc/lvmtab|head
/dev/vg00
U8)A
/dev/dsk/c0t5d0
/dev/dsk/c0t8d0
/dev/dsk/c0t9d0
/dev/dsk/c2t0d0
/dev/vg01
/dev/dsk/c1t1d0
/dev/dsk/c2t1d0
/dev/vg02
However, I missed an important step which reconciles the mismatch between kernel and LVM, i.e.
# vgchange -a y vg00
Volume group "vg00" has been successfully changed.
No errors now
# vgdisplay vg00 >/dev/null
# vgdisplay -v vg00|grep PV\ Name
PV Name /dev/dsk/c0t5d0
PV Name /dev/dsk/c0t8d0
PV Name /dev/dsk/c0t9d0
PV Name /dev/dsk/c2t0d0
Now I have to reintegrate the PV again...
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО08-03-2004 12:49 AM
тАО08-03-2004 12:49 AM
Re: Taming of the Shrew (Ghost Disk)
I still fail to succeed with the vgcfgbackup of vg00 :-(
# vgcfgbackup vg00
vgcfgbackup: /etc/lvmtab is out of date with the running kernel:Kernel indicates
5 disks for "/dev/vg00"; /etc/lvmtab has 4 disks.
Cannot proceed with backup.
Ok, force the replacement disk in...
# pvcreate -f -B /dev/rdsk/c1t0d0
Physical volume "/dev/rdsk/c1t0d0" has been successfully created.
# vgextend vg00 /dev/dsk/c1t0d0
Volume group "vg00" has been successfully extended.
vgcfgbackup: /etc/lvmtab is out of date with the running kernel:Kernel indicates
6 disks for "/dev/vg00"; /etc/lvmtab has 5 disks.
Cannot proceed with backup.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО08-03-2004 12:53 AM
тАО08-03-2004 12:53 AM
Re: Taming of the Shrew (Ghost Disk)
Check pvs in vg and active pvs.
Any mismatch there???
Anil
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО08-03-2004 12:55 AM
тАО08-03-2004 12:55 AM
Re: Taming of the Shrew (Ghost Disk)
# strings /etc/lvmtab|head
/dev/vg00
U8)A
/dev/dsk/c0t5d0
/dev/dsk/c0t8d0
/dev/dsk/c0t9d0
/dev/dsk/c2t0d0
/dev/dsk/c1t0d0
/dev/vg01
/dev/dsk/c1t1d0
/dev/dsk/c2t1d0
# vgdisplay -v vg00|grep PV\ Name
PV Name /dev/dsk/c0t5d0
PV Name /dev/dsk/c0t8d0
PV Name /dev/dsk/c0t9d0
PV Name /dev/dsk/c2t0d0
PV Name /dev/dsk/c1t0d0
# vgcfgrestore -n vg00 /dev/rdsk/c1t0d0
vgcfgrestore: Mismatch between the backup file and the running kernel:
Kernel indicates 6 disks for "/dev/vg00"; /etc/lvmconf/vg00.conf indicates 5 dis
ks.
Cannot proceed with the restoration. Deactivate the Volume Group and try again.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО08-03-2004 12:56 AM
тАО08-03-2004 12:56 AM
Re: Taming of the Shrew (Ghost Disk)
# vgdisplay vg00|grep -e Cur\ PV -e Act\ PV
Cur PV 6
Act PV 5
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО08-03-2004 01:04 AM
тАО08-03-2004 01:04 AM
Re: Taming of the Shrew (Ghost Disk)
lvmtab and vgdisplay are in sync
# strings /etc/lvmtab|sed -n /vg00/,/vg01/p
/dev/vg00
U8)A
/dev/dsk/c0t5d0
/dev/dsk/c0t8d0
/dev/dsk/c0t9d0
/dev/dsk/c2t0d0
/dev/dsk/c1t0d0
/dev/vg01
# vgdisplay -v vg00|grep PV\ Name
PV Name /dev/dsk/c0t5d0
PV Name /dev/dsk/c0t8d0
PV Name /dev/dsk/c0t9d0
PV Name /dev/dsk/c2t0d0
PV Name /dev/dsk/c1t0d0
How can I force kernel structures into acknowledgement of new reality?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО08-03-2004 01:07 AM
тАО08-03-2004 01:07 AM
Re: Taming of the Shrew (Ghost Disk)
would a reboot resolve this mismatch?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО08-03-2004 01:32 AM
тАО08-03-2004 01:32 AM
Re: Taming of the Shrew (Ghost Disk)
Are you up to date on LVM patches??
Reboot
Anil