adb remount之后,OTA 升级失败的问题

Posted xuyewen288

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了adb remount之后,OTA 升级失败的问题相关的知识,希望对你有一定的参考价值。

MTK平台,remount后ota升级失败


userdebug版本,remount升级失败

adb root
adb remount
然后push了一堆东西进去,ota升级的时候会报空间不够,我们先看mtk的debug log

 473   473 I update_engine: [1101/114216.247577:INFO:dynamic_partition_control_android.cc(197)] Loaded metadata from slot A in /dev/block/platform/bootdevice/by-name/super
 473   473 I update_engine: [1101/114216.247946:INFO:boot_control_android.cc(312)] Removing group main_b
 473   473 I update_engine: [1101/114216.248105:INFO:boot_control_android.cc(343)] Added group main_b with size 1844969472
 473   473 I /system/bin/update_engine: [liblp]Partition vendor_b will resize from 0 bytes to 327540736 bytes
 473   473 I update_engine: [1101/114216.248254:INFO:boot_control_android.cc(360)] Added partition vendor_b to group main_b with size 327540736
 473   473 I /system/bin/update_engine: [liblp]Partition product_b will resize from 0 bytes to 252170240 bytes
 473   473 I update_engine: [1101/114216.248382:INFO:boot_control_android.cc(360)] Added partition product_b to group main_b with size 252170240
 473   473 E /system/bin/update_engine: [liblp]Not enough free space to expand partition: system_b
 473   473 E update_engine: [1101/114216.248480:ERROR:boot_control_android.cc(356)] Cannot resize partition system_b to size 1154273280. Not enough space?
 473   473 E update_engine: [1101/114216.248544:ERROR:delta_performer.cc(998)] Unable to initialize partition metadata for slot B
 473   473 E update_engine: [1101/114216.248630:ERROR:download_action.cc(336)] Error ErrorCode::kInstallDeviceOpenError (7) in DeltaPerformer's Write method when processing the received payload -- Terminating processing
 473   473 I update_engine: [1101/114216.249175:INFO:multi_range_http_fetcher.cc(177)] Received transfer terminated.
 473   473 I update_engine: [1101/114216.249358:INFO:multi_range_http_fetcher.cc(129)] TransferEnded w/ code 200
 473   473 I update_engine: [1101/114216.249451:INFO:multi_range_http_fetcher.cc(131)] Terminating.
1236  1524 V FespxProcessor: onMultibfDataReceived: 8 index 0 size 4096 mPreUploadRollbackDataSize 131072
 473   473 I update_engine: [1101/114216.253259:INFO:action_processor.cc(116)] ActionProcessor: finished DownloadAction with code ErrorCode::kInstallDeviceOpenError
 473   473 I update_engine: [1101/114216.253452:INFO:action_processor.cc(121)] ActionProcessor: Aborting processing due to failure.
 473   473 I update_engine: [1101/114216.253521:INFO:update_attempter_android.cc(454)] Processing Done.
 473   473 I update_engine: [1101/114216.253568:INFO:dynamic_partition_control_android.cc(151)] Destroying [] from device mapper
3254  3272 D clifeOTA: onStatusUpdate  status: 0
 473   473 I update_engine: [1101/114216.254265:INFO:metrics_repo

原因分析:

看这句
ERROR:boot_control_android.cc(356)] Cannot resize partition system_b to size 1154273280. Not enough space?
意思是空间不够,查看储存,16G内存只占用了5G多,实际内存多,为什么内存不够, 主要是看对分区的内存,结合MTKAB分区这个链接里面的分区,partition_ab_dynamic.xml,或者partition_dynamic.xml 这两个文件可以看到对super分区和userdata分区的大小,如userdata分区6291456* 512 / 1024 /1024 /1024 =3 G,表示用户空间占3G,出错原因主要是super分区的大小导致的,一般情况下是16G以上的内存的话, AB分区各占1.5G左右,然后adb remount之后会产生一个overlay的scratch分区,这个分区实际上占用在super分区上的,具体占用多少内存还是看 product,vendor,system三个目录的大小,这样,如果super分区太小的话,在AB OTA升级的时候,就是导致动态分区不够,导致升级失败,因OTA升级时不会清除scratch分区的,我这里为什么会报错,是因为改了内存,从16G降到了8G,然后其他同事改分区的时候只减小修改了super分区大小为3G多,所以userdebug版本,remount之后,overlay占用了super分区,导致升级slot b分区的时候,动态分配分区内存就不够,所以升级失败。

<?xml version="1.0" encoding="utf-8"?>
<partition lba="31457280">

<entry type="0FC63DAF-8483-4772-8E79-3D69D8477DE4" size="6144" name="proinfo"/>
	<entry type="0FC63DAF-8483-4772-8E79-3D69D8477DE4" size="30720" name="cam_vpu1_a"/>
	<entry type="0FC63DAF-8483-4772-8E79-3D69D8477DE4" size="30720" name="cam_vpu2_a"/>
	<entry type="0FC63DAF-8483-4772-8E79-3D69D8477DE4" size="30720" name="cam_vpu3_a"/>
	<entry type="0FC63DAF-8483-4772-8E79-3D69D8477DE4" size="30720" name="cam_vpu1_b"/>
	<entry type="0FC63DAF-8483-4772-8E79-3D69D8477DE4" size="30720" name="cam_vpu2_b"/>
	<entry type="0FC63DAF-8483-4772-8E79-3D69D8477DE4" size="30720" name="cam_vpu3_b"/>
	
	<entry type="0FC63DAF-8483-4772-8E79-3D69D8477DE4" size="10240" name="nvram"/>
	<entry type="0FC63DAF-8483-4772-8E79-3D69D8477DE4" size="20480" name="protect1"/>
	<entry type="0FC63DAF-8483-4772-8E79-3D69D8477DE4" size="20480" name="protect2"/>
	<entry type="0FC63DAF-8483-4772-8E79-3D69D8477DE4" size="98304" name="persist"/>
	<entry type="0FC63DAF-8483-4772-8E79-3D69D8477DE4" size="16384" name="nvcfg"/>
	<entry type="0FC63DAF-8483-4772-8E79-3D69D8477DE4" size="512" name="seccfg"/>
	
	<entry type="0FC63DAF-8483-4772-8E79-3D69D8477DE4" size="2048" name="lk_a"/>
	<entry type="0FC63DAF-8483-4772-8E79-3D69D8477DE4" size="2048" name="lk_b"/>
	
	<entry type="0FC63DAF-8483-4772-8E79-3D69D8477DE4" size="65536" name="boot_a"/>
	<entry type="0FC63DAF-8483-4772-8E79-3D69D8477DE4" size="65536" name="boot_b"/>
	
	<!-- <entry type="0FC63DAF-8483-4772-8E79-3D69D8477DE4" size="65536" name="recovery"/> -->
	<entry type="0FC63DAF-8483-4772-8E79-3D69D8477DE4" size="1024" name="para"/>
	<entry type="0FC63DAF-8483-4772-8E79-3D69D8477DE4" size="16384" name="logo"/>
	
	<entry type="0FC63DAF-8483-4772-8E79-3D69D8477DE4" size="16384" name="dtbo_a"/>
	<entry type="0FC63DAF-8483-4772-8E79-3D69D8477DE4" size="16384" name="dtbo_b"/>
	
	<entry type="0FC63DAF-8483-4772-8E79-3D69D8477DE4" size="20480" name="expdb"/>
	<entry type="0FC63DAF-8483-4772-8E79-3D69D8477DE4" size="2048" name="frp"/>
	<entry type="0FC63DAF-8483-4772-8E79-3D69D8477DE4" size="10240" name="tee_a"/>
	<entry type="0FC63DAF-8483-4772-8E79-3D69D8477DE4" size="10240" name="tee_b"/>
	
	<entry type="0FC63DAF-8483-4772-8E79-3D69D8477DE4" size="4096" name="kb"/>
	<entry type="0FC63DAF-8483-4772-8E79-3D69D8477DE4" size="4096" name="dkb"/>
	<entry type="0FC63DAF-8483-4772-8E79-3D69D8477DE4" size="65536" name="metadata"/>
	
	<entry type="0FC63DAF-8483-4772-8E79-3D69D8477DE4" size="11520" name="vbmeta_a"/>
	<entry type="0FC63DAF-8483-4772-8E79-3D69D8477DE4" size="11520" name="vbmeta_b"/>
	<entry type="0FC63DAF-8483-4772-8E79-3D69D8477DE4" size="8192" name="nvdata" />
	<entry type="0FC63DAF-8483-4772-8E79-3D69D8477DE4" size="4096" name="vbmeta_system_a" />
	<entry type="0FC63DAF-8483-4772-8E79-3D69D8477DE4" size="4096" name="vbmeta_system_b" />
	<entry type="0FC63DAF-8483-4772-8E79-3D69D8477DE4" size="4096" name="vbmeta_vendor_a" />
	<entry type="0FC63DAF-8483-4772-8E79-3D69D8477DE4" size="4096" name="vbmeta_vendor_b" />
	<entry type="0FC63DAF-8483-4772-8E79-3D69D8477DE4" size="16769024" name="super"/>
	<!-- <entry type="0FC63DAF-8483-4772-8E79-3D69D8477DE4" size="229376" name="cache"/>  -->
	<entry type="0FC63DAF-8483-4772-8E79-3D69D8477DE4" size="6291456" name="userdata"/>
</partition>

我们对比前后lpdump分区的区别,adb remount之后,
看分区 Name: scratch

C:\\Users\\aaa>adb shell
xxxx:/ $ lpdump
Metadata version: 10.0
Metadata size: 844 bytes
Metadata max size: 65536 bytes
Metadata slot count: 3
Partition table:
------------------------
  Name: vendor_a
  Group: main_a
  Attributes: readonly
  Extents:
    0 .. 639727 linear super 2048
------------------------
  Name: vendor_b
  Group: main_b
  Attributes: readonly
  Extents:
------------------------
  Name: product_a
  Group: main_a
  Attributes: readonly
  Extents:
    0 .. 492511 linear super 643072
------------------------
  Name: product_b
  Group: main_b
  Attributes: readonly
  Extents:
------------------------
  Name: system_a
  Group: main_a
  Attributes: readonly
  Extents:
    0 .. 2254431 linear super 1136640
------------------------
  Name: system_b
  Group: main_b
  Attributes: readonly
  Extents:
------------------------
  Name: scratch
  Group: default
  Attributes: none
  Extents:
    0 .. 1295 linear super 641776
    1296 .. 2351 linear super 1135584
    2352 .. 1910119 linear super 3391072
------------------------
Block device table:
------------------------
  Partition name: super
  First sector: 2048
  Size: 3690987520 bytes
  Flags: none
------------------------
Group table:
------------------------
  Name: default
  Maximum size: 0 bytes
  Flags: none
------------------------
  Name: main_a
  Maximum size: 1844969472 bytes
  Flags: none
------------------------
  Name: main_b
  Maximum size: 1844969472 bytes
  Flags: none
------------------------

正常设备lpdump

C:\\Users\\xxxx>adb shell
xxxx:/ $ lpdump
Metadata version: 10.0
Metadata size: 720 bytes
Metadata max size: 65536 bytes
Metadata slot count: 3
Partition table:
------------------------
  Name: vendor_a
  Group: main_a
  Attributes: readonly
  Extents:
    0 .. 639727 linear super 2048
------------------------
  Name: vendor_b
  Group: main_b
  Attributes: readonly
  Extents:
------------------------
  Name: product_a
  Group: main_a
  Attributes: readonly
  Extents:
    0 .. 492511 linear super 643072
------------------------
  Name: product_b
  Group: main_b
  Attributes: readonly
  Extents:
------------------------
  Name: system_a
  Group: main_a
  Attributes: readonly
  Extents:
    0 .. 2254431 linear super 1136640
------------------------
  Name: system_b
  Group: main_b
  Attributes: readonly
  Extents:
------------------------
Block device table:
------------------------
  Partition name: super
  First sector: 2048
  Size: 3690987520 bytes
  Flags: none
------------------------
Group table:
------------------------
  Name: default
  Maximum size: 0 bytes
  Flags: none
------------------------
  Name: main_a
  Maximum size: 1844969472 bytes
  Flags: none
------------------------
  Name: main_b
  Maximum size: 1844969472 bytes
  Flags: none
------------------------

解决方案:

1.暂时解决方案,清楚了为什么会失败,那么只需要关掉overlay就行
adb root
adb enable-verity
adb reboot
搞定

2.上面只是短暂解决问题,根本上解决,还是要修改super分区大小
怎么算,比如userdata分区6291456* 512 / 1024 /1024 /1024 =3 G
一个8G的话,一般系统占用时1.5G左右,要想remount没有问题的话,至少需要
1.5 * 2 + overlay分区的占用, 这里的话,我写一个4G, 8388608的,在测试,ok,
注意, 所有加起来的大小不能超过 这个,不然编译不过

ADB

ADB

常见问题

Read-only file system问题

解决办法:

1. 最简单的,adb remount

2. 不行的话,adb shell su之后将文件系统remount为读写权限: mount -o remount rw /system。出于安全考虑,记得完事后remount回只读: mount -o ro,remount /system

3. 和方法2类似,mount -o rw,remount -t ext3 /dev/block/mmcblk1p21 /system

insufficient permissions for device

使用root权限来启动adb server:

sudo –s

adb kill-server

adb start-server

exit

adb shell

如果还是不行:

lsusb

 Bus 001 Device 010: ID 0bb4:0c87 High Tech Computer Corp

$sudo vim /etc/udev/rules.d/70-android.rules

加入以下内容:   SUBSYSTEM=="usb",ATTRS{idVendor}=="0bb4",ATTRS{idProduct}=="0c87",MODE="0666"

命令

Adb logcat

Sudo -s

Adb kill-server

Adb start-server

 

卸载内置应用:

adb remount

cd system/app

rm xxx.apk

修改系统参数

修改Log.isLoggable形式的日志打印开关级别:

adb shell里面敲setprop log.tag.Mms VERBOSE

以上是关于adb remount之后,OTA 升级失败的问题的主要内容,如果未能解决你的问题,请参考以下文章

解决高通 Android 12/13 ota升级失败问题

Android 6.0 M userdebug版本执行adb remount失败

ADB

平时工作需要用到的adb命令

Android11.0 OTA差分包升级失败kDownloadStateInitializationError

adb remount 相关