ありがとうございます。

grub rescue> search -f /boot/grub/grub.cfg

を実行してみましたが、

Unknown Command 'search'

と出てきてしまいます。


これまで（サーバーを立ち上げたのは８月ですが）は、LVM ＋ RAID1 の構成で問題なく起動できていました。
主にapacheサーバーとして使ってました。
LVMは、ボリュームグループVG0のなかにlv1,lv2,lv3の３っつのロジカルボリュームを作っており、
lv1をswap、lv2を/boot、lv3 を/ にセットしています。

ありがとうございます。

今更ながらですが、私のHDD構成は
１TB×２でソフトウェアLVM+RAID1、160GB、1TBでLVM という形で４玉搭載しています。
マシンはHPのproliant ML115G5,メモリは５Gです。
OSは、Ubuntu10.04LTSのサーバー版をインストールしてます。他のOSは入れておらず、サーバー用途です。

まず、Ubuntu10.04のLiveCDから起動して場所から/や/bootを開く件ですが、いただいたメールを読む前に既にやってました。
結果はNGです。
ただし、160GBのHDDだけは、開くことができます。UUIDもしっかり確認できます。想像するに、LiveCDは、LVMやRAIDに対応してないからだと思います。
以上のことから、LiveCDではなく、SystemRescueCD、alternateInstallCD、ServerCDあたりを使うのかなと思っています。
もともとシステムをインストールしたServerCDには、GRUBのインストールやらディスクの修復なりのメニューがあって、途中までやってみましたが、途中からパーティションを切るような画面に入っていくので怖くなって中断しました。

Google で検索すると、色々対応方法が出てきますが、自分の環境や症状にとって適切なのか勉強不足のため判断できないので、わかるまではあまり不用意なことはしないようにしています。取り返しがつかなくなると困るので。

error : no such disk.
grub rescue> ls とすると
(VG1-lv03) (VG1-lv02) (VG1-lv01) (md0) (hd0) (hd0,1) (hd1) (hd1,1) (hd2) (hd2,1) (hd3) (hd3,1)
と表示されます。


SystemRescueCDから起動して以下をやってみたところ、問題なく表示はできるのでファイルシステムは壊れていないのかと思っています。
root@sysresccd /root % fdisk -l,pvscan,vgscan,lvscan,pvdisplay,vgdisplay,lvdisplay

root@sysresccd /root % grep md0 /proc/mdstat をやってみたら
md0 : active raid1 sda1[0] sdb[1]
と表示されます。
raidも死んでないように見えます。

/etc/fstabの内容は今夜にでも調べて張り付けます。

問題は、LVM＋RAIDの環境でどうやったら安全・確実にGrubを再インストールできるのか　ということだと思っています。

今夜はどうやったらSystemRescueCDから起動して、どうやったらHDDをマウントできるのかやってみたいと思います。

引き続き、ご教示お願いします。

This is My /etc/fstab

# /etc/fstab: static file system information.
#
# Use 'blkid -o value -s UUID' to print the universally unique identifier
# for a device; this may be used with UUID= as a more robust way to name
# devices that works even if disks are added and removed. See fstab(5).
#
# <file system> <mount point>   <type>  <options>       <dump>  <pass>
proc            /proc           proc    nodev,noexec,nosuid 0       0
/dev/mapper/VG0-lv03 /               ext4    errors=remount-ro 1       1
/dev/mapper/VG0-lv01 /boot           ext4    defaults        1       2
/dev/mapper/VG0-lv02 none            swap    sw              0       0
/dev/sdc1 /home/hbirds/disk_sdc      ext4    defaults          0       0

tmpfs /tmp     tmpfs defaults,size=1024M 0 2
tmpfs /var/tmp tmpfs defaults,size=1024M 0 2

/home/hbirds  /export/hbirds  none   bind   0   0

#/dev/VG1/lv03 /disk_sdd       ext4    defaults        0       1
#/dev/VG1/lv01 /disk_sdd/boot  ext4    defaults        0       2
#/dev/VG1/lv02 none            swap    sw              0       0

SystemRescuCDを調べてみたらGRUBもしくはブートローダーについての情報を見つけられませんでした。
起動しているシステムの詳細も分からないのでライブCDを使用した方法を書きます。

ライブCDを起動して＃８で書かれた方法を実行して下さい。

% mkdir /VG0lv03
% vgscan
% vgchange -ay
% lvscan
% mount /dev/VG0/lv03 /VG0lv03

% はUbuntu（フォーラム）では #  に（root）になる操作を好ましくないとする（大きなミスを防ぐために）場合もあるので
sudo を使用します。
$ sudo mkdir /VG0lv3

と言う風に、% で始まる所は全て最初に　sudo を付けて実行して下さい。

(ご存知かも知れませんが遣り取りを減らすために書いておきます。)

確認をします。
$ ls /VG0lv3

これで上手くライブCDでも /VG0lv3 がマウント出来ていれば、今度はライブCDを起動したまま使用しているシステムを/VG0lv3と入れ替えます、極端に言うと現在起動できていない内蔵HDDでシステムが稼働している状態になりますので、GRUBをMBRへ再インストールすることで各種設定が再構築されるはずです。

その前に/boot を分けているのでマウントしなければいけません。
ちなみに　
$ ls /VG0lv3/boot

ととすると、通常あるはずのカーネルイメージやgrubフォルダが無いはずです。
＃８の方法で行くと（すみません、前記している様にLVMについて明るくないのでマウント方法はお任せです）。

先に　/VG0lv03 のマウントは済ませておいてください。

以下の３行がもう一度必用なのかどうか疑問ですが実行しておきましょう。
それと、この3行に管理者権限のsudo が必用かどうかも分からないのですが害は無いのでつけておきますね。
$ sudo vgscan
$ sudo vgchange -ay
$ sudo lvscan

次のsudo　は必須です。
$ sudo mount /dev/VG0/lv01 /VG0lv03/boot

$ ls /VG0lv3/boot
で確認して見て下さい。


準備が出来たのでchrootを実行します。

$ sudo mount --bind /sys /VG0lv03/sys
$ sudo mount --bind /dev /VG0lv03/dev
$ sudo mount --bind /proc /VG0lv03/proc
$ sudo chroot /VG0lv03 /bin/bash

$ が　# に変わります。

今、気付いたけどHDD自体の認識は/dev/sda で良いのかな？
# sudo fdisk -l
で確認して見て。。
で、続き。
# grub-install /dev/sda

もしかしたら、何かオプションを付けろと警告が出るかも知れませんね。
次に設定の更新をします。

# update-grub

chrootから抜けます。
# exit

アンマウント出来る物に関してはアンマウントします。
$ sudo umount -a

再起動して見て下さい。
ライブCDからのマウントで失敗しなければ良いのですが、失敗すれば上手くHDDをマウントできているSystemRescuCDで上手く行くかも知れません。
上手く生きます様に。

色々、Google  で検索して以下を試行

vi で　/boot/grub/device.map を以下のとおり作成
(hd0) /dev/sda
(hd0) /dev/sdb


# grub-install --root-directory=/boot /dev/sda
#　　　　　　　　　〃　　　　           /dev/sda1
#　　　　　　　　　”              =/ /dev/sda
#                       ”　　　　　 =/ /dev/sda1

# grub-install --rechecl --no-floppy --modules="mdraid raid" /dev/md0
#                               〃　　　　　　　　　　　　　　　　　　/dev/sda
#　　　　　　　　　　　　〃　　　　　　　　　　　　　　　　　　/dev/sda1

いずれもダメです。

いろいろ調べてみると、

grub-install --recheck --modules="pc ext2 chain part_msdos biosdisk raid mdraid lvm" --root-directory=/ '(md0)'

なのではないかなぁと思うのですが・・・未確認です(実際に実行する際にはsudo等お忘れなく)
# '(md0)'の部分は、/dev/md0 でも可のはず。
modulesにいろいろ指定しているので、core.imgのサイズがちょっと心配。
（シェルスクリプトが読めるなら、--debugオプションを活用すると良いかも。)

こんにちは。
　念のため、構成の確認なのですが・・・
HDDは今は４台。
HDD(1TB) /dev/sda(hd0)
HDD(1TB) /dev/sdb(hd1)
HDD(160GB) /dev/sdc(hd2)
HDD(1TB) /dev/sdd(hd3)

sdaとsdbは、それぞれ１つパーティションを切っていて(sda1,sdb1)、両方でSoftRAIDを用いてRAID1を構成していて、/dev/md0(md0)として認識されている。
md0は、それ１つでLVMを構成して、ボリューム(VG0)に、lv01を作成している？
sdcは普通にパーティションを１つ切ってそのまま利用？
sddは、１つパーティションを切っていて、それ１つでLVMを構成して、ボリューム(VG1)に、lv01,lv02,lv03を作成している。
そして、grub rescueからみると、md0に構築している(VG0)のみが見えていないっぽい。

という感じでしょうか？

RAIDの中('(md0)'として認識)も、LVMの中('(VG1-lv0?)'として認識)もみえているということは、moduleが足らないということは無さそうですね。

インストール直後は動いていたら、無理と言うことではないですよね、きっと・・・
# いろいろ検索しても、/bootをRAID1のみ(LVMにしない)にして、swapは通常パーティションにする(LVMにもRAIDにもしない)・・・という構成が多いようです。「LVM over RAID」「LVM on RAID」という言い回しが判って、やっと検索で情報がひっかかり始めました・・・

ありがとうございます。
LVMを使ったHDDがもう一つあるのが原因なんてこともあるのでしょうか。
実は、LVMの縮小はSystemRescueCDを使ってやりました。今にして思うとUbuntu Alternate CD を使うべきだったと思います。
この辺も原因かなと思ってます。
たぶん、どちらかが原因なのでしょう。


構成は
HDDは今は４台。
HDD(1TB) /dev/sda(hd0)
HDD(1TB) /dev/sdb(hd1)
HDD(160GB) /dev/sdc(hd2)
HDD(1TB) /dev/sdd(hd3)

sda と sdb でRAID1を構築（VG0-lv01:/boot , VG0-lv02:swap ,VG0-lv03:/）となっています。
sdc は　何もしてない1パーティション
sdd は　VG1-lv01:/boot , VG1-lv02:swap ,VG1-lv03:/ としてしまいましたが、/boot,swap,/ などを重複して作ってしまったために、rebootしたときに
おかしくなったのかもしれないですね。
/bootや/が二つもあったりすれば、どっちなのさ？？ということになりますよね。
だとすれば、sddを外してGrubのインストールをすれば修正できるかも。
・・・と書きながら思いつきました。馬鹿なことをしました。


以下は、４玉を接続したまま作業した結果です。
#9のhir0さんのコメントに加えて、
grub-mkdevicemap -n -m -　を実行すると
(hd0) /dev/sda
(hd1) /dev/sdb
(hd2) /deb/sdc
(hd3) /dev/sdd
と表示されます。
grub-install --recheck --modules="biosdisk part_msdos mdraid lvm" '(md0)'　を実行すると以下のエラーが出ます。
usr/sbin/grub-probe: error :no mapping exists for 'VG0-lv01'
usr/sbin/grub-probe: error :no mapping exists for 'VG0-lv01'
usr/sbin/grub-probe: error :cannot stat 'md0'
usr/sbin/grub-probe: error :no mapping exists for 'VG0-lv01'
You attempted a cross-disk install ,but the filesystem containing /boot/grub/dos not support UUIDs.

grub-install --recheck --modules="biosdisk part_msdos mdraid lvm" /dev/md0　を実行すると以下のエラーが出ます。
usr/sbin/grub-probe: error :no mapping exists for 'VG0-lv01'
usr/sbin/grub-probe: error :no mapping exists for 'VG0-lv01'
usr/sbin/grub-probe: error :no mapping exists for 'VG0-lv01'
You attempted a cross-disk install ,but the filesystem containing /boot/grub/dos not support UUIDs.

grub-mkdevicemap -n
にて、devicemapを保存後、「/boot/grub/device.map」を編集して保存後に上記のコマンドを試しても同じエラーが出ました。

明日は、sddを取り外して同じ事をやってみます。今日は疲れました。
きっと、これが原因！！であって欲しい・・・・・

Debian Bug report logs - #574863
grub-pc: grub-probe unable to find mapping for /boot on LVM with a snapshot LV
Problem Description:

Creation of a snapshot logical volume makes grup-pc complete skip the volume
group and makes the system not bootable. (/boot is in an LVM).  The problem is
in the code in lvm.c:grub_lvm_scan_device()

Whenever there is a snapshot logical volume, there is a special LV of
"type = snapshot" that is created to handle the snapshot operation.

This LV is hidden and is part of the LVM metadata but not listed in lvdisplay.
This special LV will not have the "stripe_count = xxx" property.  The actual
stripe_count will be same as the source LV 'origin = ' property.

However in the code any LV not having a stripe_count property is treated as a
fatal error and control jumps to lvs_segment_fail: and further fail4: and
ultimately skips the entire VG.  None of the LVs are populated in the vg_list
leading to grub-probe failure and further issues that completely breaks grub-pc
installation and updation.

というのを発見しました。

今回のトラブルのきっかけは、LVM on RAID1 で LV のsnapshotを作成するためにボリュームをフルに使っていた
VG0-LV03を縮小したことが背景にあります。
今もsnapshot は残っています。

当該snapshotを削除すれば、問題なくなるかもしれませんので、やってみます。

Solved！！
snapshot を削除したら正常にシステムが立ち上がりました。
皆さん、ありがとうございました。
これはGrub2のバグです。
snapshotは使い終わったら削除しておかなければ、カーネルアップデートの時に同じワナにはまります。
今回は大変勉強になりました。