Can't boot Android device after replacing system.img

Question

I am working on a custom android device using the i.MX53 board from NXP (formerly Freescale). I have the OS source code, various intermediate files, and the final resulting files once produced by another developer (who customized the OS, but has since left our company). I now need to modify the contents of the system partition on these devices. I have attempted to build and load a new system.img file using make_ext4fs.exe and the directory which contains the original collection of files the prior developer must have used. I believe I have created a nearly identical system image, as the one previously used. They are both ext4, 200MB.

There is a utility for this board (called MfgTool) which copies and mounts images automatically for you at the click of a button. That MfgTool successfully writes my image to the device. When I try to boot, however, it fails and just loops with the custom boot image being displayed. If I swap out the new system image and restore the prior one in this process, everything works again. So it has to simply be a matter of getting this system image built correctly.

What might be the cause? What difference in the images might cause this? Is it possible there is a signature needed, or some other kind of protection which I'm failing to account for?

Answer 1

It turned out that my primary problem was that I need to set the mount point for the image to "system" NOT "/system" when it was created via make_ext4fs despite all documentation out there to the contrary! I figured this out by carefully reading the ASOP source: ...build\tools\releasetools\img_from_target_files.

Of note, after this hurdle, I ran it another problem where the device was acting funky. That turned out to be the result of not having any symbolic links in the image. It seems like at the least you normally have symbolic links directing your "bash" commands to the toolbox binary in system/bin. I don't know how you normally get those, but creating those links and then bundling them into the image fixed that. I suggest checking the bin directory for symbolic links if you manually create a system image like this.

Answer 2

Replace one of the system image service executable with a shell that dump kmsg and logcat to a file (in data partition or external storage for example) and then call the original executable. Then, boot to your previous system and collect those logs.