/ 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には、オペレーティングシステムではなく、 bootloader によって使用されるファイルが含まれています。ブートローダー自体のファイル（Grubの/boot/grub/*など）とLinuxカーネル（/boot/vmlinuz*）の両方、および関連する initrd のファイルが見つかります。または initramfs 。
legacy BIOS のあるPCの場合（新しい [〜＃〜] uefi [〜＃〜] とは対照的） /最近のコンピューターで見つかりました）、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の問題の横にあるもう1つの理由は、別個の/bootパーティションにより、ブートローダーが理解できない/ボリュームのファイルシステムの使用が許可されることです（liloのようなブロックリストのロードに限定されない） ）。
起動ISハード
起動...ええと...それは本当に難しい部分です。コンピュータが起動するたびに、基本的には新しいものに出会います。さまざまなパーツに精通しており、それぞれが満たす能力を身につけます。しかし、いわば、毎回正方形から、独自のブートストラップで自分自身を引き上げる必要があります。
起動プロセスを設計するときの秘訣は、マシンを段階的に立ち上げることです。ブートは高速andである必要があり、完全に未知の環境毎回。私は、リアル/プロテクトモードの会話に手を出すことすらしません（私ができるとも言わない）ですが、起動時には多くのことが行われています。コンピューターは、段階的なステップでそのたびにさまざまなコンポーネントを吸収します。おそらく、これらの中で最も重要なのは、オンボードコードの実行からオンディスクコードの実行への移行、つまり、カーネルexecです。これは、ファームウェア（表向き）がオペレーティングシステムに委譲する場合です。
何年も前、これはそうではなかった。以前はBIOSでしたが、実際にはBasic In/Outでした。通常のプログラムは、画面の描画やディスクへのアクセスなどのためにファームウェアを呼び出します。これらはinterruptsと呼ばれていました。古い帽子は、新しいドットマトリックスまたはUSRにIRQを割り当てるときにしばしば見つけた喜びのスリルに最もよく覚えています。
INT13H
割り込み（またはINT in Assembly lingo）13H BIOSが提供する一連の関数ディスクアクセスのためのサービス。これらは、現在でも、ブートプロセスのBIOSシステムでファームウェアからディスクにジャンプするために使用されています。
BIOSシステムは、検出した各ディスクの最初の数バイトをチェックし、[マスターブートレコード（]またはMBR）。これは何十年も前の事実上の標準であり、ディスクのヘッドに書き込まれる生の実行可能なバイナリが少し含まれています。 MBRはBIOSディスクを起動可能としてマークします。それが見つかるとチェックを停止しますので、実用的には巧妙なトリックをせずに取得できるのは1つだけです。それが見つかると、それをメモリにマップして実行します（リアルモードでは、私はまだそこに行きません）。
実行されたMBRはほぼ間違いなくシステムカーネルではありません-512バイト（give or take）はその部門ではかなり役に立たないでしょう。これはおそらくブートローダー-BIOSの多くのアドレッシング制限のoneを克服するために特別に設計されたプログラムです-特に、どの種類のファイルシステムもまったく理解していません。
ブートローダーが実際のカーネルを読み込んでitをメモリ内で実行するとき（誰もがそれを祈るたびに）を実行すると、おそらくBIOSに- INT13H割り込み呼び出し。そうでない場合-多くのより洗練されたブートローダーは従来の意味でファイルシステムをマウントし、コードを別の方法で実行します-そして、ブートローダーがINT13Hなしでそれほど豪華になった可能性はほとんどありません=または2つ。多くの場合、ブートローダーは、自分自身またはさまざまなstages自身をチェーンロードする必要があります。最初に割り当てられた512バイトは、それらのニーズにも適合しないためです。
鶏と卵
これはすべて、ディスクについて議論するための遠回りの方法ですが、この時点で、主な問題（1つはchicken-and-Egg typeと呼ばれることもあります）がアクセスしていることは明らかです。 ディスクへのアクセス方法に関するプログラムの説明を含むディスク。この問題の鍵はファームウェア-であり、EFIシステム上でも非常に異なる方法であり続けます-そして、最も弱いかどうかにかかわらず、ファームウェアはブートチェーンの最も重要なリンクです。
カーネルが実行され、ハードウェアにアクセスして制御するための無数のルーチンが開始すると、これらの問題はすべて消えます（または、少なくとも多少変更）、最新のOSはシステムのフルコントロール。ただし、システムが制限するまでは、ファームウェアが許可する範囲でのみシステムの制限が拡張されます。これは多くのことを言っています-BIOSは8086以来それほど変わっていません。INT13H呼び出しは8086オリジナルです。はい、もちろん（無数）拡張、そしてハックはありましたが、革新的なものは...？
より良い、より良い
BIOSへのほとんどの変更は、せいぜい単なる包帯でした。以前はハードディスクでしたが、物理的にマッピングする必要がありました。geometryのさまざまな特定の側面は、データが格納されたり、そこから取得されたりするときに参照されました。最終的に、従来のハードディスクはこれを妨げるサイズに成長しました。抽象マップだけでも多すぎる BIOSが処理するための情報でした。リアルモードでのみ動作するため、BIOSはメモリレジスタあたり1 MBに制限されています。シリンダーマップをそれよりも大きく膨らませるか、そのプロパティのいずれかを非常に多くのビットで対処できるよりも大きくすると、BIOSは文字通り失われます-範囲外。
この障壁は満たされ、破られました多数回。地図が抽象化され、新しい、賢い、精度の低い方法でエンコードされるたびに。そして最近では、BIOSがドライブを正確にマップすることは文字通り不可能です。 Logical Block Addressingは現在、事実上の標準ですが、一部のCylinder/Head/Sector（or CHS）翻訳はまだ必要です。メインボードファームウェアの正確性/責任が失われたこと、そのような拡張機能が抽象化され、ギャップを埋めるためにディスクファームウェアの責任に追加されました。
質問で参照されているのは、この猫とマウスのゲームです。純粋なサイズのためにBIOSが特定のポイントを超えてディスクを理解できない場合、ブートローダーやカーネルなど、ブート時に取得する必要のあるデータは、おそらくそのポイントを超えて配置されない方がよいでしょう。これが/bootの由来です。
たぶん実際にはより良い
最近、そのようなことは、ありがたいことに、BIOSの廃止とは無関係になっています。 30年が経過しましたが、過去数年間で [〜＃〜] uefi [〜＃〜]（またはEFI 2.0）標準に大きく置き換えられました。 UEFIはmountを1分から提供し、保護モードで初期化し、独自のブートローダーを組み込み、再起動永続的なフラッシュメモリ変数ストレージを提供し、いくつかの大きなゼタバイトなどを処理するように仕様化されていますディスクごと...そして他の多く。それは完璧とはほど遠いですが、前任者よりも大幅に改善されています。
とにかくOSカーネルでこれらすべてを処理する必要があると考えると、ディスク暗号化または階層化ファイルシステムを含む特殊なブートローダーの引数もフラットになり、ブート時にmountが指定されている場合、 'それを実行するための明確なショットを常に持っています（特に、Linuxカーネルは、そのデフォルト構成では、それ自体がすべてEFI実行可能であることを考慮してください）。
したがって、個別の/bootパーティションはおそらくあまり気にする必要はありません。EFIシステムを使用している場合は、とにかくEFIシステムパーティションにアナログがすでにあるはずです。 EFIモード。
/bootディレクトリは歴史的に決定されており、そこから Filesystem Hierarchy Standard で「修正」されています。このような標準があると、プログラム（およびsysadmins）は特定の場所に特定のファイルがあることを期待できます。この場合、起動プロセスに関連するファイルです。
/bootディスクの最初のパーティションは、使用可能なドライブの全範囲のブロック/セクターにインデックスを付けることができなかった古いBIOSには意味があります。このため、ロードする必要がある情報は、インデックスを付けることができるセクターにある必要があります。したがって、/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つ目のパーティションに配置することで、同じ効果を得ることができます。
最近のbootpartitionのもう1つの理由は次のとおりです。
- nFSまたはNBDからの起動
- 暗号化されたルートパーティション
- / bootは異なるディストリビューション間で共有