[Android] 通常起動時とRecovery起動時のmountについて

今日はrecovery時のadbの使い方に載せようと思って書いていたけれど、余りに長くなるので別出しにした内容です。

secureなboot.imgの通常起動時にsystemをリマウントするにはこんな感じの長ったらしいコマンドが必要でした。

mount -o rw,remount /dev/block/mmcblk0p22 /system

リカバリー時にsystemをマウントするにはこんな感じのコマンドでした。

mount /system

ここで同じmountなのにrecovery時は何故こんなに簡単なのかと疑問を持った方はいませんか？
そもそもデバイス名の記載がいらないのは何故でしょうか？
では実験してみましょう。
「adb reboot recovery」でrecoveryに入り、
「adb shell」上で「mount a」と入力してみましょう。

mount a
mount: can't find a in /etc/fstab

当然ですが怒られました。が、謎は解けましたね。
/etc/fstabに記載されている情報を元にmountを行っているんです。
でも通常起動時には/etc/fstabが無いんですよね。これを引っこ抜いて通常側にも入れてみましょうか。

以下はHTC Sensationでの例です。shellに入っている人は「exit」で抜けてくださいね。

adb pull /etc/fstab
adb reboot

ここで再起動がかかります。

adb shell mount -o rw,remount /dev/block/mmcblk0p22 /system
adb push fstab /etc/
adb shell chmod 644 /etc/fstab
adb reboot

はい、これでOKです。
本当はパーミッション変更する必要も無いですが、気持ち悪いので一応ね。
/etcが存在しない機種の人は残念ですが今回は見送りです。
もしboot.imgのramdiskをいじれる人だったら、/system/etcをシンボリックリンクすれば出来ますよ。
これで出来るようになったのでしょうか？「adb shell」に入りますよ。

umount cache

成功しましたね。「mount」の一覧にcacheもないし、「ls cache」としても何もありません。
アンマウントしっぱなしじゃ不味いのでマウントしますよ。

mount cache

怒られました。
busyboxの所でも書いた事ですが、toolboxの/system/bin/mountとbusyboxの/system/xbin/mountがあるんです。
上記のコマンドだとtoolbox側が呼ばれているんですが、こいつには/etc/fstabをみる仕掛けがありません。
この状態でbusybox側を呼び出すにはこうします。

busybox mount cache

成功しました。
でも、ここでわざわざcacheパーティーションを選んだのには理由があります。
試しに「umount /system」と入力してみても失敗するはずです。
これはumountしようとするパーティーション内のファイルが使用中なので実行出来ないんです。
いきなりファイルが消えたらシステムが異常終了してしまいますので当然と言えば当然です。
systemの場合はリマウントですね。

busybox mount -o rw,remount /system

ちょっとは楽になったでしょうか？デバイス名を覚える必要が無くなっただけましかな？

これをやって「 fstab入れたんだぜ！ 」と他人に言っても何の事やら分からないおかしな奴としか思われないので、完全な自己満足ですね。
Androidのカスタマイズと言うとカスタムROMを入れたりパフォーマンス上げたり派手な事ばかりが目に付きますが
こんな地味な世界もあります。