2012-03-31 VirtualBox 4.1.2、6ディスクデバイスでのDebianWheezyデイリービルド。
これまでに再現するための私の手順:
/と/ bootの両方がこのスタックに含まれます。このセットアップのファイルシステムとしてEXT4を選択しました。
Mdraid、ボリュームグループ、LVM論理ボリューム(すべてのレベルで適切に名前が付けられている)を表示できるGRUB2レスキューコンソールまで到達できますが、それらのファイルシステムの内容を見つけることができず、起動できませんそれらから。
ドキュメントからわかる限り、そこに出荷されているGRUB2のバージョンは、これらすべてを適切に処理する必要があります。
http://packages.debian.org/wheezy/grub-pc (執筆時点では1.99-17)
生成されたgrub.cfgファイルに従って、ext2、raid、raid6rec、dosmbr(これはディスクごとに1回モジュールのリストにあります)およびlvmモジュールをロードしています。また、生成されたgrub.cfgファイルに2回ロードされるモジュールのリストを定義しており、簡単なグーグルによれば、これは標準であり、GRUB2では問題ないようです。
GRUB2でファイルシステムのコンテンツを実際に読み取ってシステムを起動できるようにすることで、さらに先に進むにはどうすればよいですか?
ここでの機能の仮定の何が間違っていますか?
編集(2012-04-01)生成されたgrub.cfg:
最初に/ usr論理ボリュームがルートになり、それが失敗の原因である可能性がありますか? grub-mkconfigのバグ?または、/および/ bootの前に/ usrからのものにアクセスすることになっていますか?/bootはオンです/私にとっては-個別のブート論理ボリュームはありません。
結局のところ、それは Grub2のバグ/劣化したソフトウェアRAIDアレイの問題 でした。
Grub2 1.9xには、劣化したアレイからの起動に問題があります。システムをレスキューモードで起動し、レイドを自動的に回復させることで、問題の元のセットアップの問題が修正されました。
ちなみに、セットアップはFedora 17、Arch(安定)およびGentoo(Portage経由の安定+最新のgrub2 bzr)で箱から出してすぐに機能します(現時点:2012-06-26):Grub22.0 +で問題が修正されました。 Wheezyのフリーズが間もなく発生するので、2.0にジャンプするか、修正をバックポートすることで問題が解決されることを完全に望んでいます。
私にとって、これはまだDebian 6、7に影響します。 Ubuntu 8.04、10.04、12.04。
シングルユーザーモードのリカバリセットアップでレイド同期を許可することは、ホームシステムにとって許容できる回避策ですが、本番サーバー(小規模なオフィスファイルサーバーでも)を再起動するための潜在的な余分な問題があると、考え直します。
非常に良い投稿です。これは、DebianWheezyにLVM-over-RAIDをインストールするのにかなり役立ちました。これが私が問題を克服するために取ったステップです。
Grub2をV2 +に更新します
これらの行を/etc/apt/sources.listに追加します
deb http://http.debian.net/debian unstable main
deb-src http://http.debian.net/debian unstable main
apt-get update
apt-get install grub2
おそらく、単一のパーティションを大きくしすぎて、GRUB2をインストールするのに十分なスペースを残しておらず、LVMスペースの一部が上書きされている可能性があります。ロングショットの何か。今回は単一のディスクを使用し(RAIDをスキップ)、以前とまったく同じように単一のパーティションを作成してから残りの部分を作成することを除いて、問題を再現するための手順を試してください。私が正しければ、あなたは同じ振る舞いをするはずです。
更新:したがって、この答えは間違っています。 GRUB2のマニュアルを調べていたところ、次のようになっていることがわかりました section
代わりに、レスキューシェルしか取得できない場合、これは通常、GRUBが何らかの理由で「通常の」モジュールのロードに失敗したことを意味します。これを一時的に回避できる可能性があります。たとえば、失敗の理由が「プレフィックス」が間違っている(おそらく間違ったデバイスを参照している、または/ boot/grubへのパスがデバイスに対して正しく作成されていない)場合は、これを修正して通常モードに入ることができます手動:
# Inspect the current prefix (and other preset variables): set # Find out which devices are available: ls # Set to the correct value, which might be something like this: set prefix=(hd0,1)/grub set root=(hd0,1) insmod normal normal
ただし、レスキューシェルに問題が残っている場合は、GRUBが正しくインストールされていない可能性があります。grub-installデバイスを使用して適切に再インストールする方が便利な場合があります(grub-の呼び出しを参照)。これを行うとき、覚えておくべきことがいくつかあります。
- オペレーティングシステムでのドライブの順序は、ファームウェアで使用されているブートドライブの順序と同じではない場合があります。最初のハードドライブ(「/ dev/sda」など)がファームウェアの起動元であると想定しないでください。 device.map(デバイスマップを参照)を使用してこれをオーバーライドできますが、通常はUUIDまたはファイルシステムラベルを使用し、ドライブの順序に完全に依存しないようにすることをお勧めします。
- 少なくともBIOSシステムでは、grub-installにGRUBをパーティションにインストールするように指示したが、GRUBはすでにマスターブートレコードにインストールされている場合、 GRUBパーティションへのインストールは無視されます。
- 可能であれば、パーティションへのGRUBのインストールは避けるのが一般的に最善です(BIOSなどのGRUBのみを使用するための特別なパーティションでない限り) GPTで使用されるブートパーティション)これを行うと、GRUBは、デフラグ、チェックの実行中、またはその最中など、ファイルシステムがブロックを移動するため、コアイメージを読み取ることができなくなる可能性があります。通常の操作。通常、ディスクデバイス全体へのインストールはより堅牢です。
- GRUBが/ boot/grubを含むデバイスとファイルシステムから読み取る方法を実際に知っていることを確認します。暗号化されたデバイスからも、サポートがまだサポートされていないファイルシステムからも読み取ることができません。 GRUBに追加されました。