为了激活 init.d 和 crontab，足足忙了一整天。
最开始使用的是360的一键root，KingRoot的授权。但是这个工具没有使用install-recovery.sh。有一个类似的install_recovery.sh。但无法修改，导致 Term-init.sh 运行后init.d没有激活。在手动修改也失败的情况下，放弃了。准备刷入root包。
下载了 Root4.3.zip 之后，发现系统自带的recovery 无法刷入。尝试刷入的时候又发现，fastboot 是lock的，只能先解fastboot。成功解锁后，又无法刷入新的 Recovery。
尝试N 次之后，发现原来的脚本有问题。改成下面的代码之后就OK了。
fastboot.exe erase recovery
fastboot.exe flash filename.img
fastboot.exe boot filename.img
之后，成功刷入 ROOT4.3 。双清之后进入系统，发现居然Root不完全....RE 和 superSU 都无法运行。
抱着侥幸心理，又用360的一键root，重试了一次。这次发现 install_recovery.sh 的内容和之前不同，不再是个空文件。由于之前已经运行过 term-init.sh，/system/etc/init.d/ 和 /system/bin/sysint 已经存在。抱着试试看的心理在个文件里加入了激活init.d的代码。
func_start_kr() {
/system/xbin/krdem kingroot-dev 100002 1
/system/etc/kds --global-daemon 1
run-parts /system/etc/init.d/
}
居然就这么奇迹般的成功了......
从结果看来，有两个大概齐的结论：
-
install-recovery.sh 这个文件和安装的 Recovery 有关。有可能系统自带的 Recovery 没有在系统启动时激活。
-
KingRoot的授权，不知出于什么目的，没有使用 recovery-install.sh。而是用了 recovery_install.sh。而term-init.sh 重写了 recovery-install.sh。可能对KingRoot产生了影响。下次如果发现授权的app是 KingRoot 时，应该把 term-init.sh 进行修改，不可以覆盖以前的文件。或者向这次一样，先运行一次 term-init.sh -> 重新 root -> 手动加入 run-parts 命令。
两者应该是或的关系，再有下一台需要root的机器时，会多加留意。
总的来说，一天的时间，终于把这个问题解决啦~~~所有用到的文件，和以防万一的防砖包都在这里了。链接: http://pan.baidu.com/s/1jH3VdmY 密码: q8fw 真希望以后再也用不到。