トップ > Live CD化 >
初期RAMディスクについて

初期RAMディスクとは、Linuxシステムの起動の途中で一時的に利用される小さなルートファイルシステムのことです。

初期RAMディスクには、/bin /lib /dev などのディレクトリがあり、それぞれのディレクトリには必要最低限のコマンドやデバイスファイルなどが含まれています。 つまり、初期RAMディスクは、小さなLinuxシステムであるともいえます。

なお、初期RAMディスクは、普段はアーカイブされた1つのファイルであり、必要な時にだけメモリ上でツリー構造に展開されます。 初期RAMディスクのファイルのアーカイブ形式には、initrd形式と、initramfs形式があります。 なお、initrdというファイル名にも関わらず、中身はinitramfs形式だということも珍しくありません。

initrd形式はループバックデバイスであり、ループバックマウントして取り扱います。 一方、initramfs形式はcpioフォーマットのアーカイブであり、こちらの方が取り扱いが簡単です。

なぜ、初期RAMディスクが必要なのか。 それを説明するには、まず、カーネルの機能のモジュール化から説明する必要があります。

開発された当時のLinuxカーネルは非常に小さなものでした。 しかし現在では、様々なハードウェアデバイスに対応する必要もあり、Linuxカーネルのソースコードは、2000万行を超えています。 結果、カーネルを色々なデバイスに対応できるようにコンフィグレーションしてビルドすると、カーネルが非現実的なサイズにまで巨大化してしまうことになります。

Linuxカーネルの開発者たちは、将来的にLinuxカーネルが肥大するであろうことを、かなり以前から予見していました。 そこで、Linuxカーネル バージョン1.2では、ドライバや各種機能をモジュール化できるようにするための『ローダブルカーネルモジュール』の技術が導入されました。

ローダブルカーネルモジュールは、カーネルが必要とする機能を、必要な時にだけメモリにロードするための仕組みです。 どれだけのデバイスに対応させようと、どれだけの機能を組み込もうと、モジュール化させてしまえばカーネルは小さいままで済むのです。

ただし、ドライバや機能をモジュール化してしまうと困ったことが起こります。 カーネルがルートファイルシステムをマウントできなくなってしまうのです。 パーソナルコンピュータの電源が投入されると、BIOS → ブートローダ → カーネル → initプロセスの流れでLinuxシステムの起動が行われます。 しかし、カーネルに起動ディスクのドライバがないため、ルートファイルシステムをマウントできず、initプロセスを起動できなくなるのです。

『それなら、起動ディスクのドライバはカーネルに組み込んで、他のデバイスのドライバだけをモジュール化すればいいじゃないか』と思う方もいるかもしれません。 しかし、それでも肥大化するのです。

ハードディスクには、SATA、SCSI、IDE、USB接続などがあります。 また、そもそもハードディスクではなく、USBフラッシュメモリにインストールしようとしている利用者もいるでしょう。 さらに、ルートファイルシステムのファイルシステムタイプがEXT2 / EXT3 / EXT4 ではなく、XFS や ReiserFS や JFS の場合も考えられます。 もっと恐ろしいことに、ルートファイルシステムは、LVM の機能を使ってRAID構成になっているかもしれません。

それらを網羅しようとしてカーネルに組み込んでしまうと、結局、肥大化は避けられなくなってしまうのです。

そこで登場するのが、初期RAMディスクです。 すでに説明したように、初期RAMディスクは必要最低限のコマンドやデバイスファイルなどが含まれた小さなLinuxシステムです。

その『小さなLinuxシステム』に、起動ディスクのルートファイルシステムをマウントするために必要となるカーネルモジュール、さらに、カーネルモジュールをロードするためのコマンド群を組み込めばいいのです。 そうすれば、初期RAMディスクにさえアクセスできれば、どの起動ディスクにあるルートファイルシステムにでもアクセスできるようになります。

もちろん、カーネルは必要最低限のサイズで済みます。 また、起動ディスクのルートファイルシステムがマウントされた後は、初期RAMディスクはメモリから消去されます。 よって、初期RAMディスクが不必要にメモリを圧迫することもありません。

『初期RAMディスクにさえアクセスできれば、後はなんとかなる』と説明しました。 しかし、こう思う方もいるのではないでしょうか。 『初期RAMディスクは確実に読めるのか』と。

まず前提として、起動ディスクから初期RAMディスクを読み込むのは、カーネルではありません。 初期RAMディスクは、ブートローダ(セカンダリブートローダ)によって読み込まれます。

ブートローダは、カーネルを起動ディスクからメモリに読み込んだ後に、初期RAMディスクもメモリに読み込みます。 つまり、カーネルは何のドライバも必要とせずに、初期RAMディスクにアクセスできるのです。

でも、みなさん疑問に思わないでしょうか。 なぜ、512バイトしかないプライマリブートローダが、起動ディスクからセカンダリブートローダを読み込めるのでしょうか。 カーネルは、起動ディスクのルートファイルシステムをマウントしようとして肥大化に困っているんです。 なのにどうして、512バイトしかないプライマリブートローダが、起動ディスクからセカンダリブートローダを読み込めるのでしょうか。

答えは単純で、GRUBは、BIOSを経由して起動ディスクにアクセスしています。 つまり、GRUBは、ドライバを持つことなく起動ディスクにアクセスできるのです。

加えてGRUBは、一般的に使われているファイルシステムタイプを解析できるだけでいいのです。 LVMによるRAID構成のような、特殊な構成のルートファイルシステムは解析できなくても問題はありません。 つまり、512バイトだけしかなくても、なんとかセカンダリブートローダを読み込む機能が持てるのです。

でもなぜ、一般的に使われているファイルシステムタイプのみを解析するだけで済むのでしょうか。 なぜ、LVMによるRAID構成のような特殊な構成のルートファイルシステムは解析できなくてもいいのでしょうか。

それは、セカンダリブートローダが置かれているパーティションのファイルシステムタイプや構成を限定しておけばいいからです。

具体的には、セカンダリブートローダが置かれている /boot を ルートファイルシステムとは別のパーティションとして独立させ、EXT2 / EXT3 / EXT4 などの一般的なファイルシステムタイプとし、RAID構成などの特殊な構成にしなければいいのです。

そうすれば、わずか512バイトのプライマリブートローダでも、起動ディスクからセカンダリブートローダを読み込むことができるのです。 起動ディスクにはBIOS経由でドライバなしでアクセスできますし、/boot が EXT2 / EXT3 / EXT4 / XFS / ReiserFS / JFS のような一般的なファイルシステムタイプで、かつ、LVMによるRAID構成ではないなら解析も簡単です。

読み込まれたセカンダリブートローダは、カーネルと初期RAMディスクを読み込みます。 カーネルや初期RAMディスクも /boot にあるため、同様の理由で簡単に読み込むことができるのです。

作成した新システムでは、初期RAMディスクは使用していません。 そもそも、初期RAMディスクという用語すら出てきませんでした。

これまで初期RAMディスクを使わずに済んでいたのは、ハードディスクのドライバがビルトインされているためです。 作成した新システムのカーネルは、ほぼ標準設定のままでカーネルコンフィグレーションを行いました。 そのため、多くのハードディスクのドライバがビルトインされています。 また、標準設定では、EXT4 ファイルシステムもビルトインされます。

そのため、初期RAMディスクがなくても、カーネルが起動ディスクのルートファイルシステムをマウントできたのです。

ここからは、初期RAMディスクを利用するよう新システムを修正していきます。 初期RAMディスクを利用する理由は、1CD Linuxを動作させるには、ルートファイルシステムに透過ファイルシステムを使用しなければならないからです。

透過ファイルシステムについては後ほど説明しますが、透過ファイルシステムをルートファイルシステムとしてマウントするには、初期RAMディスクを用意し、その中で透過ファイルシステムを操作する処理を行わなければならないのです。

つまり、初期RAMディスクの本来の目的である、『起動ディスクのルートファイルシステムをマウントするために必要となるカーネルモジュールを提供する』のためではなく、『起動ディスクのルートファイルシステムをマウントする前にちょっとした細工をする』という目的のために初期RAMディスクを使います。