Linuxブートシーケンスまとめ。GRUBと起動トラブルのメモ

menuentry 'Ubuntu, with Linux 2.6.32-32-generic' --class ubuntu --class gnu-linux --class gnu --class os {
	recordfail
	insmod raid
	insmod mdraid
	insmod ext2
	set root='(md1)'
	search --no-floppy --fs-uuid --set dbba431a-7cc1
	linux   /boot/vmlinuz-2.6.32-32-generic root=UUID=dbba431a-7cc1 ro video=800x600-16
	initrd  /boot/initrd.img-2.6.32-32-generic
}
※UUIDは長いだけなので一部省略しました。

この中で重要な情報は、当然 linux と書かれたカーネル指定ですが、同じぐらい重要なのが initrd です。これについては後で述べます。

recordfail は grub に対するオプションです。debian 6(squeeze)のgrubでは無効でした。
insmod raid, insmod mdraid は grub に対するオプションです。モジュールを読み込めという指定ですが、このモジュールは /boot/grub/*.mod に実際に存在します。

set root='(md1)' はルート(/)ファイルシステムの存在するパーティションを指定します*2。指定できるデバイスの一覧は、GRUBコンソールモードで「ls」を入力すると出てきます。これはGRUBに対する指定です。

HDDのパーティションを指定するときは、set root='(hd0,msdos2)'という風に指定します。これは /dev/sda2 を指定するようなものです。ですが、2番目以降のHDDから起動した場合、そのHDDが例え /dev/sdb に相当するものでも、GRUBを起動しているHDDは常に hd0 になります。注意してください。hd1以降は、GRUBを起動しているHDDを除いてデバイス順に並べたものです。また、(hd0,1)（/dev/sda2相当）といった旧来のGRUB方式の指定は無効です。これも注意してください。

search という以前のGRUBには無かった行は「set root=」の代替手段を示しています。「set root=」が指定されないとき、または「set root=」で指定されたデバイスが無効であるとき、GRUBは「--set」以降で指定されたUUIDを持つファイルシステムを探索し、それをGRUBに対するルート(/)ファイルシステムだと解釈します。

linux 行にある「root=UUID=dbba431a-7cc1-a56e」はlinux kernelに対するルート(/)ファイルシステムの指定でまた意味が違ってきます。

GRUBのルート(/)ファイルシステムとはなんぞや？

GRUBの重要な役割はカーネルをメモリに展開（ロード）して、起動シーケンスをカーネルに渡すことです。ロードするカーネルはどこに書かれているかというと、HDDのパーティション内に書きこまれています。

GRUBはファイルシステムを（insmodすればRAIDすらも）理解することができますが、膨大なファイルの中からカーネルを自動で探すことはできません。カーネルがどこに存在するのかきちんとGRUBに教える必要があります。

GRUBのルート(/)ファイルシステムとは、Linuxカーネルをロードするときのファイルシステムの基準(/)を指定するものです。もし、/boot パーティションが /dev/sda1 に分かれていて、/dev/sda3 がLinuxのルート(/)ファイルシステムならばGRUBは次のように書かれます。

set root='(hd0,msdos1)'
linux   /vmlinuz-2.6.32-32-generic root=/dev/sda3 ro
initrd  /initrd.img-2.6.32-32-generic

もしsearch行を書くなら、そこでは /dev/sda1のUUID なりを記述します。

また見て分かるとおりlinux, initrd で書かれたパスが異なっています。これはroot='(hd0,msdos1)'で指定した位置を基準(/)としたパスで記述する必要があるからです。

Linuxカーネルとカーネルモジュール

GRUBオプションにより正しくLinuxカーネルを発見できたら、GRUBはそれをファイルシステムからロードし、また同時にinitrdが指定されていればinitramfsを展開します。

Linuxが起動しないというトラブルにも何段階かありますが、カーネルがとりあえずロードされるなら、GRUBの設定には（linux行のroot指定やinitrdが合っていれば）問題はないと言えます。

昔のLinuxカーネルはモノリシックな作りになっていて、カーネルが標準で対応していないデバイスを使いたい場合、多くはカーネルを全部つくり直す必要がありました*3。かといって予めすべてのデバイスに対応するようなカーネルを作っておくとカーネルが大きくなってそれはそれでメモリを圧迫しましたし起動もロードも遅かったのでした*4。

今はカーネルモジュール(*.ko)と言って、デバイスドライバの部分を切り離して別ファイルとして置いておき、その特定のデバイスを見つけ必要になったとき自動ロードするようになりました。

しかし、これには大きな問題があります。カーネルモジュールは当然ファイルシステムのどこかに置かれているわけですが、ファイルシステムを認識する前に必要なモジュールや設定情報はどうやって知ればいいのでしょうか？

例えば、標準のディスク（ATAやSATAのext3やext4）なら当然カーネルに組み込まれていますが、ソフトウェアRAIDや専用のRAIDカードから起動されたとき、モジュールを読み込もうにもモジュールを読み込むのに必要なデバイスドライバをカーネルが持っていないので起動できません。*5

GRUBの「root=」で正しくLinuxルート(/)ファイルシステムを指定しているのに、ルート(/)ファイルシステムのマウントに失敗して起動できない原因はここにあります。

Begin: Mounting root file system...

と表示される当たりで起動シーケンスが止まってしまうのです。

しかしだからと言って、起動時に必要になるかもしれないすべてのデバイスをカーネルに組み込むのも考えものです。メモリとリソースのムダでしかありません。これを解決するためLinux2.6から導入されたのがinitramfsです。

initramfs

カーネル起動時にあらかじめメモリに展開することでファイルシステムを構成する仕組みです。CDブートするディスクトップ環境とかでも使われてるメモリファイルシステムです。GRUBで指定する initrd行がそれです。

メモリなのでカーネル起動時でもファイルを参照することができ、必要に応じてモジュールをロードできます。そして、本来のルート(/)ファイルシステムをマウントする段階で破棄されますのでメモリを圧迫することもありません。

いいこと尽くめなのですが、１つだけ難点がありあらかじめinitrd.imgとしてRAMファイルシステム全体を固めておく必要があります。UbuntuやDebianでは次のコマンドを使用します。

# update-initramfs -u

設定等は /etc/initramfs にありますが特にいじる必要はなさそうです。

update-initramfsは次のような場合に実行する必要があります。

カーネルモジュールを手動追加したり、blacklist登録したとき。
ソフトウェアRAIDを組んでいて、RAID構成情報(/etc/mdadm/mdadm.conf)を変更した場合。→詳細はこちら

Begin: Mounting root file system...

が表示されるまでが、initramfsでの動作になります。

復旧時に大事なchrootする方法

/dev/md1 が復旧対象のLinuxのルートファイルシステムです。

#!/bin/sh
mount /dev/md1 /main-root
mount --bind /dev /main-root/dev
mount --bind /dev/pts /main-root/dev/pts
mount --bind /proc /main-root/proc
mount --bind /sys /main-root/sys
chroot /main-root

mount --bindで、chroot後もデバイスを参照できるようにしてあげるのがコツらしい。

		2011/06
日	月	火	水	木	金	土
			1	2	3	4
5	6	7	8	9	10	11
12	13	14	15	16	17	18
19	20	21	22	23	24	25
26	27	28	29	30