LVMを語らせていただけませんか？ その2

1 ：10/07/16 〜 最終レス ：12/01/24

LinuxのLVM(Logical Volume Manager)について情報交換するスレです。
■LVMの主な機能
ハードディスクのパーティションを物理デバイスでまたがって一つのパーティションにする
既にあるLVMパーティションを増設した物理デバイスを追加することができる
パーティションのスナップショットを作成する
など。
前スレ
LVMを語らせていただけませんか？
http://pc11.2ch.net/test/read.cgi/linux/1024122484/
関連スレ
RAID総合スレッド No.5
http://pc11.2ch.net/test/read.cgi/linux/1253111675/
ファイルシステム総合スレ その11
http://pc11.2ch.net/test/read.cgi/linux/1256639505/

2 ：

973 名前：login:Penguin []： 2010/06/30(水) 17:44:54 ID:FlM5EzIK (2)
lvremoveで削除した論理ボリュームを復活させたいんだけど、
もう無理？
975 名前：login:Penguin [sage]： 2010/06/30(水) 21:12:27 ID:aeXlIJ6f (2)
>>973
VGの構成情報は/etc/lvm/archive/の下に
自動でバックアップされている(LVMを操作するたび)
lvremoveしたあと、LVM関連の変更を行っていないのであれば、
/etc/lvm/archive/の下の一番新しいファイルが
lvremove直前のものだから、vgcfgrestoreで戻せるはず。
つうか、テストしたら普通に戻せた
1.バックアップの中身確認( "-l"オプション )
# vgcfgrestore -f /etc/lvm/archive/testvg_00006.vg -l testvg
File: /etc/lvm/archive/testvg_00006.vg
VG name: testvg
Description: Created *before* executing 'lvremove /dev/mapper/testvg-first'
Backup Time: Wed Jun 30 21:03:38 2010
2.実際の構成情報リストア
# vgcfgrestore -f /etc/lvm/archive/testvg_00006.vg testvg
Restored volume group testvg
3. LVのactivate
# vgchange -ay testvg

3 ：

978 名前：login:Penguin []： 2010/07/05(月) 05:05:53 ID:CEfOH2GT
973の方と同様の過ちをしたのですが、archiveにも残ってない場合は無理でしょうか？
983 名前：login:Penguin [sage]： 2010/07/05(月) 23:38:37 ID:vI6Vt5iG
>>978
ネタだと思うけど一応。
基本的には無理だけど、限定条件下なら可能
1. これまでlvcreate/lvextendでPV,PEを指定するオプションを使ったことが無い
2. LVの縮小や削除をしたことが無い(ミスった1回以外)
3. 削除後、LVMの操作をしていない
上記1-3を満たす場合、PEは先頭から順番に使用され(複数のPVがある場合1個目から)
かつ再利用されていないから、以下のコマンドで使用中のPEを確認し、
歯抜け部分を先頭から順番にくっつければOKのはず
# lvdisplay --maps
歯抜け部分を順番にくっつけるには、以下のいずれか
A. PE指定で、lvcreate→lvextend→lvextend→lvextend…
B. vgcfgbackupで現在のVG情報をテキストに落としたものに、削除してしまったLVの
　エントリを捏造して、vgcfgrestore
テストなら戻せるけど、実環境では2の条件が無理
(歯抜けPEをddで見て、元のLVを判別出来るなら何とかなるかもしんないけど)

4 ：

972 名前：login:Penguin [sage]： 2010/05/13(木) 21:59:39 ID:AnZS7vyd
linuxのLVM2だとLVの作成数の上限は無いとmanページに書いてあるんですけど、
試しに作ってみたら400個程しか作れませんでした。
100GのHDDに4MのLVを作ったので、空き容量はあるんですけど？
metadataが一杯みたいなエラーがでてました。
特別な作成方法があるのでしょうか？
977 名前：login:Penguin [sage]： 2010/06/30(水) 22:02:45 ID:aeXlIJ6f (2)
>>972
PV作成時にmetadataのサイズを指定する
# pvcreate --metadatasize 512m /dev/sda

5 ：

スナップショットとかどうでもいいから、
ボリューム管理＋RAIDみたいな感じになると最強だな。

6 ：

ホームサーバーのデータをミラーリングしたいと思ってLVM + RAID1の構成を作ろうと思っているのですが、
こちら(ttp://kimitakeblog.net/item/688)などで紹介されているようにLVM自体にもミラーリングの機能があるのでしょうか？
そうだとすると、LVMを使う前提ではRAIDとLVMをまぜて使うよりもLVM単体でミラーリングを行った方がいいですか？

7 ：

やめたほうがいいいです

8 ：

>>6
LVMを利用しようと思った理由は何?
RAID1を利用しようと思った理由は何?
LVM単体でミラーリングを利用しようと思った理由は何?
的確なアドバイスを求めるのなら手を抜かずに質問内容を書いたほうがいいよ。
答える義理もないが。

9 ：

それ聞いてもしょうがなくね。

10 ：

>>9
まあ暇だし。

11 ：

>>6
LVMは絶対に止めたほうがいい。

12 ：

それとAppleも絶対に止めたほうがいい

13 ：

SSDとHDD混在のVolume Groupを作ったとき、
アクセス頻度の高いPEをHDDからSSD側に動的に移動してくれるなんて機能はありませんかね？

14 ：

同じことやろうとしたけどなかった。
かろうじて近いのがMDの--write-mostly構成くらいだった。
たぶん改造するしかない。

15 ：

>>14
なるほど。
PEのアクセス頻度を調べて、移動させるぐらいなら何とか改造できるかな。
あと、もうひとつ考えたんだけど、LVMでミラーリング（PE単位でミラー）機能はあるけど、RAID5を実装させたい。
mdadmでRAID5とか組むとディスク単位になるから、リビルドとかにものすごい時間かかるんだよね。
これをPE単位でRAID5が組めれば、使用しているPE分だけのリビルドで復旧でき、時間短縮になるかなーと思った。

16 ：

>mdadmでRAID5とか組むとディスク単位
え？

17 ：

>>13
階層ストレージ管理ってやつ？
ググったらそれっぽいのあるけど
Online Hierarchical Storage Manager
ttp://ohsm.sourceforge.net/

18 ：

LVMのメリットの多くは HDDが活線挿抜できないと意味が無いので
LVMを使うメリットは無い

19 ：

また阿呆が来やがった

20 ：

いやまあ LVM mirror を試したときはそう思ったけどな。
そのあたりが整理されないと MD vs DM は永久に平行線。

21 ：

確かにHot-Add + online resize出来るとすげえ便利だ。
0. ディスクあふれやがった…
1. HDD追加してpvcraete -> vgextend
2. あふれた所をlvextend
3. ext4だったのでそのままresize2fs
4. 空きができた
なんて事が再起動なしであっさり出来てしまったので、感動のあまり書き残してみる。

22 ：

冗長化してないPVにVGなんて砂の上の城

23 ：

>>21
resize2fs サイズ指定しないでコマンド打つと、MAXまで広げてくれるんだよな。
うっかりやってしまって、後でCDブートで直すはめに。

24 ：

>>22
阿呆もうくんなよｗ

25 ：

LVの縮小ってのは、そもそもデータの保持は保証しておらず
作業前のデータのバックアップ、作業後の復元を前提にしているのですか？
umount
fsck
resize2fs
lvreduce
の順でやって何度やっても、ぶっ壊れるのですが。
実データ量はわずかで、縮小後もサイズには余裕があります。

26 ：

>>25
俺も何度もその作業やったけど壊れなかったよ
lvreduceの前後でlvdisplay -mでマップを表示してみたら？

27 ：

>>26
ありがとうございます。
そういうこともあるんですね。

28 ：

物理ドライブ /dev/sda と /dev/sdb とで作成し
/home として システムA にマウントさせていた論理ボリューム LV-A を、
システムB に物理的に接続し直し、同じようにマウントさせるには、
どのような手順を踏めば良いのでしょうか？

29 ：

まず服を脱ぎます

30 ：

>>28
http://tldp.org/HOWTO/LVM-HOWTO/recipemovevgtonewsys.html

31 ：

>>30 ありがとうございます。頑張ります。

32 ：

lvcreate -mNで作れるミラーって微妙だな

33 ：

/dev/sda1 (500GB) + /dev/sdb1 (500GB) = /dev/VolGroup00/LogVol01 (1TB)
という VG, LV を作って使っていたのですが、/dev/sda1 に不良が発生したらしく、
正しく読めなくなってしまいました。交換用に購入した HDD は単発で 2TB のもので、
こいつを /dev/sdc1 2TB として物理接続し、
ddrescue -r3 /dev/VolGroup00/LogVol01 /dev/sdc1 をやってみたところ、
数回のエラーは出たものの、どうやら無事 rescue できた様子。
なんですが、さてこれ、元の /dev/VolGroup00/LogVol01 とは、
どうやって完全に置き換えればいいんでしょうか。
いちおう、希望としては、2TB 単発ではなく、やはり2台の 2TB HDD を用いて、
4TB な LV を作りたいと思っているのですが。

34 ：

阿呆発見

35 ：

>>33
普通、ddrescueで吸い出さないといけないのは、LogVol01じゃなくて、
異常の発生した物理DISK(/dev/sda1)だよ
> ddrescue -r3 /dev/VolGroup00/LogVol01 /dev/sdc1 をやってみたところ、
> 数回のエラーは出たものの、どうやら無事 rescue できた様子。
"無事に"って本当？/dev/sdc1はマウント出来て、中身もちゃんとある？

36 ：

>>35 どうも。そうなんですか。
もう一回やってみます。ありがとうございます。

37 ：

ディスクを全部交換したいときってどうしたらいいの？

38 ：

>>37
1. 新しいDISKを既存のボリュームグループに追加(vgextend)
2. 古いDISK上の使用中の領域を新しいDISKに移動(pvmove)
3. 古いDISKをボリュームグループから削除(vgreduce)
古いDISKが無くなるまで繰り返し

39 ：

>>38　その古いDISKのうちのどれかに不良が発生してても基本的に同じ？

40 ：

>>36
もう一度試す前に/dev/sdc1の中身を調べてみろって
間違いなくデータは救出できてるから
もちろんマウント前にfsckは忘れずに

41 ：

>>39
1. ddrescueで不良DISKのデータ吸い出し
2. vgcfgrestore
3. vgchange -ay
4. fsck
>>38は、小さいDISKで作ったボリュームグループを、
データを載せたまま大きいDISKに移行したい、って場合を想定してたんだけど
(すべての新旧DISKを同時接続できるなら、普通にコピーした方が楽)
>>33,37,39 って同じ人？

42 ：

>>41 ども。 >>33 >>39 は同じ人です。 >>37 の人は違います。
>>40 の人は意地悪さんなのか、それとも親切さんなのでしょうか？

43 ：

>>42
>>40は親切さんだよ
>>35の物理ボリュームを吸うってのは一般的には正しいが、
もし物理DISKの異常が軽度だったら、LogVol01をddrescueで吸い出したものが
ファイルシステムのイメージとして有効な可能性もある
異常があると言いつつ、VGの活動化は出来ているみたいだから、
軽度の異常である可能性は十分ある
/dev/sdc1のfsck & mountを試みるべき

44 ：

なかなかまとまった時間が取れず、未だにきちんと通して試せてないです。
せっかく教えていただいてるのにどうもすみません。
間違えるとエラいことになるかと思うと、落ち着きと集中力とが必要で。。
もう一度情報を整理してみました。
1). 古いHDD2台を物理接続しただけでマウントしてない状態です。
# pvscan
PV /dev/sda1 VG VolGroup00 lvm2 [465.75 GB / 0 free]
PV /dev/sdb1 VG VolGroup00 lvm2 [465.75 GB / 64.00 MB free]
Total: 2 [931.50 GB] / in use: 2 [931.50 GB] / in no VG: 0 [0 ]
# vgscan
Reading all physical volumes. This may take a while...
Found volume group "VolGroup00" using metadata type lvm2
# lvscan
ACTIVE '/dev/VolGroup00/LogVol00' [931.44 GB] inherit
これが現状です。
これまでの経験から、エラーが出るのは /sda1 ではなく sdb1 だったので、
不良があるのはどうも /dev/sdb1 の方らしい。

45 ：

2). 一旦シャットダウンし、救出先のHDDを新たに追加物理接続して起動。やはりマウントしてない状態です。
これまでに ddrescue した /sdc が、/sda の代わりに認識されているようなので、
# vgchange -a n VolGroup00
# vgremove VolGroup00
# fdisk /dev/sdc
でパーティションを抹消、
# vgchange -a y VolGroup00
で古い方を再活性化した状態からの再スタートになります。
不安なので、上記 1). の状態に戻っているか一行ずつチェックし、完全に 1). 通りであることを確認。
3). ここで再度以下を試します。
# ddrescue -r3 --force /dev/VolGroup00/LogVol00 /dev/sdc /var/log/`date +%Y%m%d`_ddrescue.log
巨大サイズ故にかなり時間がかかることは経験済みなので、この状態で外出します。
まとまった時間が取れないのは、ボリュームがデカすぎて、時間を取ったつもりが、
それでも全然終わらんから、というのは冗談抜きに深刻な問題です。
戻って来るのは夕方すぎですが、はたしてその頃に終わっているかどうか。。。

46 ：

4). 帰ってきました。終わってました。上記 3).で取ったログは以下の内容でした。
# Rescue Logfile. Created by GNU ddrescue version 1.13
# Command line: ddrescue -r3 --force /dev/VolGroup00/LogVol00 /dev/sdc /var/log/20101021_ddrescue.log
# current_pos current_status
0xE438006E00 +
# pos size status
0x00000000 0xE438006000 +
0xE438006000 0x00001000 -
0xE438007000 0x4A3FF9000 +
以上。この + とか - とかになんか意味があるんでしょうが、分かりません。

47 ：

>>46
つ ttp://www.gnu.org/software/ddrescue/manual/ddrescue_manual.html#Logfile-Structure
リトライするなら/dev/sda1と/dev/sdb1を吸い上げて欲しかったけど、まぁいいや
とりあえず、/dev/sdcをfsck & mountだ

48 ：

>>47 へ？そうなんですか？どうもありがとうございます。
とりあえず現在、
# fsck /dev/sdc
中です。ちなみに /dev/sda1 と /dev/sdb1 とを吸い上げる場合、
それぞれ別の物理ドライブに吸い上げる方がいいのですか？それとも同一物理ドライブに？

49 ：

ところで fsck の結果をログに取るにはどうすれば？
# fsck /dev/sdc >`date +%Y%m%d`_fsck_sdc.log 2>&1
などとするんでしょうか？
関係ないですけど、この最後の 2>&1 ってのがワケ分らなくて、いつも忘れる。
あ、今以下の用に出ました。これは y するしかないと思いますがとりあえず。
# fsck /dev/sdc
fsck 1.35 (28-Feb-2004)
e2fsck 1.35 (28-Feb-2004)
/dev/sdc contains a file system with errors, check forced.
Pass 1: Checking inodes, blocks, and sizes
Inode 119652481 is in use, but has dtime set. Fix<y>?
この時点で40分以上経過。
以下、同じ待機状態が連続すると予測。
やっぱ -y でやるしかないのかな。

50 ：

>>49
fsck -y /dev/sdx
cat /var/log/fsck

51 ：

やはりあまりに辛気くさいので ctr + c で中止。以下をやり直しとります。
# fsck -y /dev/sdc > /var/log/`date +%Y%m%d`_fsck_sdc.log 2>&1
09:20:56 にスタート。待機。

52 ：

>>50 入れ違った。 orz　　でもありがとうございます。そこにログはあるんですね。

53 ：

>>51 から約1時間半経ちますが、まだ延々 fsck やっとります。
ところで mount はどこに？
様子見なので /mnt/test など「どっか適当に」かな？
でもこれ、論理ボリュームを写したものなので、
こいつ自体もやっぱ論理ボリュームのはずだと思うんですが、違うのかな。
とすると、いきなり
# mount -t ext3 /dev/sdc1 /mnt/test
とやったところで「そんなデバイスはないぜ」と言われる気がするのですが。
やっぱ pvscan vgscan lvscan なんですかね。

54 ：

好きにしろや

55 ：

fsck いま終わった。どきどきする。恐い。

56 ：

>>48
> 中です。ちなみに /dev/sda1 と /dev/sdb1 とを吸い上げる場合、
> それぞれ別の物理ドライブに吸い上げる方がいいのですか？それとも同一物理ドライブに？
質問の意図が分からん
俺だったら、/dev/sda1と/dev/sdb1のイメージファイルを新しい1個のDISK上に吸い上げる(容量があれば)
んで、次の作業を始める前に、イメージファイルをさらに別のDISKにバックアップしておく
>>53
> 様子見なので /mnt/test など「どっか適当に」かな？
うん。適当で
> でもこれ、論理ボリュームを写したものなので、
> こいつ自体もやっぱ論理ボリュームのはずだと思うんですが、違うのかな。
違うよ。
デバイスの種類としては、DISKのパーティション(/dev/sda1, /dev/sdb1等)と同じ
論理ボリューム＝仮想的なDISKパーティション

57 ：

>>56
いつも丁寧なアドバイスをどうもありがとうございます / ました。
>>56 のリプライをいただいたのと入れ違い？になってしまったのですが、
>>55 のあと「失敗したら最初からやり直しゃいいや」と思い、
エイヤ！でいろいろやってみました。
結論から言いますと、すべてのデータを救出できました。
まず、>>47 のアドバイスをいただいて、>>48 にトライする段階で、
そもそも /dev/sdc1 が無いことに軽い衝撃を受けていました。
物理ドライブを丸ごと全体使っても、一つのパーティションとして、
つまり /dev/sdc1 として認識されるものだと思っていました。← アホ

58 ：

それで # fdisk /dev/sdc でパーティション構成を見ても何もなくて、
ものすごいショックで、もう一回一からやり直そうかと考えたのですが、
もう一度冷静に >>47 を読み直して、/dev/sdc1 とは書かれておらず、
あくまで /dev/sdc と書いておられたことを確認し、
半信半疑で # fsck -y /dev/sdc をやったのが >>48 と >>51 です。
fsck のログを見たら、JPG ファイルが一つと mp3 ファイルが一つ、
なんかよく分りませんが、具体名を上げて、ログに記録されていました。
でもそれらの不良も fixed されたような感じだったので、かつ、
/dev/sdc1 ではなくて /dev/sdc であることを知ったので、
# mount -t ext3 /dev/sdc /mnt/2TBtest でマウントし、
ログに記録されていたファイルをチェックしてみたところ、問題なし。
というわけで、一つもファイルを落とさずに、すべて復活させることができました。
何も分ってない私に最後まで辛抱強く付き合って下さった >>35 >>40 >>41 >>43 >>47 >>50 >>56 さん。
どうもありがとうございました。心から感謝いたしまする！

59 ：

おめ

60 ：

こ

61 ：

RHEL6.1でLVMミラーがようやくまともに使えるようになりそうだ。
ミラーログのミラーができるようになっている。

62 ：

今までのおかしな仕様がやっと変更されるのか

63 ：

スナップショットおしえて

64 ：

lvm mirror のログ置き場で /dev/loop0 といった仮想ディスクもどきを使って
起動時の同期を避けれるんだが、なにか論理的な欠点ありそう？
lvm のディスク ID とか等で loop デバイスの番号等を変えちゃ駄目とか。。。

65 ：

>>64
> 起動時の同期
んなアホな、と思って仮想マシンで試してみたけど、
案の定、起動時の同期なんか起きない
同期が完了していない状態で再起動しているだけじゃないの？
ついでに色々テストしてみたけど、正直微妙
将来的にはZFSのDISK管理部分みたいなものを目指しているのか…？

66 ：

lvm mirror はソースコードか操作説明ぐらいしかないので
色々テストとは興味深いです。
微妙ですか。最近は、lvm には mdadm みたいな障害告知が無いので
lvm mirror はあまり意味ないかなーと思い始めてます。
ディスク追加とかボリュームサイズ変更の柔軟性は便利そうなので
将来的な期待ですか。
もっとも ZFS みたいに突発電源オフでもデータ不整合は無い
（ディスクは物理的に壊れるかも知れないが。。。）
というわけにはいかないでしょうね。
ただ lvm mirror の作業ログ自体は corelog でないならきちんとファイルで
恒久化されるので、それで問題無いというログなら同期は完了済みとして、
corelog と違い同期不要なのでは、と期待してます。根拠無いですが。。。
ソース読めば明確なんでしょうけど。。。

67 ：

LVM以外で、複数のHDDをひとつに見せる方法はありますか？

68 ：

RAID

69 ：

>>67
アロンアルファ
ひとつにくっつけたらひとつに見えるよ。

70 ：

>>67
dmとmdを直接使うとか。

71 ：

>>69
おもろい。笑いすぎて腸捻転になった。
死にそう。助けて。

72 ：

心がすさんでるな。

73 ：

カーネル2.421なんですけど
PEをどんな大きさにしても、LVサイズの上限が2TB以上に
ならないんですけど、これは仕様ですかね
PEを4MBとかにするとちゃんとLVの上限が256Gになるんで
小さい方にはちゃんと計算されてるんですが・・・

74 ：

2.4はブロックデバイスが2TBまで
パッチはあるが2.6にしたほうが幸せになれるだろう

75 ：

>>74
＞2.4はブロックデバイスが2TBまで
わーお。
２TBの壁を越えるためにLVMを考えてたんだけど
LVMで出来るのもよく考えればブロックデバイスだわな。
おれはなんて馬鹿なんだ・・・

76 ：

CentOS5.5でLVM作ってみたんですが、Snapshot領域がマウントできません。
ファイルシステムを指定汁、って出たので、LVと同じext3を指定したら
そんなファイルシステムじゃねえよとかエラーが出ます…

77 ：

lvmってHDDがクラッシュするとどうなるの？
死んだHDDとLVがまたがっている場合、
生きてるHDDの方のデータはちゃんと取り出せるの？

78 ：

RAID 0と似たようなものと考えてくれ

79 ：

どちらかというとJBOD

80 ：

>>77
ブロックデバイスレベルではね。
その上に載ってるファイルシステムが、そういうエラー状態で
どういう挙動するかは、ファイルシステム次第。

81 ：

>>77
この前1台が死んだ。
新しいドライブつなげてpvmoveでエクステント移動して、
xfs_repairで救出したら・・・ある程度は救出できた（LVM全体の60%ぐらい）
残ったHDDのデータがファイルシステム上完全である保証はないから
まぁ仕方ないかなという感じ
クラッシュ怖いならバックアップしろって感じだな
地震多いしRAID程度じゃ焼け石に水だ

82 ：

>>77
前スレを読むといい

83 ：

1台から不良セクタが出始めたのでそのHDDを取り外すために新しく追加用HDDをつなげてPVを作ったものの、間違えてlvextend 100%VG とやっちまったので、
Free PEなくなってしまった。それ以降書き込みはしていないので新しくつなげたHDDにデータはないはずなんだけど、強制的に新HDDを取り外す方法はないかな？

84 ：

>>83
LiveCDで起動→vgcfgrestoreで以前の状態に戻す
(lvextendの直前 or vgextendの直前)
lvextendしただけなら問題ないはず
ファイルシステム拡張済みの場合はfsckする

85 ：

>>84
今VGから1回取り外したPVを再作成して取り外したいPVから pvmove 中…
本当助かりました！ありがとう！
自分の知識じゃ思いつかなかったもんで、もう1台外からつなげて移動させようとHDD買ったのが届いてしまった…

86 ：

LVM2で質問です。
64bit kernel 3.1.x + lvm2 な環境です。
VGこさえるときのPEサイズで、1LVの最大容量が決まる（65536PEまで）
みたいな記述があちこちにあるので、試しに
vgcreate -s1k VG /dev/sdc1
とPEサイズを1kiBにして、その上に1TiBのLV作れちゃったんだよね。
そういう仕様について、適切な記述があるとこを教えて欲しいのですが。。。
ちなみに目的は、30TiBぐらいまで拡張可能なLVを運用することです。
ソース嫁は、ちょっと勘弁してくだしあ。

87 ：

自己レスです。
LVM2では、事実上PEサイズの上限は無いみたいですね。1KiB〜みたいな。
PEサイズを小さくしてPE数が多くなると、ツールのパフォーマンスは下がるけどI/Oには関係ないと。
ベストバランスはどのへんなんだろう。。。

88 ：

>>86
LVあたりのPE数の制限はLVM1だけだと思う
その環境だとLV1つあたり最大8EB
ttp://tldp.org/HOWTO/html_single/LVM-HOWTO/#AEN407
PEサイズはファイルシステム拡張時の最小単位ということを意識しつつ出来るだけ大きい値
30TBがゴールなら1GBぐらいでいいんじゃないの
というか、小さいPEサイズで細かく拡張とかしてたら30TB使い切る前にmetadataが溢れるような気がする

89 ：

すみません、質問させて下さい。
CentOS 5.3 64bit でLVMを使用しています。
カーネルパニックを起こしていたので再起動したところ、
正常に立ち上がらなくなってしまいました。
以下、起動途中に出るエラーメッセージです。
--------------------------------------------------------------------------------------------
Red Hat nash version 5.1.19.6 starting
Reading all physical volumes. This may take a while...
Couldn't find device with uuid 'kDdyoQ-0P5f-eZkg-qt54-KMQt-Krxk-JuWVjY'.
Found volume group "VolGroup00" using metadata type lvm2
Couldn't find device with uuid 'kDdyoQ-0P5f-eZkg-qt54-KMQt-Krxk-JuWVjY'.
Couldn't find device with uuid 'kDdyoQ-0P5f-eZkg-qt54-KMQt-Krxk-JuWVjY'.
Refusing activation of partial LV LogVol00. Use --partial to override.
Couldn't find device with uuid 'kDdyoQ-0P5f-eZkg-qt54-KMQt-Krxk-JuWVjY'.
Refusing activation of partial LV LogVol00. Use --partial to override.
0 logical volume(s) in volume group "VolGroup00" now active
Unable to access resume device (/dev/VolGroup00/LogVol01)
mount: could not find filesystem '/dev/root'
setuproot: moving /dev failed: No such file or directory
setuproot: error mounting /proc: No such file or directory
setuproot: error mounting /sys: No such file or directory
switchroot: mount failed: No such file or directory
Kernel panic - not syncing: Attempted to kill init!
--------------------------------------------------------------------------------------------
RAIDを組んだりもせず、1TBx2個をLinuxインストール時にLVMで2TBとし
そこにCentOSを入れていたのですがもうアウトでしょうか。
もし復旧できそうならアドバイスお願いします。

90 ：12/01/24

>>89
多分、DISKの1つが見えないからボリュームグループを活動化出来ない状態
1.蓋開けてケーブルが抜けてないか確認
2.LiveCDで起動してDISKを認識するかどうか確認
→１個しかDISKが見えない場合＝片方死んでる。
生きてる方のDISKのデータを部分的にでも救出したい場合(復旧は無理)、
LiveCD上からボリュームグループを無理やり活動化→論理ボリュームに対しfsck
# vgchange --partial -a y
# fsck -y /dev/VolGroup00/LogVol01
2つのDISKを跨っていたファイルシステムは激しく壊れるから期待しないほうがいい