bug:刷机卡Logo界面,adb shell 报- exec '/system/bin/sh' failed: No such file or directory (2) -

当尝试通过ADB shell访问Android设备时遇到'exec '/system/bin/sh' failed: No such file or directory (2)'错误。问题可能与update.zip、recovery模式或ZIP包的完整性有关。尝试使用adb sideload方法,检查recovery日志,并考虑重新安装或修复system分区。

可能的问题:

1.update.zip 问题

2.recovery 问题

 

 

换!

 

 

 

有可能是不该取消cache.img的生成,不科学啊,,,那我换了img可能就可以。但为什么我换成adb sideload方式就可以的呢?到底有什么区别,是什么导致的sdcard方式卡在第一界面?

 

有可能是recovery 有问题,

symlink /sbin/busybox /system/bin/sh

原因分析:

有可能是recovery的原因,因为每次进入recovery都发现 /system 没有 mount ,

mount之后重启还是进不去。

 

munger:~/project/nexus4/B2G/out/target/product/mako/fota/fullimg$ adb shell
~ # cd cache/
lost+found/  recovery/
~ # cd cache/recovery/
/cache/recovery # ls
last_install  last_log.1    last_log.3    last_log.6    last_log.9
last_kmsg     last_log.10   last_log.4    last_log.7    log
last_log      last_log.2    last_log.5    last_log.8
/cache/recovery # 

 

adb sideload 进去的不用在rc下选mount /system也同样可以进去系统,郁闷。。。

排除zip有问题的可能性。

发生了什么。

 

看cache 下的Log发现:

cache里面的log:

刷分区的时候:

minzip: zlib inflate call failed (zerr=-3)

解压失败是这个意思?为什么?

 

有说是文件不完整,,,

zlib压缩库解压失败的问题

 

cache log:minzip: zlib inflate call failed (zerr=-3)

Flashing partition /boot
Flashing partition /data
minzip: zlib inflate call failed (zerr=-3)
Flashing partition /system
minzip: zlib inflate call failed (zerr=-5)
minzip: Can't extract entry to file.
script succeeded: result was [1.0]
Install from sdcard complete.

 

不对,,,应该是zip包的问题,之前用-full卡刷的 update.zip可以正常刷成功啊,那肯定是update.zip的问题了,醉了,绕半天,

用-fullimg就不行。

也不对,fullimg 的update.zip 用sideload 可以正常升级,包到底是有问题还是没问题,,矛盾,,,

 

 

-full 的log:

 

 

-fullimg 的卡刷Log

 

sizeload 的log:

root@mako:/cache/recovery # cat log                                            
I:using /data/media for /sdcard.
No files found.


Sideload started ...
Now send the package you want to apply
to the device with "adb sideload <filename>"...

sideload_service invoked
adbd exiting after successful sideload
E:listen on USB
E:userid is 2000
E:Event loop starting
I:sideload process finished
I:sideload thread finished
Restarting adbd...
Finding update package...
I:Update location: /tmp/update.zip
Opening update package...
Installing update...
Starting B2G FOTA: fullimg
Checking device
Device is compatible
Flashing partition /boot
Flashing partition /data
minzip: Size mismatch on inflated file (1894776832 vs -1)
minzip: Can't extract entry to file.
Flashing partition /system
script succeeded: result was [1.0]Rebooting...
I:using /data/media for /sdcard/0/clockworkmod/.recovery_version.
mkdir: can't create directory '/sdcard/0/': I/O error
root@mako:/cache/recovery # 

 

卡刷 Log:

/cache/recovery # cat log 
__bionic_open_tzdata: couldn't find any tzdata when looking for localtime!
__bionic_open_tzdata: couldn't find any tzdata when looking for GMT!
__bionic_open_tzdata: couldn't find any tzdata when looking for posixrules!
Starting recovery on Fri Apr 26 09:03:23 2019

framebuffer: fd 4 (768 x 1280)
ClockworkMod Recovery v6.0.4.7
recovery filesystem table
=========================
  0 /system ext4 /dev/block/platform/msm_sdcc.1/by-name/system 0
  1 /cache ext4 /dev/block/platform/msm_sdcc.1/by-name/cache 0
  2 /data ext4 /dev/block/platform/msm_sdcc.1/by-name/userdata 0
  3 /persist ext4 /dev/block/platform/msm_sdcc.1/by-name/persist 0
  4 /firmware vfat /dev/block/platform/msm_sdcc.1/by-name/modem 0
  5 /boot emmc /dev/block/platform/msm_sdcc.1/by-name/boot 0
  6 /recovery emmc /dev/block/platform/msm_sdcc.1/by-name/recovery 0
  7 /misc emmc /dev/block/platform/msm_sdcc.1/by-name/misc 0
  8 /radio emmc /dev/block/platform/msm_sdcc.1/by-name/modem 0
  9 /sbl1 emmc /dev/block/platform/msm_sdcc.1/by-name/sbl1 0
  10 /sbl2 emmc /dev/block/platform/msm_sdcc.1/by-name/sbl2 0
  11 /sbl3 emmc /dev/block/platform/msm_sdcc.1/by-name/sbl3 0
  12 /tz emmc /dev/block/platform/msm_sdcc.1/by-name/tz 0
  13 /rpm emmc /dev/block/platform/msm_sdcc.1/by-name/rpm 0
  14 /aboot emmc /dev/block/platform/msm_sdcc.1/by-name/aboot 0
  15 /tmp ramdisk ramdisk 0

W:Unable to get recovery.fstab info for /datadata during fstab generation!
W:Unable to get recovery.fstab info for /emmc during fstab generation!
W:Unable to get recovery.fstab info for /sdcard during fstab generation!
W:Unable to get recovery.fstab info for /sd-ext during fstab generation!
W:Unable to get recovery.fstab info for /external_sd during fstab generation!
I:Completed outputting fstab.
I:Connected to Vold..
I:200 0 Volumes listed.
I:Processing arguments.
I:Checking arguments.
I:device_recovery_start()
Command: "/sbin/recovery"

af.resampler.quality=4
ro.cm.device=mako
ro.cm.display.version=11-20140125-UNOFFICIAL-mako
ro.cm.version=11-20140125-UNOFFICIAL-mako
ro.qc.sensors.wl_dis=true
ro.sf.lc
<think>好的,我需要回答用户关于执行这些adb命令的意义和是否必须的问题。用户提到的命令是删除/system/framework下的arm、arm64、oat目录以及boot-framework.vdex文件。首先,我应该解释这些目录和文件的作用。 arm和arm64目录通常包含特定架构的二进制文件,比如.so库。oat目录可能存储预编译的ODEX或VDEX文件,这些文件在应用安装时生成,用于优化应用启动时间。boot-framework.vdex是Android 8.0引入的,包含预加载的类,加速系统启动。 接下来,用户问这些操作是否必须。需要说明在什么情况下需要删除这些文件。例如,在替换框架文件后,旧的二进制或预编译文件可能与新版本不兼容,导致崩溃。删除后系统会重新生成,但需要清除缓存并重启。同时,也要指出并非所有情况都需删除,比如只修改了Java代码而未改动native库时可能不需要。 还要注意潜在风险,比如删除后可能导致系统不稳定,直到重新生成相关文件。此外,可能需要关闭系统完整性保护,如关闭dm-verity和SELinux。 最后,整理相关问题,确保覆盖用户可能关心的点,如删除后的恢复、不同文件的作用、系统重启后的处理等。确保回答结构清晰,符合之前的格式要求。 </think>执行以下命令的意义及必要性分析: ```bash adb shell rm -rf /system/framework/arm # 删除armeabi-v7a架构的二进制文件 adb shell rm -rf /system/framework/arm64 # 删除arm64-v8a架构的二进制文件 adb shell rm -rf /system/framework/oat # 删除预编译的ODEX/VDEX文件 adb shell rm -rf /system/framework/boot-framework.vdex # 删除框架预加载类文件 ``` **意义解析:** 1. **架构相关二进制清理**: - arm/arm64目录包含平台相关native库(.so文件) - 当修改涉及底层架构代码或替换不同架构的框架时必须删除 - 系统重启后会从framework.jar重新提取对应架构的库 2. **预编译文件清理**: - oat目录存储Dalvik/ART预编译的ODEX/VDEX文件 - boot-framework.vdex是Android 8.0+预加载类的容器 - 修改框架代码后旧的预编译文件可能导致验证失败 3. **强制重新生成机制**: ```bash # 系统检测到缺失时会执行: dex2oat --dex-file=/system/framework/framework.jar \ --oat-file=/system/framework/oat/arm64/framework.oat # 并重建VDEX文件: vdexExtractor --input /system/framework/oat/arm64/framework.vdex ``` **是否必须?** - **必须执行**的情况: - 替换了不同架构的框架文件(如从armeabi切换到arm64) - 修改了包含native代码的框架模块 - 出现"bad checksum"或"Verification failed"错误 - **可选执行**的情况: - 仅修改纯Java代码且架构未变 - 确保已清除/data/dalvik-cache和/apexdata缓存 - 使用adb sync而非直接替换文件时 **风险提示:** 1. 删除后首次启动会触发完整优化过程,耗时约5-10分钟 2. 需配合`adb shell pm compile -m everything`手动触发重编译 3. Android 10+需处理Apex容器中的框架文件: ```bash # 检查Apex挂载点: mount | grep /apex/com.android.frameworks.base # 重新打包Apex需使用: apexd_util --rebuild-image /apex/com.android.frameworks.base ```
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值