这个帖子和其他的帖子一样，在先决条件里提到了一样“要可以 CWM Recovery”。要知道，经过前边的折腾，咱偏偏就是没搞定自定义 Recovery。不过这困顿之际，另一个问题浮现出来，到底要干些什么事情呢，以至于非要用自定义 Recovery 来完成，难道已经在手的 root 身份还不够吗？从安装步骤上看，似乎硬件上只需要一台 root 过的手机即可，而软件的准备也只是一个 Debian 镜像文件和一个名为 easy-signed 的 ZIP 压缩包。很显然，压缩包里的货色是重点，到底有些什么呢？下载下来解开看看。

压缩包的顶级路径下，有五个目录和一个脚本文件 webtopmod.sh。既然原帖中说是要让 Recovery “安装”这个压缩包，很显然，这些包里的文件会被进行某种处理，融入到系统中去。那个名为 webtopmod.sh 的脚本文件当然很可疑，但这个名字显然不是一个通用性的名字，也就是说，如果不是在别的什么地方指定了要执行这个文件，那 Recovery 绝不应该会自行将之认作应该运行的程序（要是名字是 update.sh 到说不定有此可能）。那五个目录分别是 etc、home、opt、usr、META-INF。查看这个压缩包的奥秘时，高人其实也在，他一眼就看出这个 META-INF 的目录怕事有蹊跷，待 META-INF、com、google、android 这么一层层双击进去，眼前顿时了然，有一个名为 update-binary 的文件，一个名为 updater-script 的文件。毋庸置疑，前者是个脚本解释器，而后者则是要执行的脚本，这个脚本文件就是我们要寻找的东西。

打开脚本文件仔细查看，发现其使用某种特定语法的脚本书写而成，但相当易懂。其中调用的操作颇为有限，几乎都是在 root 下可以轻易做到的事情，有文件复制、文件移动、文件删除、目录创建、文件/目录的权限/属主设置、程序执行、分区加载/卸载、从压缩包中提取文件到指定目标路径等，另外还有一些和界面交互有关的则一概未予考虑。两相比照，三太爷这 Linux 菜鸟战战兢兢地把它翻译成了 shell 脚本，与此同时，下载帖子里提到的 Debian 镜像文件也已完成（原贴里的百度云盘链接已经失效，但其引用的英文原帖中的下载链接依然健在：http://droid.makrit.net/WebTopMOD/WebTopMOD-20110707.7z）。找来一张 16GB 的 TF 卡，把映像文件小心翼翼地解压到卡上的 WebTopMOD 目录下，原来的 updater-script 是要从压缩包里提取文件的，现在 shell 脚本解压缩就不那么方便，所以将必要的文件也都从 easy-signed.zip 中事先解压了出来，在卡上的 WebTopMOD 目录下新建了一个 install 目录，把这些文件（其实就是上文提到的 etc、home、opt、usr 四个目录和那个 webtopmod.sh 脚本文件了）仍然保持原来的目录结构不变复制过来。webtopmod.sh 脚本在 Recovery 安装的方式下会被 updater-script 所调用，而今我老人家正好借尸还魂，把根据 updater-script 改写的脚本与 webtopmod.sh 中的脚本一并整理为新的 webtopmod.sh。其完整内容见下：

#!/sbin/busybox sh

echo
echo This script SHOULD be run under root.
echo Based on SyR89 WTMod version 0.2.5.7
echo By dandycheung, 2014-01-19
echo

echo Backuping files...

mkdir /osh/opt/WebTopMOD
mkdir /osh/opt/WebTopMOD/backup/
mkdir /osh/opt/WebTopMOD/root/
mkdir /osh/opt/WebTopMOD/icons/
mkdir /data/home/adas/.gconf/apps/avant-window-navigator/window_manager

cp "/data/home/adas/.gconf/apps/avant-window-navigator/window_manager/%gconf.xml" "/osh/opt/WebTopMOD/backup/%gconf.xml"
cp /osh/etc/sudoers /osh/opt/WebTopMOD/backup/sudoers
mv /osh/sbin/tomoyo-init /osh/opt/WebTopMOD/backup/tomoyo-init
mv /osh/sbin/tomoyo-start /osh/opt/WebTopMOD/backup/tomoyo-start

echo Copying files...
cp usr/sbin/linux /osh/usr/sbin/linux
cp usr/bin/lxterminal /osh/usr/bin/lxterminal
cp usr/bin/xmessage /osh/usr/bin/xmessage
cp "home/adas/.gconf/apps/avant-window-navigator/window_manager/%gconf.xml" "/data/home/adas/.gconf/apps/avant-window-navigator/window_manager/%gconf.xml"
cp etc/sudoers /osh/etc/sudoers
cp usr/share/applications/linux.desktop /osh/usr/share/applications/linux.desktop
cp usr/share/applications/leafpad.desktop /osh/usr/share/applications/leafpad.desktop
cp opt/WebTopMOD/icons/linux.png /osh/opt/WebTopMOD/icons/linux.png

echo Setting proper permissions...

chown 5000.5000 /osh/usr/sbin/linux
chmod 755 /osh/usr/sbin/linux

chown 5000.5000 /osh/usr/bin/lxterminal
chmod 755 /osh/usr/bin/lxterminal

chown 5000.5000 /osh/usr/bin/xmessage
chmod 755 /osh/usr/bin/xmessage

chown 0.0 /osh/etc/sudoers
chmod 440 /osh/etc/sudoers

chown 0.0 /osh/usr/share/applications/linux.desktop
chmod 644 /osh/usr/share/applications/linux.desktop

chown 0.0 /osh/usr/share/applications/leafpad.desktop
chmod 644 /osh/usr/share/applications/leafpad.desktop

chown 5000.5000 /osh/opt/WebTopMOD/
chmod 777 /osh/opt/WebTopMOD/

chown 5000.5000 "/data/home/adas/.gconf/apps/avant-window-navigator/window_manager/"
chmod 700 "/data/home/adas/.gconf/apps/avant-window-navigator/window_manager/"
chown 5000.5000 "/data/home/adas/.gconf/apps/avant-window-navigator/window_manager/%gconf.xml"
chmod 700 "/data/home/adas/.gconf/apps/avant-window-navigator/window_manager/%gconf.xml"

echo
echo Done!

至此，TF 卡准备完工，将之插入 MB860，重启 MB860，然后将之 USB 连接到电脑。运行 adb shell，su 为 root 身份，将路径 cd /sdcard-ext/install，按道理讲，直接运行 ./webtopmod.sh 即可。不过说来不怕大家见笑，三太爷这脚本写完之后，着实生怕直接运行会有差池，事实上是将其中所有代码逐行复制到 adb shell 里运行的（echo 行除外），所幸百分之百成功。这里，如果有哪位读者君是跟着实际操作的，请补上三太爷当时漏了的一个步骤：重启手机。

把 MB860 插入笔记本底座（或者多媒体底座、或者已经破解之后可以正常进入 WebTop 模式的 HDMI 设备），则任务栏的右侧，leafpad、lxterminal 以及 Linux 这三个图标应该已经好端端地显示出来了。点击 Linux 的那个企鹅图标，则以下步骤与原帖完全一致，照做即可。

不过目前三太爷的 MB860 状态是，xfce4 安装完成，但 sudo xfce4-session 会导致手机重启。cat /etc/debian 显示 Debian 版本为 7.8 是不是太新了点？有待和高人抽空一起探讨。

看着这个名为 1FF-olympus_hktw-user-2.3.4-4.5.2A-74_OLH-25-release-keys-signed-Retail-05.sbf 的 1.5GB 的大文件，当务之急是要找个工具能对它进行分析，对其中的部分进行提取。迅速到网上做了检索，百度经验里有一篇文章进行了讲解，《怎样解包和打包摩托罗拉的 sbf 文件》，里面提到的工具叫做 MotoAndroidDepacker。三太爷看着文章里的插图就乐开了花，Recovery 映像对应哪个文件清清楚楚。兴冲冲地按这个名字搜索并下载了工具，让它打开文件的时候竟然无耻地说打开失败！还好我老人家脑速飞快，瞬间想到工具的版本可能有问题，一看信息，是个 1.2 alpha 的版本，感觉就有点不靠谱。手动把版本号加到 1.3 再搜，竟然真有（http://bbs.mfunz.com/thread-186627-1-1.html），这次下载下来，果然就能打开了。

老天爷的考验无处不在。工具确实可以把 sbf 拆解为若干文件，但是信息表里却并没有说哪个文件是 Recovery 分区的映像文件。只好想招，从大小上着手。先去看了看 CWM Recovery 文件的大小，大概是 3MB 多，于是在分拆出来的一堆文件里找和这个尺寸相近的，发现了两个 3MB 左右的文件（此处三太爷犯了个错误，后文再说）。用 HxD 打开观察，挑中了一个感觉更像是 Recovery 映像的，依据是在里面找到了“Recovery”的字串。用 adb push 把它传到了手机上，命名为 recovery.img，然后 adb shell，su 切换到 root 身份，谋划到底该把它刷到哪个分区里。既然文件是按大小选出来的，那何不选定分区也按大小来呢？使用 cat /proc/partitions 命令，发现 mmcblk0p1 恰好在 3MB 与 4MB 之间。为了确认不会刷坏，还特意先 dd 它之前的内容到一个文件里进行了查看，所有字节都是 0。这种情况有两个可能，一是这个分区并非 Recovery 分区，二是固件管理器当初信誓旦旦说的刷入成功其实是个假象。我选择了相信后者，与其说是相信，不如说是宁可相信。其实心里还有另一重考虑，一个全部内容为零的分区，即使刷错了，也不应该有太大的恶劣后果。用 dd 命令把从电脑上传来的 recovery.img 刷到了 mmcblk0p1 分区，成功；重启手机，试图进入 Recovery 模式，失败，错误没变。很显然，那个分区不对。

又经过一些试验，突然想到可以用内容比对的方式来确定。一边是固件管理器下载下来的 CWM Recovery 映像文件（按照常理推测，软件不会自动把下载的此类文件删除，而事实上也很轻松就找到了），一边是依次检索各个分区当前的内容，哪个分区对上了，哪个就是 Recovery 分区。首先还是根据大小，选了 3 个分区来做比较，最后终于确定到了 mmcblk0p10。把 recovery.img 刷到 mmcblk0p10 分区，重启，在菜单里选择进入 Recovery 模式，Failed to boot 2 字样消失，成了 starting RSD protocol support。我老人家瞬间明白：1、分区找对了，2、recovery 映像文件找错了。上文说到三太爷曾犯了个错误，其实就在这个地方。如果稍微再仔细一点，从 cat /proc/partitions 命令的输出结果中就应该能看到并联想到，从底包中提取出来的映像文件的大小，和它对应的分区的大小应该是一致的。那么，当时看到 CWM Recovery 的映像文件大小接近 4MB，那么原始 Recovery 的映像文件很显然就不会是更小的文件。

从底包中拆解出来的文件中，大小与 mmcblk0p10 分区匹配的有两个，一个名为 CG58.smg，一个是 CG59.smg，那么哪个才是 Recovery？现在就好办了，既然有两个大小一样的文件，显然手机上就还会有一个和 mmcblk0p10 大小一样的分区（事实上是 mmcblk0p11），把 mmcblk0p11 的内容 dd 转储出来，发现与 CG59.smg 的内容完全匹配，从而得出 CG58.smg 就是原装的 Recovery 映像。再次用 adb 将之传送，并 dd 到 mmcblk0p10 上，重启尝试进入 Recovery 模式，那个摆了个三角架的小机器人终于又出现了。所有这些情况，表明 MB860 的 bootloader 很强悍，对系统做了非常严格的控制，常规方法无法更改，强行更改则无法运行。

兜兜转转，回到原点。高人说：1、这是折腾的真意；2、这是盘旋上升。顺便说一句，最开始刷错的那个分区，我老人家也在第一时间纠正了：dd if=/dev/zero of=/dev/block/mmcblk0p1。

中间其实还了解到一些别的知识，例如 CWM Recovery 究竟是如何满足大家的补丁需求的。既然刷自定义的 Recovery 受阻，三太爷将挑战一下如何把需要 Recovery 完成的工作在 root 下完成。

目前只是了解了些皮毛，接下来需要一些实践。三太爷到底能不能仅靠有 root 就把 Debian 部署到 MB860 上且与 WebTop 和平共处呢？欲知后事如何，且听下回分解。