/ bootパーティションは本当に何のためですか？

Linuxパーティションとファイルシステムに関する比較的古いテキスト（LPIC 1 Certification Bible）を読んでいます。それは言います：

Linuxブートローダーの一部のバージョンは、ディスク上の最初の1024シリンダーの外側にあるカーネルにアクセスできません。ドライブの先頭に/ bootパーティションを配置することにより、ブート時にカーネルにアクセスするときに問題が発生しないことが保証されます。この問題は、最初のパーティションにある別のオペレーティングシステムとともにLinuxをデュアルブートする場合に最も頻繁に発生します。

ブートローダーが「ディスク上の最初の1024シリンダー以外のカーネルにアクセスできない」のはなぜですか？

また、「/ bootパーティションをドライブの先頭に置く」とはどういう意味ですか？

これは、Linux自体ではなく、非常に古いBIOSとブートローダーを使用することによる制限です。BIOSはディスクの最初の1024シリンダーにのみアクセスできます（シリンダー/ヘッド/セクターの詳細については、こちらを参照してください）。この制限は、単純な性質のため、独自のディスクドライバーを持たず、BIOSサービスを使用してディスクにアクセスするブートローダーにも適用されます。

これは、ブートローダーとカーネル（ロードするのはブートローダーの仕事であるため）の両方が、この制限のあるシステムの最初の1024シリンダー内になければならないことを意味しました。これを行う簡単な方法/bootは、カーネルを含む別のパーティションを作成し、それをドライブの先頭に置くことでした（通常は最初のパーティションにするだけです）。これは、パーティションが大きすぎないことを条件に、最初の1024シリンダー内に物理的に常駐することを意味します。

古いBIOSにのみ適用されるため、この制限はもはや問題ではありません。また、多くの最新のブートローダー（GRUBなど）には独自のディスクドライバーがあるため、BIOSサービスに依存する必要はありません。最新のブートローダーは/boot他の目的にも使用できますが、別のパーティションと最初の1024シリンダー内の両方に存在する必要はなくなりました（ただし/boot、別のパーティションに配置する必要がある場合が多くあります）。

歴史

/bootオペレーティングシステムではなく、ブートローダーで使用されるファイルが含まれています。ブートローダー自体（/boot/grub/*Grubなど）とLinuxカーネル（/boot/vmlinuz*）の両方のファイルがあり、多くの場合、関連するinitrdまたはinitramfsがあります。

（最新のコンピューターに見られる新しいUEFIとは対照的に）レガシーBIOSを搭載したPCでは、ROM内のソフトウェアがブートディスクの最初の512バイトをメモリ（ブートセクター）にロードします。512バイトしかない（すべてにコードが含まれているわけではありません。一部にはパーティションテーブルなどのデータが含まれています）ので、コードは多くのことを実行できません。実際のディスクドライバーはありません。そのような限られたスペースでできることは、BIOSインターフェイスを使用してより多くのコードをロードすることだけです。このインターフェイスは、ディスク上のN番目のセクターをロードするコマンドを提供します。Nのサイズは制限されているため、その方法でディスクの先頭にしか到達できません。

BIOSインターフェースは30年ほどで進化してきましたが、そのサイズ制限はディスクサイズに対応するのに苦労しており、古いBIOSやブートローダーは32MB、512MB、2GB、8GB（そしておそらく私が覚えていない他のしきい値）。ブートローダは、BIOSインターフェイスを使用して、ディスクドライブに直接アクセスするために必要なすべてのピースをロードできる必要があります。ブートローダーには一般にすべてのディスクコントローラー用のドライバーが含まれていないため、Linuxカーネル（およびinitrd / initramfs）を読み込むまでのすべてがBIOSインターフェイスを使用する必要があるため、ディスクの先頭に収まる必要があります。

これはBIOSまたはブートローダーの制限であり、Linux自体またはディストリビューションの制限ではないことに注意してください。

/boot今日は別

最新のBIOSと最新のブートローダー、またはUEFIを搭載したシステムでは、サイズの制限はもはや関係ありません。ディスクサイズが追いつくのに時間がかかります。ただし、別の/bootパーティションを有用にする他のユースケースがあります。これにより、メインシステムは、ブートローダーがサポートしていないRAIDデバイス、またはブートローダーがサポートしていないファイルシステムタイプに配置できます。メインシステムを暗号化されたデバイス上に置くことができます。Linuxはこれを解読できますが、ブートローダーは解読できません。

これらの制限とユースケースのいずれも/boot当てはまらない場合、個別のパーティションとして保持することは役に立ちません。しかし、それらはほとんどのディストリビューションがそれをサポートする十分な人々に影響します。

前述のBIOS問題のほかの理由は、別の/bootパーティションが/、ブートローダーが理解できないボリュームのファイルシステムの使用を許可することです（ブロックリストの読み込みに制限されることなくlilo）。

起動が難しい

起動...まあ...それは本当に一番難しい部分です。コンピュータが起動するたびに、それは基本的に新たに会います。さまざまな部分に慣れており、それぞれの部分で能力を獲得します。しかし、それは、いわば、自力でブートストラップを実行する必要があります。

ブートプロセスを設計する際の秘theは、マシンを段階的に起動することです。起動は高速で信頼性が高く、毎回完全に未知の環境にある両方でなければなりません。Real / Protectedモードでの会話に挑戦することさえありません（私ができると言っているわけではありません）が、起動時に多くのことが行われています。コンピューターは、段階的な段階でさまざまなコンポーネントを同化するたびに、同化します。おそらく、これらの中で最も重要なのは、オンボードコードの実行からオンディスクコードの実行、つまりカーネル実行への移行です。これは、ファームウェアが（表面上）オペレーティングシステムに降伏するときです。

何年も前、これはそうではありませんでした。以前はBIOSでしたが、実際にはBasic In / Outでした。通常のプログラムは、画面の描画やディスクへのアクセスなどのためにファームウェアを呼び出します。これらは割り込みと呼ばれていました。古い帽子は、新しいドットマトリックスまたはUSRにIRQを割り当てるときによく見かけるスリルを味わうために、最もよく覚えているかもしれません。

INT13H

BIOSがディスクアクセスのサービスとして提供するのは、割り込み（またはINTアセンブリ言語）13Hシリーズの機能です。これらは、ブートプロセスのBIOSシステムでファームウェアからディスクにジャンプするために今日でも使用されています。

BIOSシステムは、検出した各ディスクの最初の数バイトをチェックし、マスターブートレコード（またはMBR）として認識するパターンを探します。これは数十年前の事実上の標準であり、ディスクのヘッドに書き込まれる生の実行可能なバイナリが少し含まれています。MBRは、BIOSディスクを起動可能としてマークします。見つかった場合はチェックを停止します。したがって、実際には、巧妙なトリックを使用しなくても1つだけが得られます。見つかった場合は、メモリにマップして実行します（リアルモードでは、まだそこに行きません）。

実行されたMBRはほとんど間違いなくシステムカーネルではありません。512バイト（ギブまたはテイク）はその部門ではほとんど役に立ちません。これはおそらく、ブートローダー（ BIOSの多くのアドレス指定制限の1つを克服するために特別に設計されたプログラム）であり、具体的には、いかなる種類のファイルシステムもまったく理解しないことです。

ブートローダーが実際のカーネルを読み取り、メモリで実行するとき（私たち全員が毎回祈っています）、おそらくINT13H割り込み呼び出しを介してBIOSに尋ねることによってそうします。そして、そうでない場合-多くのより洗練されたブートローダーが従来の意味でファイルシステムをマウントし、コードを別の方法で実行します-ブートローダーがINT13H1つまたは2つなくてもそれほど空想を持っている可能性はほとんどありません。多くの場合、ブートローダーは、最初に割り当てられた512バイトがニーズにさえ合わないため、自分自身またはさまざまな段階でチェーンロードする必要があります。

鶏肉と卵

これはすべて、ディスクについて議論する回り道ですが、この時点までに、主な問題（鶏と卵のタイプと呼ばれることもある）がプログラム命令を含むディスクにアクセスしていることを十分に明らかにする必要がありますどのようにアクセスディスクに。この問題の鍵はファームウェアです-そして、EFIシステム上でも非常に異なる方法であり続けます-そして、最も弱いかどうかにかかわらず、ファームウェアはブートチェーンの最も重要なリンクです。

カーネルが実行され、ハードウェアにアクセスして制御するための無数のルーチンがすべて開始されると、これらの問題はすべて消滅します（または、少なくとも多少変化します）。しかし、それらが実行されるまで、システムの制限はファームウェアが許可する範囲内でのみ拡張されます。これは多くのことを言っています-BIOSはINT13H8086 以降ほとんど変更されていません。呼び出しは8086のオリジナルです。はい、（無数の）拡張機能があり、もちろんハッキングもありますが、イノベーションは...？

より良いとより良い

BIOSのほとんどの変更は、せいぜい単なる包帯でした。以前はハードディスクでしたが、物理的にマッピングする必要がありました。データを保存したり、そこから取得したりするときに、ジオメトリのさまざまな特定の側面が参照されました。最終的に、従来のハードディスクはこれを禁止するサイズにまで成長しました。抽象マップだけでも、BIOSが処理するには情報が多すぎます。リアルモードでのみ動作できるため、BIOSはメモリレジスタごとに1 MBに制限されています。シリンダーマップをそれより大きくするか、そのプロパティのいずれかを非常に多くのビットでアドレス指定できるより大きくすると、BIOSは文字通り失われます-範囲外です。

この障壁は何度も満たされ、壊れてきました。マップが抽象化およびエンコードされるたびに、より新しく、賢く、あまり正確ではありません。そのため、最近ではBIOSがドライブを正確にマップすることは文字通り不可能です。論理ブロックアドレス指定は、事実上の標準になりましたが、シリンダー/ヘッド/セクター（またはCHS）の変換が依然として必要です。メインボードのファームウェアが精度/責任において失ったものは、そのような拡張機能が抽象化され、ギャップを埋めるためにディスクファームウェアの責任に追加されました。

あなたの質問で参照されているのは、この猫とマウスのゲームです。BIOSがその大きさのために特定のポイントを超えてディスクを理解できない場合、ブートローダーやカーネルなど、ブート時に取得したいデータは、おそらくそのポイントを超えて配置しない方が良いでしょう。これがどこ/bootから来たのかです。

実際にはより良い

ありがたいことに、このようなことは、ありがたいことに、BIOSの終byによって無関係になりました。30年が経過しましたが、過去数年でUEFI （またはEFI 2.0）標準にほぼ置き換えられました。UEFIは、1分からマウントを提供し、保護モードで初期化し、独自のブートローダーを組み込み、再起動永続的なフラッシュメモリ変数ストレージを提供し、数千のゼータバイトまたはディスクごとに処理するように仕様化されています...それ以外。完璧とはほど遠いですが、前任者を大きく改善しています。

いずれにせよ、これらすべてをOSカーネルで処理する必要があると考えると、ディスク暗号化またはレイヤードファイルシステムを含む特殊なブートローダーの引数でさえ平たんになり、ブート時にマウントを提供すると、常に明確なそれを実行するためのショット（特に、デフォルト構成のLinuxカーネルはすべてEFIで実行可能であることを考慮して）。

したがって、/bootおそらく別のパーティションはあまり気にする必要はないはずです。EFIシステムを使用している場合は、EFIモードを起動するための要件であるEFIシステムパーティションに既にアナログがあるでしょう。

が存在することを/bootディレクトリが、歴史的に決定され、そこでは「固定」であるファイルシステム階層標準。このような標準があると、プログラム（およびシステム管理者）は特定の場所にある特定のファイルを期待できます。この場合、ブートプロセスに関連付けられたファイル。

持つ/bootディスクの先頭に分割して使用可能であったドライブの完全な範囲のインデックスブロック/セクタにできなかった古いBIOS'esのために意味を成していました。このため、ロードする必要がある情報は、インデックスを作成できるセクターにある必要があります。したがって/boot、BIOSが追加のデータ/プログラムをロードできる別のパーティション（セクター番号が小さい）になります。 BIOSを使用しないディスク範囲）。

また、別の/ bootパーティションを作成することも非常に整然としています。私のマシンには多くのディストリビューションとバックアップがあり、それぞれ独自のパーティションにありますが、それらはすべて同じ/ bootパーティションを共有しています。これはすべてのOSのすべてのカーネルが存在する場所です。また、すべてのディストリビューションは/ bootにあるlilo.confの唯一のコピーを指しているため、カーネルを追加したり、ディストリビューションを追加したりするときに何が起こっているのかを推測する必要はありません。これが私のlilo.confからの抜粋です：

image  = /boot/vmlinuz-3.16.0-4-686-pae
initrd = /boot/initrd.img-3.16.0-4-686-pae
root   = "LABEL=y5--5-Debian1"
label  = y5:D1:16.0-4

image  = /boot/vmlinuz-3.16.0-4-686-pae
initrd = /boot/initrd.img-3.16.0-4-686-pae
root   = "LABEL=y8--5-Debian2"
label  = y8:D2:16.0-4

image  = /boot/vmlinuz-3.16.0-4-686-pae
initrd = /boot/initrd.img-3.16.0-4-686-pae
root   = "LABEL=y11-5-Debian3"
label  = y11:D3:16.0-4

image  = /boot/vmlinuz-3.16.0-4-686-pae
initrd = /boot/initrd.img-3.16.0-4-686-pae
root   = "LABEL=w5--5-Debian1"
label  = w5:D1:16.0-4

...これは、2つのディスク上のDebianバックアップだけです。カーネルの追跡がどれほど簡単かをご覧ください。（現在、同じカーネルを使用するすべてのバックアップ）。

最新のシステムでは、ファイルのセクターはディスク上のどこからでもアクセスできますが、単に「すべての卵を1つのバスケットに入れない」という原則から、ブートマテリアルを独自のブートパーティションに限定することは理にかなっています。

下位ステージのブートローダーが次のステージを適切に読み取れないような方法でメインファイルシステムが破損しているとします。代わりに、ブートローダーのマテリアルが独自のパーティションにある場合、カーネルが起動し、fsckを介して破損したルートパーティションを適切に処理できます。それ自体は、独自のパーティションに配置できます。

ブートパーティションには、代替ルートパーティションのマウントなど、「レスキュー」のオプションがあります。また、異なるパーティションで異なるオペレーティングシステムをマルチブートした場合はどうなりますか？その場合、ブート材料はこれらのシステムのいずれにも属しません。独自のパーティションを持つことは合理的です。OSパーティションのいずれかを別のOSに置き換えても、残りのOSを起動できる場合があります。

また、ブートローダがまったく理解できないメインパーティションのファイルシステムを使用する場合はどうなりますか？または、ブートローダー側のサポートは実験的なものですか？そのような状況では、セクターマップがあればブートタイムファイルを使用できます（そしてブートローダーはそのようなことをサポートします：古き良きLinuxブートローダーLILOはセクターマップを使用したので、ファイルシステムを理解する必要はありませんでしたすべての構造）。しかし、セクターマップは本質的に不安定です。ファイルシステムが再編成されると、セクターが動き回るので、セクターマップが不正確になり、再生成する必要があります。そうしないと、システムをリブートできません。

最後に、実際のパーティションがない場合でも、すべてのブートアイテムが少なくともの下/bootにあり、他の場所に散らばらないという組織原則があります。

これはLinuxディストリビューションの制限ではありませんでしたが、古いBIOSの制限でした。当時は、Linuxを確実に起動するために、すべての起動関連ファイルを独自のパーティションに配置し、ハードディスク上の最初のパーティションにして、ブートローダーが最初の1024シリンダー内に収まるようにしました。1024シリンダー（ハードドライブごとに異なる）にあるサイズよりも小さいパーティションを作成します。ただし、この境界よりも大きい最初のパーティションを作成すると、ブートローダーファイルが1024シリンダーの外側に配置され、BIOSがそれらをロードできなくなる可能性があります。

また、最初の1024シリンダー内にある2つの小さなパーティションを作成し、2番目のパーティションにすべてのブートローダーファイルを配置することでも、同じ効果を達成できます。

最近のブートパーティションのもう1つの理由は次のとおりです。

• NFSまたはNBDからの起動
• 暗号化されたルートパーティション
• / boot共有betweedの異なるディストリビューション