- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - HP-UX
- >
- Re: Failed physical volume causing lvmtab weirdnes...
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
Forums
Discussions
Discussions
Discussions
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
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
05-01-2002 10:57 AM
05-01-2002 10:57 AM
I've got a K box running 11.0 with several disk arrays attached, with the disks arranged in several volume groups. One of the disks in the VG /dev/foo is in the process of failing. However, we didn't realize this was happening before our last software update, and we rebooted the machine (necessary step in our in-house update process).
Here's where the weirdness starts. I'm trying to figure out exactly which disk (one of 4) in the VG is the one that's dying, since you can't tell by looking at the drives themselves (no amber lights to be seen, and there's no logical correlation between the PVs and which VG they belong to -- they all kind of got put where they were needed at the moment (not my doing, the system's been in place far longer than I've been in the job)). Here's what the system tells me:
# vgdisplay -v /dev/foo
vgdisplay: Volume group "/dev/foo" does not exist in the "/etc/lvmtab" file
vgdisplay: Cannot display volume group "/dev/foo"
Okay, not an insurmountable problem. However, oddly enough, the other three LVs within the volume group are mounted and are accessible -- /dev/foo/lvx, /dev/foo/lvy, and /dev/foo/lvz are mounted where they need to be, and we've got programs using directories under the mount points. /dev/foo/lva is missing as it should be, since it's on the dying disk.
Following standard procedure, I back up /etc/lvmtab, delete the existing copy, and do a vgscan. And I seem to find the three disks which correspond to /dev/foo/lvx, /dev/foo/lvy, and /dev/foo/lvz. However...they're listed as being in /dev/vg01.
We don't have a /dev/vg01. And /dev/foo doesn't show up.
Using vgdisplay on /dev/vg01 lists the three PVs, all right. Using pvdisplay -v on those PVs shows that they're not associated with any LV (it gives "???" for the LV for each logical extent).
I can't use lvdisplay on /dev/foo/lvx -- it complains that /dev/foo isn't in lvmtab (which we knew). However, it's mounted, and nothing changed in /etc/fstab -- it's still listed as /dev/foo/lvx in there.
Any ideas on (1) what's going on, and (2) how I can fix it? Thanks.
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
05-01-2002 11:04 AM
05-01-2002 11:04 AM
Re: Failed physical volume causing lvmtab weirdness
What are the timestamps on /dev/vg01?
Regards,
Dave.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
05-01-2002 11:05 AM
05-01-2002 11:05 AM
Re: Failed physical volume causing lvmtab weirdness
One way to identify a failing disk is:
# dd if=/dev/rdsk/cXtYdz of=/dev/null
Look for errors...
Regards!
...JRF...
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
05-01-2002 11:11 AM
05-01-2002 11:11 AM
Re: Failed physical volume causing lvmtab weirdness
Regards,
Dave.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
05-01-2002 11:18 AM
05-01-2002 11:18 AM
SolutionSounds like David may be on to something here.
If the /dev/foo dir exists & /dev/vg01 doesn't.
Why don't you create a link from /dev/foo -> /dev/vg01?
vgscan looks at the info on the disk & doesn't care about the /dev dirs - so it's possible someone renamed the /dev/vg01 to /dev/foo.
This may get you past the current problem until you can take it down & fix it the way it's supposed to be.
HTH,
Jeff
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
05-01-2002 11:24 AM
05-01-2002 11:24 AM
Re: Failed physical volume causing lvmtab weirdness
Then see if the problem goes away. Before you do make sure you check for the lbolt
grep -i lbolt /var/adm/syslog/syslog.log
and
dmesg | grep -i lbolt
dmesg will be the same as syslog, but syslog had more history and timestamps.
HTH
Dave.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
05-01-2002 11:29 AM
05-01-2002 11:29 AM
Re: Failed physical volume causing lvmtab weirdness
If your mount points still show as /dev/foo/lvx than there has to be a directory structure under /dev as /dev/foo. I think renaming as suggested should do the work.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
05-01-2002 11:36 AM
05-01-2002 11:36 AM
Re: Failed physical volume causing lvmtab weirdness
This will work until I can do a real fix. Thanks again.