web-dev-qa-db-ja.com

Linuxは個別の/ bootパーティションをどのように扱いますか？

Linuxが個別のブートパーティションをどのように扱うかについて興味があります。私は実際にこれを行うことに興味がありますではありませんが、これが内部でどのように機能するか知りたいのですが。

2つのパーティションsda1とsda2があるハードドライブsdaについて考えてみます。 sda2がLinux OSを含むrootパーティション/であるとしましょう。

私の理解では、ブートローダーGRUB2は/bootにマウントされています。ただし、ディレクトリ/bootが別のパーティションsda2にある場合、/が実際にマウントされる前にこれがどのように発生する可能性がありますか？

この場合、BIOS、マスターブートレコード、およびGRUB（またはファイル/boot））間の相互作用はどのように成功しますか？/bootのデータはこの初期段階で実際に/ファイルシステムにマウントされていませんか？

注： この質問 はルートパーティションのマウントを扱いますが、個別のブートパーティションについては説明しません。

bootpartitiongrub
11
jII

ここにあなたの理解の問題があります：

私の理解では、ブートローダーGRUB2は/ bootにマウントされています。

GRUBはブート時に「マウント」されません。 GRUB isinstalledto /boot、and isloadedマスターブートレコードのコードから。MBR/BIOS（GPT/UEFIではない）を備えたGNU/Linuxディストリビューションを想定した、最新のブートプロセスの簡単な概要は次のとおりです。

  1. BIOSがロードされます。
  2. BIOSは、マスターブートレコードにある小さなコードをロードします。
  3. GRUBは、マスターブートレコードのサイズである440バイトに収まりません。したがって、ロードされたコードは実際にパーティションテーブルを解析し、/bootパーティション（マスターブートレコードにGRUBをインストールすると判別される）を見つけて、解析します。ファイルシステム情報。次に、ステージ2 GRUBをロードします（ここで簡略化が行われます）。
  4. ステージ2 GRUBは、GRUB構成を含む）に必要なすべてのものをロードし、メニューを表示します（ユーザー構成によっては、そうでない場合もあります）。
  5. ブートシーケンスが選択されます。これは、タイムアウト、ユーザーによるメニューエントリの選択、またはコマンドリストの起動によるものです。
  6. 起動シーケンスが実行を開始します。これは、たとえばカーネルのロード、別のブートローダーへのチェーンロードなど、さまざまなことを実行できますが、ブートシーケンスが標準のGNU/Linuxであると仮定しましょう。
  7. GRUBはLinuxカーネルをロードします。
  8. GRUBは initial ramdisk をロードします。
  9. 最初のramdiskは/の下に/new_rootをマウントし（おそらく暗号的にロック解除します）、udevを開始し、resume-from-swapを開始します。
  10. 最初のramdiskはpivot_rootユーティリティを使用して/new_rootを実際の/として設定します。
  11. initが始まります。パーティションがマウントされ、デーモンが起動し、システムが起動します。

カーネルはステップ7でのみロードされることに注意してください。このため、ステップ7までマウントの概念はありません。 GRUBがすでに使用している場合でも、ステップ9で/bootを再度マウントする必要があるのはこのためです。

また、GRUBのWikipediaページの GRUB 2セクション を参照することもできます。

18
strugee

Linux（カーネル）は、ブートパーティションの数を気にしません。ディスクからカーネルをロードするのはブートローダーの仕事（例：grub、grub2、lilo）であり、これらのツールはカーネルが配置されている場所の数を気にしません。彼らは特定の場所のみを気にします。

例として、私のブートパーティションは/dev/md1です。これは、物理パーティション/dev/sde1と/dev/sdf1によってサポートされるmdadm RAIDミラーです。必要に応じて、これらを個別にマウントすることができます。つまり、同じデータが含まれているはずですが、技術的には2つのブートパーティションがあると見なされます。

私にとって/ bootに2つのパーティションがあることは可用性の問題ですが、同じように/ bootパーティションが異なる場合もあります。次のステップは、ブートローダーがどのように知るかです。方法は次のとおりです。

menuentry 'Linux 3.10.17 (sde) kernel-3.10.17-g' {
        root=hd0,1
        linux /boot/kernel-3.10.17-g domdadm dolvm root=/dev/md3
        initrd /boot/initrd-3.10.17-g
}

menuentry 'Linux 3.10.17 (sdf) kernel-3.10.17-g' {
        root=hd1,1
        linux /boot/kernel-3.10.17-g domdadm dolvm root=/dev/md3 
        initrd /boot/initrd-3.10.17-g
}

これはgrub2構成の抜粋であり、エントリが参照するブートパーティションを確立するroot=hd0,1とroot=hd1,1のみが異なることに注意してください。

ここで何が起こっているのかを理解できるように、ブーツを歩きます。

  • BIOSはMBRをブートボリュームから読み取り、ブートローダーにジャンプします
  • ブートローダー（例：grub2）は、カーネルを含むデバイスとパーティションを認識するように設定されています。 Grub2はこのパーティションに直接アクセスし、カーネルをメモリにロードします。
  • 次に、ブートローダーがカーネルにジャンプし、カーネルがマシンを起動します。

ブートローダーはあなたが持っているブートパーティションの数を気にしません、それはそれらがどこにあるかを気にするだけで、あなたはそれにその情報を伝えなければなりません。

カーネルは、ブートパーティションがいくつあるかを気にしません。これは、ブートパーティションを表示する必要がないためです（たとえば、新しいカーネルを追加する場合にのみ使用可能にする必要があります）。

6
casey

質問1

私の理解では、ブートローダーGRUB2は/ bootにマウントされています。ただし、/ bootディレクトリが別のパーティションsda2にある場合、/が実際にマウントされる前にこれがどのように発生する可能性がありますか？

あなたが理解しているのはここだとは思いません。 GNU GRUBウィキペディアのページ から：

抜粋

コンピューターの電源がオンになると、コンピューターの [〜＃〜] bios [〜＃〜] は、構成されたプライマリブート可能デバイス（通常はコンピューターのハードディスク）を検出し、初期 をロードして実行しますbootstrapマスターブートレコード （MBR）からのプログラム。 MBRはハードディスクの最初の セクター であり、番号は0です（セクターのカウントは0から始まります）。長い間、セクターのサイズは512バイトでしたが、2009年以降、セクターサイズが4096バイトのハードディスクが利用可能で、 Advanced Format ディスクと呼ばれています。 2013年10月の時点でも、このようなハードディスクは 512eエミュレーション を使用することにより、512バイトのセクターで引き続きアクセスされます。

GRUBバージョン2 では、次のようになります。

抜粋

コンピュータを起動する

電源をオンにすると、次のことが起こります。

  • ハードウェアが初期化し、CPUをリアルモード（仮想メモリなし）に設定し、固定位置0xFFFF0（CPU回路にハードワイヤード）にジャンプします。
  • したがって、ROMまたはその場所にマッピングされたフラッシュメモリに保存されているBIOSコードが実行されます。
  • BIOSコードはBIOS構成データを調べて、どちらが起動デバイスであるかを確認します。通常、このBIOS構成データは、電源をオンにした直後に特別なキーシーケンスを押すことで編集でき、BIOS構成プログラムが実行されます。特に、通常はここで起動デバイスを選択できます。
  • BIOSコードは、ブートデバイスのMBRをRAMにロードします。 MBRは512バイトに過ぎないことに注意してください。ロードされたデータはもちろん、grub-installプログラムが実行されたときにgrub-installが動的に作成してそこに書き込んだプログラムとデータです。
  • BIOSコードは、ロードされたMBRの開始アドレスにジャンプします（つまり、電源投入以降、Grubコードが初めて実行されます）。
  • GrubのMBRコードは、アドレスがMBRブロックに組み込まれている単一のセクターをロードします。次に、そのセクターの（address、len）ペアをループして、すべてのデータをディスクからメモリに読み込みます（つまり、ファイル/boot/grub/core.imgのコンテンツまたはその「埋め込み」コピーを読み込みます）。次に、MBRコードはロードされたコードにジャンプします。つまり、core.imgでプログラムを「実行」します。
  • 「Grubのインストール」セクションで説明されているように、未加工のディスクブロックアドレスを埋め込むこのトリックにより、core.imgをパーティション内ではなく、ファイルシステムとしてまったくフォーマットされていないスペースに格納できます（ 「埋め込み」）。この場合、core.imgが変更されても、新しいバージョンが同じ場所に「埋め込まれている」限り、MBRコードを更新する必要はありません。
  • あるいは、core.imgが実際のファイルシステム内にあり、Grubがそのファイルシステム用のドライバーがなくてもcore.imgファイルの内容を読み取ることができます。ただし、この場合、core.imgを変更すると、ファイルの最初のブロックにディスク上の新しいアドレスが割り当てられる可能性があります。これが発生した場合は、この新しい場所を指すようにMBRを更新する必要があります。それにもかかわらず、core.imgは通常grub-installを実行することで更新されるため、これは通常問題にはなりません。
  • 理論的には、core.imgがMBRとは異なるデバイス上にあり、新しいハードウェアが追加されている場合、Grubによって生成されたMBRレコードがcore.imgファイルを正しくロードできない可能性があります。 core.imgの最初のセクターが見つかるデバイスIDはMBRに固定されており、検索されません。ただし、これに対する解決策はありません。 Grubの「search」コマンドに相当するものを512バイトのMBRに埋め込む方法はありません。ただし、この問題は起こりそうにありません。通常、core.imgはMBRと同じデバイスに埋め込まれます。また、core.imgがロードされると、search.modを使用して、すべての/boot/grubファイルを見つけることができるため、ハードウェアの再配置の影響を受けません。
  • 実行されたcore.imgコードは、それに組み込まれている（core.imgにリンクされている）すべてのモジュールを初期化します。これらのモジュールの1つは、ディレクトリ/boot/grubが存在するファイルシステムを読み取ることができるファイルシステムドライバーになります。
  • また、組み込みコマンドのセット（set、unset、ls、insmod）も登録します。
  • 「構成ファイル」がcore.imgにリンクされている場合、これは非常に単純な組み込みスクリプトパーサーに渡されて処理されます。構成ファイル内のスクリプトコマンドは、組み込みまたはリンクされたコマンドのみを呼び出すことができます。単純なシナリオ（ローカルドライブから典型的なデスクトップコンピューターを起動するなど）では、構成ファイルは必要ありません。この機能は、pxe、リモートnfs、または/boot/grubがLVMデバイス上にある場合のブートなどに使用されます。
  • Core.imgはファイル“/boot/grub/normal.mod”をディスクから動的にロードし、そのエントリ関数にジャンプします。この手順では、適切なファイルシステムドライバーを設定する必要があることに注意してください（つまり、組み込み）。

ss of boot process

注：起動するOS /カーネルを選択する一般的なGRUB2メニューが表示された場合、システムの/boot/grubディレクトリを参照していますこの点。

ss of grub tui

参考文献

6
slm