- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - HP-UX
- >
- Re: etc/lvmtab is out of date with the running of ...
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-29-2006 10:22 PM
тАО08-29-2006 10:22 PM
etc/lvmtab is out of date with the running of kernel
A volume group housing physical volumes /dev/dsk/c3t3d0 and /dev/dsk/c1t3d0 contain databases files and log files. I realized that the database was down and in an attempt to re-start it, I realized that one of the PV is not accessible (i.e /dev/dsk/c1t3d0).
Can I use pvchange to siwtch to the other disk or what do I do?
Thanks in advance
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО08-29-2006 10:25 PM
тАО08-29-2006 10:25 PM
Re: etc/lvmtab is out of date with the running of kernel
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО08-29-2006 10:56 PM
тАО08-29-2006 10:56 PM
Re: etc/lvmtab is out of date with the running of kernel
You need know if the system detect that disk.
ioscan -fnC disk
If the system list the disk you need to test him:
It's better if have a console near the server.
dd if=/dev/dsk/cxtydz of=/dev/null
(disk with problem)
If it's work the light must blink.
If nothing happend you can halt the system remove and put back the disk and boot the system again.
Joel
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО08-29-2006 11:21 PM
тАО08-29-2006 11:21 PM
Re: etc/lvmtab is out of date with the running of kernel
mv /etc/lvmtab /tmp
vgscan
vgdisplay -v
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО08-31-2006 03:29 AM
тАО08-31-2006 03:29 AM
Re: etc/lvmtab is out of date with the running of kernel
I'm not sure exactly your question. Did you receive an error stating that lvmtab is out of date with running kernel? Because having one drive fail shouldn't cause that to happen. A drive failure may however cause other problems.
Assuming the problem is that the drive is missing, you can do the following:
Providing the lvols in that vg are mirrored onto the two drives, then you can activate the vg in low quorum mode (or lack of quorum mode) with:
# vgchange -a y -l q /dev/vgXX
If the lvmtab is out of date with kernel, you can fix it by running vgscan as previously suggested, although that can cause other problems, especially if also have a failed drive at the time of the vgscan.
LVM likes checks and balances, and likes the vg information to match in each place that it's kept. It is kept on the drives, in the VGRA (actually two copies of this on each drive), also in /etc/lvmtab, and also in the kernel.
vgscan will only modify the info in the lvmtab and the kernel, but not the info in the vgra. So, if you were to vgscan to rebuild lvmtab, and if at the time of the vgscan one of the member drives in the vg was failed, it would build the lvmtab incorrectly, with only one disk. Likewise, it would update the lvm info in the kernel with only one disk. However the vgra, commonly refereed to as the the drive header info, would still know about that second disk. Then you would get a mismatch between active and current disks in a vgdisplay.
My suggestion would be to activate the vg with the "vgchange -l q" option, then reduce out the failed disk drive using vgreduce -f. That will correctly update lvmtab, kernel and vgra. Then, you can replace the failed drive, re-vgextend it back in, and re-mirror your lvols.
Hope that helps.
Andrew Jendricks
HP Critical Services Support