このようなAct PVとCur PVに不一致が生じる代表的なケースは以下のパターンが考えられます。
(詳しくは技術ツリー内を参照してください)
0.あるVGが4本で構成されているとします。
1.そのVG内のPVにハード障害が発生して物理的にアクセスできない状態となる。
2.上記の状態でvgscanを実行
3.ハード障害が発生したPVはvgscanによってアクセスできないため、vgscanによって新たに構成された/etc/lvmtabファイルにはそのPVの情報が反映されない。
4.このファイル(/etc/lvmtab)を利用して起動すると、カーネルはlvmtab内のPVのみをアクティブにしようとする。
5.Act PVは3本となるが実際のPV上のVGRAにはCur PV=4と記録されているためVGがアクティブになる際、ディスクから読み取ったVGRAの情報と矛盾する。
つまり
# strings /etc/lvmtab
では3本だが
# vgcfgrestore -f /etc/lvmconf/vg00.conf -l
だと4本になると思います。
この場合の復旧は(今回はvg00なのでLVMメンテナンスモードを利用する必要があります)
1.物理的に損傷を受けたディスクを交換
2.vgcfgrestoreにて交換したディスクへLVM構成情報復元
3./etc/lvmtabに矛盾があればvgexport,vgimportにて再作成
(->再インポートにてディスク上のLVM構成から/etc/lvmtabを復元。
ディスク上のLVM構成は正しいといえる場合に実行。)
4.この時点で/etc/lvmtab内のPVは4本に復元され、vgcfgresotre -f /etc/lvmconf/vg00.conf -lにて示される値と一致する(はず)。
となりますが、今回はvgcfgrestoreでの本数も3本なんですよねぇ。
これはつまりLVM構成情報としてもCur PV=3と記録されていることを示します。
今回の状態が発生した経緯がいまいち読めませんが、
>一つ思い当たるのは交換した際に
>c3t4d0を想定したが、ことなる値に
>なったので再度付け替え、
という現象の後、
make_recoveryにてバックアップを取得/リストアを行った。
ということでしょうか?
なんにせよ、すでに指摘されたとおり
# vgchange -f /dev/vg00
で解決できれば良いのですが。と、いうところです。
ちなみにもし
# vgcfgrestore -f /etc/lvmconf/vg00.conf.old -l
の出力結果が4本であるなら、価値のあるファイルなので
# vgchange -f /dev/vg00
をたたく前にこのファイルのバックアップを取っておくと良いかもしれません。
# cp /etc/lvmconf/vg00.conf.old /tmp/vg00.conf.old
