PC UNIXの起動と起動ファイルの解読

YAMAMORI Takenori ●yamamori

●カーネルの起動からinitの起動まで(起動10%〜50%)

ブートローダがカーネルを読み込み,カーネルに制御が移ると, カーネルはデバイスドライバを含めたさまざまな初期化を行ないます. ひととおりの初期化が終ると,カーネルはrootファイルシステムを マウントします.

○rootファイルシステムをマウントするには

rootファイルシステムは通常はハードディスク上にあるため, カーネルはこの時点で初めてハードディスクにアクセスすることになります. ところで,カーネル自体はブートローダによって,BIOSコールを使って読み込まれ ましたが,カーネルはもうBIOSを使用しません. したがって,カーネルがハードディスクにアクセスするには, そのためのデバイスドライバが必要になります. このことはとくに,SCSIのハードディスクをrootファイルシステムとして マウントする場合に注意するべき点です.

※注
別の例として,rootファイルシステムをNFSでマウントするディスクレスマシンでは, ネットワーク関係のドライバがこの時点で有効になっていて, カーネル自身によってネットワークインターフェイスが立ち上げられている 必要があります.

デバイスドライバの読み込みは,次のように各OSごとに異なる方法が用いられています.

FreeBSDの場合,多くのデバイスドライバはカーネルに静的に組み込まれており, そのままrootファイルシステムにアクセスすることができます.

Solarisではデバイスドライバがカーネル本体とは別のモジュールに 分かれていますが,ブートローダがファイルシステム内にアクセスし, カーネルのほかにSCSIなどの各種デバイスドライバも読み込むため, 問題なくrootファイルシステムをマウントできるようになっています.

Linuxでは,initrd(初期RAMディスク)を用い, initrdの中に必要なSCSIドライバを組み込んでおくという 独特の仕組みを用いています.
(コラム「Linuxのinitrdについて」参照)

○rootファイルシステムのマウント

rootファイルシステムのマウントは,OSの起動処理の中でのひとつの関門であり, この段階で頻発する有名なエラーメッセージがあります.それは, 「Kernel panic: VFS: Unable to mount root fs on ...」(Linuxの場合) というもので,これは,rootファイルシステムのマウントに必要なドライバや カーネルのコンフィギュレーション,カーネルオプション,initrd,LILOの設定などが 不適切で,rootファイルシステムのマウントに失敗した時に起こります. もしかすると,これの対処方法がわからず,やむなくOSごと再インストール してしまった人もいるのではないでしょうか(その必要はないのですが…).

ここで,カーネルによるrootファイルシステムのマウントは, 通常の書き込み可でのマウントではなく,リードオンリ状態でのマウントです. /sbin/initもこの状態のまま実行されます. その理由についてはコラム「fsckのトリック」を御覧ください.

○initの起動

rootファイルシステムが正常にマウントされると, カーネルは,起動後初めてのプロセスとして/sbin/initを実行します. このため,initのプロセスID(pid)は必ず1になります (ただし,pid 0のカーネルプロセスが存在することもあります)

initは,このあとrcスクリプトを実行し, rcスクリプトの中からは各種デーモンの起動などが行なわれます. またinitは,すべてのプロセスの祖先となり, また,親プロセスが先に終了してしまったプロセスの親の役目も果たします.

このような重要な役目を果たすinitですが, 実はinitの代わりに普通のシェルを指定し, initなしの環境でOSを起動することも可能です.
(コラム「initなしで直接シェルを起動」参照)


To『PC UNIXの起動と起動ファイルの解読』[index]


このページは、技術評論社 「SoftwareDesign 2001年9月号、『起動ファイルから解読するPC UNIX』の原稿を元に、Web 用に再構成したものです。
To 謎の処理系 SunOS 4.1.4 [Home]
yamamori