0

I feel my old mobile with android 2 or 3 got bricked as it get stuck on boot logo each time but I can easily got into fastboot mode but in fastboot mode I can complete following commands like:

fastboot devices
fastboot flash recovery recovery.img
fastboot flash splash splash.img
fastboot flash userdata userdata.img

But each time I run the following command

fastboot flash system system.img

The fastboot command stuck on

Sending 'system' (124183 KB)

I can easily erase the system but cannot flash it.

  • Have you updated adb to latest version on your laptop. Older versions cannot handle big files – beeshyams Nov 15 '19 at 9:01
  • Yes to the latest released version i.eAndroid Debug Bridge version 1.0.41 Version 29.0.5-5949299 Installed as /usr/bin/adb – jkp Nov 15 '19 at 9:03
  • 2
    Boot in recovery and write system.img using dd. – Irfan Latif Nov 15 '19 at 9:38
  • Can you elaborate – jkp Nov 15 '19 at 11:42
0

boot in recovery from fastboot, once in twrp enter adb shell, or use -> Advanced -> Terminal

fastboot boot recovery.img
adb shell

be careful with dd especially double check partition name and partition size.

in your /etc/recovery.fstab there might be just a symlink but no worry you can use it dd will targeting the real partition.

cat /etc/recovery.fstab
ls -l /dev/block/bootdevice/by-name/system
dd if=/external_sd/system.img of=/dev/block/mmcblk0p99  

if the file size is bigger than partition size it is strongly recommended to add parameters block size and count to limit the write process to maximum partition size, otherwise your cache and userdata partition may be destroyed.

beware files bigger than 4 GiB can not copied to MicroSD Card, so instead adb push

adb push system.img /dev/block/mmcblk0p99  

How can I view the Android internal partition table?

if you are not sure about your system.img is sparsed image or LZ compressed, you can check the header for file system type / partition magic
ext4: 0xEF53 at offset 0x438
f2fs: 0xF2F52010 at offset 0x400

hexdump -C -n1088 system.img | grep 53.ef
hexdump -C -n1032 system.img | grep 10.20.f5.f2

if one of these magic is found the image can be loop mounted for testing, otherwise you need to convert file with simg2img or sdat2img first

| improve this answer | |
  • 3
    Using 1024 bytes as block size is a bad choice for flash storage. The internal size of flash chips is usually larger (in the range of 4-8K). Writing with a lower block size can result in flash blocks that need to be written multiple times. Therefore a block size of 8192 and a reduced count will preserve flash and also may increase writing speed. – Robert Nov 15 '19 at 15:25
  • thx, didn't know that. i was just always using 1k because it is easy to compare with output block size of /proc/partitions and df – alecxs Nov 15 '19 at 15:55
  • Are you sure about this: otherwise your cache and userdata partition may be destroyed? – Irfan Latif Nov 15 '19 at 16:00
  • never tried, but once i dumped a 200 MiB "recovery.img" because dd was not detecting end of partition (lucky it was just copy not writing) i believe there are factores like dd version/build partition table layout or something that have influence. same for adb push, be careful – alecxs Nov 15 '19 at 16:25
  • 1
    Storage devices and partitions are exposed by Linux kernel as block devices. One can't jump to adjacent block device by crossing boundary when writing to one block device - either in filesystem or as raw. That's the whole purpose of partitioning. // Btw system partition isn't necessarily always adjacent to cache and userdata partitions, there could be others. – Irfan Latif Nov 15 '19 at 18:07

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.