Help: rootvg is whacked on AIX 3.2.5 box
David Cowley
years of neglect. I was called in after an external SCSI disk on the
machine died. I was able to boot after removing that dead disk, but
there's other problems afoot:
Rootvg won't vary on. I can't use lsvg to look at rootvg, and I don't
appear to have any swap volumes. Yet the machine boots, and heck, I can
even get Oracle to start and bring up a database.
All the usual logical volumes that are normally part of rootvg appear to
be on hdisk1. There is no hdisk0 that I can detect.
lspv says:
# lspv
hdisk1 000002840005684c None
inspire0 00000284f80ee747 None
hdisk2 00000284cc030bab None
hdisk5 00000284ac6c09e0 oraclevg
lsvg says:
# lsvg
rootvg
dbasevg
dbase
oraclevg
And furthermore:
# lsvg rootvg
0516-010 lsvg: Volume group must be varied on; use varyonvg command.
# varyonvg rootvg
PV Status: 000002840001e214 PVNOTFND
0516-013 varyonvg: The volume group cannot be varied on because
there are no good copies of the descriptor area.
I've gone into the ODM, and found the following:
# odmget -q name=rootvg CuAt
CuAt:
name = "rootvg"
attribute = "vgserial_id"
value = "00000284f9e2c92c"
type = "R"
generic = "D"
rep = "n"
nls_index = 637
CuAt:
name = "rootvg"
attribute = "pv"
value = "000002840001e2140000000000000000"
type = "R"
generic = ""
rep = "sl"
nls_index = 0
So it appears to me that the ODM entry for rootvg has an old PV's ID
number in it (maybe 2840001e214 is the missing hdisk0?).
I think I can restore rootvg to its senses by updating the ODM to have
hdisk1's PV ID in it. Is that correct?
I've looked at the synclvodm man pages, and am unsure what it's going to
try to do in this situation. Does it change the ODM, the VGDA, or both?
I could update the ODM record manually by doing an odmget/edit/odmadd
followed by a savebase, but is that really necessary? Am I up the right
tree? Any guidance would be greatly appreciated.
Thanks,
- Dave Cowley
Rob Kouwenberg
> All the usual logical volumes that are normally part of rootvg appear to
> be on hdisk1. There is no hdisk0 that I can detect.
IMHO a 'synclvodm' is in place. Please gather more opinions on this
before trying this out, no guarantees !
John Newman
You are definately suffering from an old 3.2.5 problem with the ODM
being out of sync with your system.
You are right in that you need to clobber the entries in the ODM. There
used to be a IBM FAX called fixrootvg, this should still be
available. It basically whilst the system is online does an export of
the root volume group, followed by a import of the root volume group,
and because all the information about the VG is held in the VGDA/VGSA
then the ODM can be rebuilt from this data. This is the best way to fix
the problem.
Below is a copy of the fax, but it is related to 4.3, but I see no
reason why it cannot be used here.
Later, John.
Rebuilding a Volume Group's Customized Device Database [rvg.4x.krn]
Rebuilding a Volume Group's Customized Device Database
------------------------------------------------------------------------
-------
Contents
About This Document
Related Documentation
Problem Determination
Before Using the Script
About the Script
The Script
------------------------------------------------------------------------
-------
About This Document
Run the script in this document when the ODM (Object Data Manager)
entries for
the root volume group are corrupted. For non-rootvg volume groups, all
that
should be required is to varyoff the volume group, export the volume
group, and
re-import it. If the volume group cannot be varied for some reason, the
script
may be modified for volume groups other than rootvg. (See the About the
Script
section in this document.) This document applies to all levels of AIX
Version
4.x.
"Related Documentation"
For more in-depth coverage of this subject, the following IBM
publications are
recommended:
o AIX Version 4.3 System Management Guide: Operating System and
Devices
(SC23-2525)
o AIX Version 4.3 Commands Reference, (references for varyonvg,
varyoffvg,
exportvg, importvg, lsvg, and synclvodm)
IBM documentation can also be found online at the following url:
http://www.rs6000.ibm.com/resource
------------------------------------------------------------------------
-------
Problem Determination
When the ODM entries for a volume group are corrupted, you may notice
one of
the following symptoms:
o The lsvg, lslv or lspv commands fail.
o You cannot change the size of file systems.
o The system cannot find volume groups or device IDs.
o The output of the following command contains question marks (?s) in
some
fields, or some fields are blank:
lsvg -l VGname
------------------------------------------------------------------------
-------
Before Using the Script
Before using the following script, you may wish to save the current
version of
your /etc/objrepos/Cu* files, in case you want to go back to that
version at
some time. This is optional.
mkdir /etc/objrepos/Cu.bak
cp /etc/objrepos/Cu* /etc/objrepos/Cu.bak
------------------------------------------------------------------------
-------
About the Script
1. This script contains only a few provisions for handling error
conditions
because it is designed to minimize typing mistakes.
2. The PV (physical volume) and VG (volume group) variables on the
first two
lines of the script are defaulted for the root volume group
(rootvg). The
PV is set to /dev/ipldevice, which is a synonym for one of the
physical
volumes that is a member of the rootvg volume group.
If you wish to run this script for a volume group other than the
rootvg,
you must change the VG variable to match the volume group you wish
to fix,
and change the PV variable to match any one of the physical
volumes
(/dev/hdisk#) that is a member of that volume group. To determine
to which
VG a PV belongs, enter the command:
lsvg `lqueryvg -vp hdisk# ` | grep GROUP
Please note that grave (back tic) characters are used in the
preceding
command.
3. It is not necessary to reboot after running this script.
4. If this script is being used to clean up a rootvg AND the rootvg
is
mirrored, the user must run the bosboot command to the disks that
make up
the bootable rootvg. Note that there is no need to reboot after
the
bosboot.
5. Note that this script calls the synclvodm command, which will
change the
permissions on all logical volume device files to 660, and their
ownership
to root:system. This may cause problems with database applications
that
use raw logical volumes whose device files have had their
ownership or
permissions changed. Running this script may thus require you to
shut down
applications that operate in this manner, and change the
permissions and
ownership on those files when finished.
------------------------------------------------------------------------
-------
The Script
NOTES:
1. Run the following script while in Normal mode and logged in as
root.
2. Depending on how you are viewing this document, some characters in
the
following code may appear incorrectly. If the characters in the
following
list do not match their descriptions, be sure to change them in
the code.
[ left bracket
] right bracket
3. Please note that page headers and footers may appear in the
following
code. They should be removed before the code is used. Also,
revision bars
(vertical bars in the left margin which mark changes in the
document) may
appear to the left of the code and should be removed before the
code is
used.
PV=/dev/ipldevice
VG=rootvg
lqueryvg -Lp $PV | awk '{ print $2 }' | while read LVname; do
odmdelete -q "name = $LVname" -o CuAt
odmdelete -q "name = $LVname" -o CuDv
odmdelete -q "value3 = $LVname" -o CuDvDr
done
odmdelete -q "name = $VG" -o CuAt
odmdelete -q "parent = $VG" -o CuDv
odmdelete -q "name = $VG" -o CuDv
odmdelete -q "name = $VG" -o CuDep
odmdelete -q "dependency = $VG" -o CuDep
if [ "$VG" = rootvg ]
then
odmdelete -q "value1 = 10" -o CuDvDr
else
odmdelete -q "value1 = $VG" -o CuDvDr
fi
odmdelete -q "value3 = $VG" -o CuDvDr
importvg -y $VG $PV # ignore lvaryoffvg errors
varyonvg $VG
synclvodm -v $VG
savebase
Techdocs Ref:90605223414650 4FAX Ref:none
Sent via Deja.com http://www.deja.com/
Before you buy.