Android - Trying to flash a system.img I took with dd - failing

Episode 3: Return of the Shell.

If I ever had any chance of solving this, I first had to figure out why the shell wasn't working. adbd itself was responding, so it was started on the tablet side - but it could not execute the shell, even when I hack-patched it to invoke a file (/sbin/sh) that I myself placed in the boot image - being 100% sure that it had the proper permissions and was accessible from the shell (id=2000) account that adbd uses.

Which left only one explanation - SELinux "cages".

So I checked how adbd was started from my boot image's init.rc:

# adbd is controlled via property triggers in init.<platform>.usb.rc
service adbd /sbin/adbd --root_seclabel=u:r:su:s0
    class core
    socket adbd stream 660 system system
    disabled
    seclabel u:r:adbd:s0

...and tried an obvious change:

service adbd /sbin/adbd
    class core
    socket adbd stream 660 system system

I re-packed, and to my intense satisfaction, saw ...

linuxbox# adb shell
$ 

I finally got access to the tablet - from "inside".

Checking the mounted /system, it became clear that the flashing process - even though fastboot flash system ... reported that all was Ok - had failed spectacularly. It was a wonder that the partition was mounted in the first place.

That explained why the tablet was not booting, and gave me the final idea that solved the issue.

I needed to boot the tablet so that it used my pristine copy of the /system partition, but at this point, even though I had shell access, I was not root - (the changes I did in default.prop are apparently ignored by the Asus kernel - I'll have to recompile it soon...) so I could not mount the external sdcard and dd over my good copy.

But I did have my own boot image - which meant I could edit the /fstab.qcom inside it, and do this:

Original line that told the tablet how to mount /system

/dev/block/platform/msm_sdcc.1/by-name/system  /system  ext4 ro,barrier=1 wait

My edit

/dev/block/mmcblk1p2  /system ext4  rw,barrier=1 wait

...and back in my linux box, I dd-ed the pristine backup of the tablet's system partition to my external SD card's 2nd partition - which I created via gparted to be exactly 2GB.

That did it - the tablet booted from my external SD card.

EDIT: The journey continued - I eventually patched and compiled my own kernel and became root.

It seems you've already found some kind of solution to your problem (there's a lot of text to read on this page), but it seems this probably could have been resolved much more simply.

linuxbox# fastboot getvar all
(bootloader)  version-bootloader: 3.03
(bootloader)  version-hardware: rev_c
(bootloader)  variant: LEOPARDCAT 16G
(bootloader)  version-baseband: H00_0.16.F_0521
(bootloader)  serialno: 0a3dXXXX
...
(bootloader)  partition-type:system: ext4
(bootloader)  partition-size:system: 0x0000000080000000

Among these variables, did your tablet return a max-download-size variable? If so, that might have provided a warning, outright, that the flashing process might have some issues with such a large image. The current fastboot code is made to work around a max-download-size that is too small, but I've experienced your same error even when the image is smaller than what the device says it can handle, so actually the point is kind of moot, I guess.

linux_box# fastboot flash system system.img  
error: cannot load 'system.img'

So, anyway, it seems here, that for whatever reason, you are unable to flash. If you and I are right, and it's about size (your tablet does only have 1 GB of RAM, and supposedly most devices try to read the whole image into RAM before flashing), this is where I think the mere adjustment of adding the -S option to fastboot might have fixed your flash as it has for me:

fastboot -S 512M flash system system.img  

Instead, however, it seems you tried to force your 2 GB image into a size that (1) might not be possible for it to be stuffed into and (2) is not the size that your device's system partition is supposed to be.

• Regarding point #1, in my experience, I would not count on the brittle Android build tools to complain if you ask them to do something they will fail at, and it's possible that they might have here.

• Regarding point #2, I don't believe you can't just do that; additional steps would be required to use a different system partition size.

Assuming your tablet expects sparse image files, I believe the command you wanted to try instead of make_ext4fs -l 1536M new_system.img /system was make_ext4fs -l 2048M -s new_system.img /system. The adjusted command would make an image that inflates to the correct size, but is stored temporarily stripped of any excess fat like big pockets of empty data: a "sparse image file" (see the page I linked to earlier for more info on them; I don't have enough reputation on this site to repeat the link).

This old readme someone wrote for a collection of the tools should help understand how the process goes.

Cheers.

With my Moto G I created a back up using dd like you did. I needed to restore my system partition the other day, so I booted TWRP (I didn't flash it, I just booted the image to RAM). I then used adb to connect while TWRP was running and I just pushed the img I made with dd to my SD card and then used dd to write the image to the system partition.

Check out the videos I've made about this here: https://youtu.be/BHCamV-sHx0?list=PLcUid3OP_4OVI1Rtuwxk1RjABh1PxXXQq