スタートアップ過程を理解しようとしましたが、ちょうど一つの想像を超越することがありますね…
Linuxカーネルが起動し、ルートファイルシステム(/)がマウントされたら、プログラムを実行し、追加のカーネルモジュールを統合して追加機能を提供できます。ルートファイルシステムをマウントするには、特定の条件を満たす必要があります。カーネルには、ルートファイルシステムがあるデバイス(特にSCSIドライバ)にアクセスするために適切なドライバが必要です。カーネルには、ファイルシステム(ext2、reiserfs、romfsなど)を読み取るために必要なコードも含まれている必要があります。ルートファイルシステムが暗号化されている可能性があります。この場合、ファイルシステムをマウントするにはパスワードが必要です。
初期のRAMディスク(initdiskまたはinitrdとも呼ばれます)は上記の問題を解決します。 Linuxカーネルは、実際のルートファイルシステムをマウントする前にRAMディスクに小さなファイルシステムをロードし、ここでプログラムを実行するオプションを提供します。initrdローディングはブートローダー(GRUB、LILOなど)によって処理されます。ブートローダには、ブートメディアからデータをロードするためにBIOSルーチンのみが必要です。ブートローダがカーネルをロードできる場合は、初期のRAMディスクもロードできます。特別なドライバーは必要ありません。
/bootが別のパーティションではなく/パーティション内に存在する場合、ブートローダが "initrd"イメージとカーネルイメージにアクセスするためにSCSIドライバは必要ありませんか?イメージに直接アクセスできる場合は、SCSIドライバが必要なのはなぜですか?
答え1
Nighpher、あなたの質問に答えます。ただし、起動プロセスのより完全な説明を表示するには、以下を試してください。この記事のソースはIBMです。。
わかりました、解釈のためのブートローダーとしてGRUBまたはGRUB2を使用しているとします。まず、BIOSがブートローダをロードするためにディスクにアクセスするときに、有名な13h割り込みに格納されているディスクアクセスのための組み込みルーチンを利用します。ブートローダ(および設定中のカーネル)は、ディスクにアクセスするときにこれらのルーチンを使用します。 BIOSはプロセッサのリアルモード(16ビットモード)で動作するため、2 ^ 20バイト以上のRAM(2 ^ 16ではなく2 ^ 20、リアルモードの各アドレスはすべてセグメントアドレスで構成されています)をアドレス指定できません。 *)16 +オフセット、セグメントアドレスとオフセットの両方が16ビットです。参考Wikipediaの「x86メモリ分割」)。したがって、これらのルーチンは1MiB以上のRAMにアクセスできず、これは重大な制限であり、大きな不便です。
BIOSはMBR(ディスクの最初の512バイト)から直接ブートローダコードをロードして実行します。 GRUBを使用している場合、このコードはGRUBのステップ1です。このコードは、ディスク領域の最初の32KiB(DOS互換領域と呼ばれる)またはファイルシステムの固定アドレスにあるGRUBステップ1.5をロードします。これを行うためにファイルシステム構造に関する知識は必要ありません。これは、ステップ1.5がファイルシステムにあっても「生」コードであり、RAMに直接ロードして実行できるためです。 Pixelbeat.orgの「PC用GRUBの詳細」、下の画像のソースです。ディスクからRAMへの1.5段階のロードは、BIOSディスクアクセスルーチンを利用します。
手順1.5にはファイルシステムユーティリティが含まれており、ファイルシステムから手順2を読み取ることができます(もちろん、BIOS 13hを使用してディスクからRAMに読み込むが、現在はinodeなどのファイルシステム情報を復号化してディスクからソースコードを取得するすることができます)。以前の BIOS は、ディスクアドレッシングモードの制限により、HD 全体にアクセスできない場合があります。つまり、スティグマセクタシステムを使用でき、ディスクスペースの最初の8GiB以上をアドレス指定できません。http://en.wikipedia.org/wiki/Cylinder-head-sector。
第二段階カーネルロードRAMに書き込みます(再びBIOSディスクユーティリティを使用して)。 2.6+カーネルの場合、initramfsもコンパイルするため、ロードする必要はありません。古いカーネルの場合、ブートローダは別のinitrdイメージをメモリにロードし、カーネルがそれをマウントし、ディスクから物理ファイルシステムをマウントするためのドライバをインポートできるようにします。
問題は、カーネル(およびRAMディスク)の重量が1MiBを超えるので、それをRAMにロードするには、カーネルを最初の1MiBにロードしてから保護モード(32ビット)にジャンプし、ロードされたカーネルを高い位置に移動する必要があることです。メモリ(リアルモードで最初の1MiBを取得)してから、リアル(16ビット)モードに戻り、ディスクから最初の1MiB(別のinitrd以前のカーネルの場合)にRAMディスクをインポートします。おそらくそうです。保護(32ビット)モードに戻り、元の位置にしてからリアルモードに戻すこともできます。https://stackoverflow.com/questions/4821911/does-grub-switch-to-protected-mode)カーネルコードを実行します。警告:この説明の完全性や正確性は不明です。
今、最後に、カーネルを実行すると、カーネルがすでに存在し、ブートローダを介してRAMディスクがRAMにロードされます。したがって、カーネルはramdiskのディスクユーティリティを使用して実際のルートファイルシステムをマウントし、ルートをここに転送できます。 ramfsドライバはカーネルに存在するので、当然initramfsの内容を理解しています。
答え2
私はこれが特定のブートローダがどの機能をサポートしているかに依存していると思います。例えば。結合(ブート+ルート)パーティションの特定のファイルシステムを知る必要はありません。この場合、ブートローダと連携するように別々のブートパーティションを作成するだけです。ルートパーティションをマウントする方法のその他の複雑さは、ブートパーティションから起動するカーネルイメージとinitrdイメージに残ります。ブートローダは、独自のドライバを使用するか、BIOSルーチンを使用してSCSIデバイス(および使用されているブートローダによって異なるデバイス)にアクセスする方法を知っています。また、一部のファイルシステムなどを読み取る方法も知っています。
たとえば、考えてみましょう。 UEFIブートを使用すると、実際にUEFIファームウェアはEFIパーティションにアクセスし、それを読み取り、中間ブートローダなしでそこからLinuxカーネルをロードする方法をすでに知っています。この場合、Linuxイメージはルートパーティションから分離されており、UEFIファームウェアはそれにアクセスするためにすべての外部ファイルシステムを知る必要はありません。私は「ブート」イメージを「ルート」パーティションから分離するのが合理的だと思います。他に理由がない場合は、ルートファイルシステム暗号化を設定するときにこれが必要です。
答え3
記録のためにブートローダがこれを行う場合いいえinitrdをロードすることは他のブートローダをテストする価値があります。これLILOが正しく指定された中間サイズinitrd(<4Mb、SATA SSDの単一のext4 rootfs、GPT)を自動的に無視し、GRUB 2.00が成功した場合。
起動プロセスは通常の手順で迅速に終了します。
RAMDISK: Couldn't find valid RAM disk image starting at 0.
Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(8,3)