kindle起動時の文鎮化要因を改めて見直してみる

投稿者: | 2010年2月23日

フレームワークの起動処理を追ってみた

先日以下のような報告がありました。
「anti-bunchinを入れていたのでUSBネットで接続はできるが、すぐに端末の電源が切れてしまう。」
とのこと。
起動時の処理をしっかり把握できていなかったので、文鎮状態になるかどうかの観点で起動スクリプトの流れを追ってみた。
スクリプトの読める方は自分でスクリプトを読むほうがわかるかもしれないです。
今回確認したのは以下の2ファイル。
/etc/init.d/framework
/opt/amazon/ebook/bin/start.sh

以下長々と書いてますが、結論としては
以下2つを作成すれば、端末の自動電源断とリブートの繰り返しは防げると思われます。
/mnt/us/DONT_HALT_ON_REPAIR
/mnt/us/system/dont-restart-framework
あとはkindleとPCの接続方法さえ確保できればbrickからのrecoveryは可能。

起動スクリプト

kindleは通常ランレベル5で起動するのでrc5.dのS95frameworkがjava環境の立ち上げスクリプト。
シンボリックリンク元は
/etc/init.d/framework

Step1 /etc/init.d/framework

このスクリプトでは、画面の初期化処理とフレームワーク起動スクリプトの呼び出しを行っている。

その中に、
FRAMEWORK_REBOOT_COUNT_FILE(/var/local/system/.framework_reboots)
が2以上だとRepair Needed画面を出してhalt(システム終了電源断)しにいく処理がある。

これをやめるためには
_DONT_REPAIR_FILE(/mnt/us/DONT_HALT_ON_REPAIR)
を作ってやればいい。
ついでにFRAMEWORK_REBOOT_COUNT_FILEの削除も行っておくと良さそう。
v0.31以前のanti-bunchinハックにはこのファイルの確認処理が抜けているため、最初に書いたような報告をもらったんだと考えられる。

ちなみに、
/var/local/system/.framework_reboots
はRepairNeeded画面を見た時点でファイルが作成され、
起動時のkindleの初期化でもファイルの削除はされないので、2度以上文鎮化した場合にここで引っかかり、起動してもすぐに電源が切れる状態になります。

上記haltが走らなければ、以下のstart.shを呼ぶ。

Step2 /opt/amazon/ebook/bin/start.sh

1段階目が正常に通るとそこから
/opt/amazon/ebook/bin/start.sh
が呼ばれる。

最初でフレームワークの起動リトライカウント
FRAMEWORK_RETRIES_COUNT_FILE(/var/local/system/.framework_retries)
の確認が行われ、4以上だとフレームワークの起動をあきらめ、
FRAMEWORK_REBOOT_COUNT_FILE(/var/local/system/.framework_reboots)
に1or2を書き込みしてkindleのrebootを行う。
この流れでStep1のRepairNeeded画面へと移行する。

このstart.shでのrebootを回避するには
/mnt/us/system/dont-restart-framework
を作ってやればよい。
このファイルを作成するとフレームワークの起動エラー時にもstart.shのリトライをしなくなるため、
端末の強制再起動に移行しない。(=シリアルorUSBネットワークでアクセスできる)

ここまで問題が無ければフレームワークの起動が実行され、通常起動扱いになる。

ちなみに、start.shでは
/tmp/.framework_stop
を最初で確認し、ある場合このファイルを消して処理を抜けるのでフレームワークは起動しないようだが
どの場合にこのファイルが生成されるのかわかっていないので、今回そのルートは追っていない。

コメントを残す

メールアドレスが公開されることはありません。 が付いている欄は必須項目です