PC UNIXの起動と起動ファイルの解読 |
YAMAMORI Takenori ●yamamori |
ブートローダがカーネルを読み込み,カーネルに制御が移ると, カーネルはデバイスドライバを含めたさまざまな初期化を行ないます. ひととおりの初期化が終ると,カーネルはrootファイルシステムを マウントします.
rootファイルシステムは通常はハードディスク上にあるため, カーネルはこの時点で初めてハードディスクにアクセスすることになります. ところで,カーネル自体はブートローダによって,BIOSコールを使って読み込まれ ましたが,カーネルはもうBIOSを使用しません. したがって,カーネルがハードディスクにアクセスするには, そのためのデバイスドライバが必要になります. このことはとくに,SCSIのハードディスクをrootファイルシステムとして マウントする場合に注意するべき点です.
デバイスドライバの読み込みは,次のように各OSごとに異なる方法が用いられています.
FreeBSDの場合,多くのデバイスドライバはカーネルに静的に組み込まれており, そのままrootファイルシステムにアクセスすることができます.
Solarisではデバイスドライバがカーネル本体とは別のモジュールに 分かれていますが,ブートローダがファイルシステム内にアクセスし, カーネルのほかにSCSIなどの各種デバイスドライバも読み込むため, 問題なくrootファイルシステムをマウントできるようになっています.
Linuxでは,initrd(初期RAMディスク)を用い,
initrdの中に必要なSCSIドライバを組み込んでおくという
独特の仕組みを用いています.
(コラム「Linuxのinitrdについて」参照)
rootファイルシステムのマウントは,OSの起動処理の中でのひとつの関門であり, この段階で頻発する有名なエラーメッセージがあります.それは, 「Kernel panic: VFS: Unable to mount root fs on ...」(Linuxの場合) というもので,これは,rootファイルシステムのマウントに必要なドライバや カーネルのコンフィギュレーション,カーネルオプション,initrd,LILOの設定などが 不適切で,rootファイルシステムのマウントに失敗した時に起こります. もしかすると,これの対処方法がわからず,やむなくOSごと再インストール してしまった人もいるのではないでしょうか(その必要はないのですが…).
ここで,カーネルによるrootファイルシステムのマウントは, 通常の書き込み可でのマウントではなく,リードオンリ状態でのマウントです. /sbin/initもこの状態のまま実行されます. その理由についてはコラム「fsckのトリック」を御覧ください.
rootファイルシステムが正常にマウントされると, カーネルは,起動後初めてのプロセスとして/sbin/initを実行します. このため,initのプロセスID(pid)は必ず1になります (ただし,pid 0のカーネルプロセスが存在することもあります)
initは,このあとrcスクリプトを実行し, rcスクリプトの中からは各種デーモンの起動などが行なわれます. またinitは,すべてのプロセスの祖先となり, また,親プロセスが先に終了してしまったプロセスの親の役目も果たします.
このような重要な役目を果たすinitですが,
実はinitの代わりに普通のシェルを指定し,
initなしの環境でOSを起動することも可能です.
(コラム「initなしで直接シェルを起動」参照)