web-dev-qa-db-ja.com

仮想ディスクにgrubを配置します

Linuxの起動プロセスについて学ぶために、grubをディスクイメージファイルに配置し、qemuを使用して起動しようとしました。私は現在、カーネルイメージをドライブに入れていません。 grubを使用してインストールしました

kpartx -av mydrive.img
losetup /dev/loop1 /dev/mapper/loop0p1
mount /dev/loop1 mnt/mydrive/
cd mnt/mydrive/boot
grub-install --no-floppy --boot-directory=. -v /dev/loop0

ブートシーケンスを段階的に実行したかったので、grubがカーネルが欠落していると主張することを期待し、カーネルをインストールしてそれを修正し、Xまで追加し続けたいと思いました。

今私は得る

エラー：そのようなデバイスはありません

しかし期待される

エラー：構成ファイルがありません

フォームレスキュープロンプト、lsは

(hd0) (fd0)

質問：* grubが探しているデバイスは何ですか？それはホストシステムを指すものですか？ [部分的に解決されましたが、UUIDは仮想ファイルシステムのUUIDと同じです] * Grubがデバイスを見つけられないのはなぜですか？

VM内のlive-cd（これは小さなバイナリディストリビューションであるため、Bodhi-linuxを選択しました）からgrub（およびgrub以外は何もありません）をインストールすると、すべて正常に機能します。 qemuはブートパーティションに別のuuidを与え、外部では使用されませんか？

仮想ドライブのパーティションテーブルは次のとおりです。

Disk mydrive.img: 264 MB, 264241152 byte
32 huvuden, 63 sektorer/spår, 256 cylindrar, totalt 516096 sektorer
Enheter = sektorer av 1 · 512 = 512 byte
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Diskidentifierare: 0xebe6ebdb

       Enhet Start     Början        Slut     Block    Id  System
mydrive.img1            2048      516095      257024   83  Linux
linuxbootgrub2qemu
6
user877329

この種のパーティションのモジュール（DOS/MBRパーティションラベルを想定しています）は、デフォルトではgrubによってcore.imgにインストールされていないようです。

以下を使用して、必要なモジュールもインストールします。

grub-install --modules part_msdos --root-directory=. /dev/loop0

次に、grubはパーティションテーブル、ファイルシステム、したがってmnt/mydrive/bootに含まれるインストールを読み取ることができるはずです。

その結果、grubコマンドlsは次のように出力されます。

(hd0) (hd0,msdos1) (hd0)
2
doak

Gilesが指摘したように、これはx86アーキテクチャにのみ適用されることに注意してください。

バックグラウンド

適切な順序を知りたい場合は、カーネルをインストールする前に、QEMUにホストシステムをインストールする必要があります。このアプローチは、起動プロセスについて学習するのとは直感に反しているように見えますが、唯一の有効な方法です。説明させてください：

任意のOSの実行中のシステムには、少なくとも3つの部分があります。

  1. カーネル
  2. ローダー
  3. 最終的な起動OS。

コンピューターは2つのモードで動作します。

  1. リアルモード
  2. 保護モード 、誤って仮想モードと呼ばれることもあります。

すべてのx86プロセッサは、どれほど洗練されていても、どれだけ高速に動作しても、これら2つのモードの何らかの形で動作します。詳細については、リンクしたWikiPediaの記事の右側にあるリストを参照してください。

これがどのように機能するか

  1. すべてのコンピュータはリアルモードで起動します。
  2. リアルモードでは、BIOS設定の確認、すべてのデバイスが接続されていることの確認、タイミングの時計の制御などが行われます。
  3. リアルモードのチェックが完了すると、制御はローダー、別名ブートローダーに渡されます。ブートローダーは、PCの制御をリアルモードからプロテクトモードに移すのに十分なコードをロードすることで、その名前が示すとおりに実行します。一部のブートローダーは、「テイクオーバー」の開始時にこの転送を実行します。一部のブートローダーは、終了時に実行しますが、ほとんどはステージで実行します。 起動を参照 。
  4. ブートローダーがステージのロードを完了すると、PCは次の再起動まで「永続的保護モード」になっているため、OSは他のすべての操作を安全かつ効率的に処理できます。

これがGrubとどのように関係するか

Grubを正しくインストールしたときにコピーされたファイルを見ると、Stageというテキストを含むファイルがあります。 3つあるはずです。Stage1*、Stage1_5 *、およびStage2 *

  1. Stage1はMBR/EFIに埋め込まれているboot.imgをロードします。ディスクに接続し、最後にcore.imgをロードするように構成されています
  2. Stage1_5は、core.imgを使用して、一般にBootSectorと呼ばれるセクター0〜62をロードします。慣例により、これらのセクターには何も含まれていないため、それらに配置されたアイテムが自動的に上書きまたは更新されることはありません。
  3. Stage_2が開始されると、最初の62セクターとカーネルへのパスが決定されます。 Stage_2は、カーネルとそのヘルパーファイル、最も自然に 初期RAMディスク をメモリにロードします。RAMディスクとカーネルは次に、圧縮を解除して、yurシステムをセットアップし、選択したLinuxOSに制御を移すために使用します。

GNU Grub を参照してください

さて、これが直感に反すると言う理由：これがどのように機能するかについてのステップ3から始めて、これがどのようにGrubに関連するかを理解することはできません 。 Stage1.5が完了すると、Stage_2はレスキュープロンプトに送信します。カーネルと初期値RAMディスクがある場合は、圧縮されていない場合はセットアップするデバイスがありません。この場合はhd0。また、Grubが報告しているエラーは正しいです。

エラー：そのようなデバイスはありません

hd0にセットアップするOSがないため、正しいです。したがって、GrubStage_2に「ロードする必要のあるOSです」と伝えるOSはありません。そのため、OSをビルドまたはインストールしてからカーネルをインストールし、最後にブートローダーをインストールすることで、逆方向に作業する必要があります。この場合、LiveCDのISOイメージをCDROMとしてロードするようにQEMUを構成してから、仮想ディスクhd0にOSをインストールしてから、ブートローダーを構成する必要があります。 LiveCDのリストについては、 DistroWatch Major Distributions を参照してください。膨張が少ない方が快適だと感じる場合は、ソースベースのディストリビューションを試してください Gentooなど 。

0
eyoung100