「Ubuntu 12.10、起動時にChecking battery state...で停止する」の調査（３）

はじめに

前回の続きで、どこまで起動の処理ができているのか起動スクリプトを確認して原因を探した。

対象の起動スクリプトを抽出する

正常起動した場合のランレベルが２だったので、「/etc/rc2.d」以下の起動スクリプトが対象となる。

ランレベル

$ runlevel
N 2

起動スクリプト

$ ls -al /etc/rc2.d
drwxr-xr-x   2 root root  4096 1月 1 00:00 ./
drwxr-xr-x 145 root root 12288 1月 1 00:00 ../
lrwxrwxrwx   1 root root    15 1月 1 00:00 K20saned -> ../init.d/saned*
lrwxrwxrwx   1 root root    27 1月 1 00:00 K20speech-dispatcher -> ../init.d/speech-dispatcher*
lrwxrwxrwx   1 root root    18 1月 1 00:00 K30pppd-dns -> ../init.d/pppd-dns*
-rw-r--r--   1 root root   677 1月 1 00:00 README
lrwxrwxrwx   1 root root    14 1月 1 00:00 S20avgd -> ../init.d/avgd*
lrwxrwxrwx   1 root root    20 1月 1 00:00 S20kerneloops -> ../init.d/kerneloops*
lrwxrwxrwx   1 root root    17 1月 1 00:00 S20postfix -> ../init.d/postfix*
lrwxrwxrwx   1 root root    15 1月 1 00:00 S50rsync -> ../init.d/rsync*
lrwxrwxrwx   1 root root    19 1月 1 00:00 S70dns-clean -> ../init.d/dns-clean*
lrwxrwxrwx   1 root root    14 1月 1 00:00 S75sudo -> ../init.d/sudo*
lrwxrwxrwx   1 root root    22 1月 1 00:00 S99acpi-support -> ../init.d/acpi-support*
lrwxrwxrwx   1 root root    21 1月 1 00:00 S99grub-common -> ../init.d/grub-common*
lrwxrwxrwx   1 root root    18 1月 1 00:00 S99ondemand -> ../init.d/ondemand*
lrwxrwxrwx   1 root root    18 1月 1 00:00 S99rc.local -> ../init.d/rc.local*

S99である S99acpi-supportまで実行されているが分かっているので、残りの同じ実行順の起動スクリプトを確認する。

対象の起動スクリプトの処理を確認する

No	Script	Description
1	/etc/init.d/grub-common	Record successful boot for GRUB
2	/etc/init.d/ondemand	CPU周波数が動的に変化する設定にする
3	/etc/init.d/acpi-support	省電力モードの切り替えスクリプト
4	/etc/init.d/rc.local	特定サイトに特化したコマンドを記述するスクリプト

grub-commonは何をしている？

OSの起動まで正常に行えた事をGRUB*1の環境ファイル「/boot/grub/grubenv」に記録している。
OSの起動で問題があり次回の起動時にGRUBのメニュー画面を表示する必要がある場合「grubenv」に「recordfail」が設定される。
このスクリプトでは「grubenv」から「recordfail」の設定を取り消して次回の起動でGRUBのメニューが表示されないようにしている。
Manual grub

ondemandは何をしている？

負荷によりCPU周波数を切り替える機能があり、その設定を強制的にondemandに設定している。
処理としては「/sys/devices/system/cpu/cpu*/cpufreq/scaling_governor」に「ondemand」を設定している。
cpu*はコアの分だけ(0～)繰り返して全コアを同じ設定にしている。

rc.localは何をしている？

自身の環境では「/etc/rc.local」が存在したら実行するだけの処理になっていた。
「/etc/rc.local」は何も追加していないので正常を返すだけの「exit 0」のみ。

今回の調査結果

起動スクリプトには障害や常駐するような処理は無かった。
では、どこで障害が発生しているのか？
表示されないログイン画面はどこで起動しているのか？
改めて、Ubuntuの起動の仕組みを調べる必要がある。

おまけ

「rc.local」の説明には最後に実行されるスクリプトになっている。
起動スクリプトの実行順が「Knn」「Snn」の"nn"が小さい順であることは分かるが同じ番号の場合、それ以降の名前で昇順になるのだろうか…
実際に各起動スクリプトを呼び出している「/etc/init.d/rc」では「for s in /etc/rc$runlevel.d/S*」でファイルリストを取得している。

$ bash <<< 'for s in /etc/rc2.d/S*; do echo $s; done'
/etc/rc2.d/S20avgd
/etc/rc2.d/S20kerneloops
/etc/rc2.d/S20postfix
/etc/rc2.d/S50rsync
/etc/rc2.d/S70dns-clean
/etc/rc2.d/S75sudo
/etc/rc2.d/S91apache2
/etc/rc2.d/S99acpi-support
/etc/rc2.d/S99grub-common
/etc/rc2.d/S99ondemand
/etc/rc2.d/S99rc.local

この結果を見る限りでは番号順・名前順で昇順である。
しかし「rc.local」より後にくる名前を付けた場合はどうなるのか？

*1:GRnad Unified Bootloader