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

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

ハードドライブ考えてみましょうsda2つのパーティションを持っている、sda1としますsda2。言わせsda2ているrootパーティション/のLinux OSが含まれています。

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

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

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

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

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

GRUBはブート時に「マウント」されません。GRUBがされインストールに/bootされており、ロードマスターブートレコードのコードから。以下は、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は最初のramdiskをロードします。
9. 最初のramdiskは（おそらく暗号的にロックを解除する）/下にマウントされ/new_root、udevを開始し、resume-from-swapなどを開始します。
10. 最初のramdiskは、pivot_rootユーティリティを使用/new_rootして実際のとして設定し/ます。
11. init開始します。パーティションがマウントされ、デーモンが起動し、システムが起動します。

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

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

質問1

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

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

抜粋

コンピューターの電源がオンになると、コンピューターのBIOSは構成されたプライマリブート可能デバイス（通常はコンピューターのハードディスク）を検出し、マスターブートレコード（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）ペアをループして、すべてのデータをディスクからメモリに読み込みます（つまり、fileの内容/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.imgMBRと同じデバイスに埋め込まれます。また、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”をディスクから動的にロードし、そのエントリ関数にジャンプします。この手順では、適切なファイルシステムドライバーを設定する必要がある（つまり、組み込み）ことに注意してください。

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

参照資料

• Grub2を使用したLinux on x86の起動
• GNU GRUB-ウィキペディア
• Linuxブートプロセスの6つの段階（起動シーケンス）
• Linuxブートプロセスの内部
• Linux起動プロセス
• GRUB 2ブートローダー-完全なチュートリアル-Dedoimedo

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

例として、私のブートパーティションはです/dev/md1。これは、物理パーティション/dev/sde1とに支えられたmdadm RAIDミラー/dev/sdf1です。必要に応じて、これらを個別にマウントすることができます。そのため、技術的には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はこのパーティションに直接アクセスし、カーネルをメモリにロードします。
• 次に、ブートローダーがカーネルにジャンプし、カーネルがマシンを起動します。

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

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