[SuperSU] karthikrr:
0 - Check

1 - Check

2 - Fail

Tools and Process: Listing all of them. The one I followed for this methodical approach is the first one. Including the others for context, in the hopes that it will indicate what the next step should be.

1) Carliv's Kitchen

Followed instructions, placed boot.img in the boot_resources folder, unpacked it with the tool, changed nothing, repacked with the same tool, made tar using "tar -cf boot_stock_repack.tar bootxxx.img" bootxxx.img is what Carliv generated, of course. To compare, made tar of the stock boot.img as well, naming it boot_stock.tar. Flashing boot_stock.tar works, device boots, no problems. Flashing the boot_stock_repack.tar fails with "Unsupport dev_type" on the device.

Additional Info:

------------------------------------------------

2) bootimg_tools

split_boot to extract the kernel and ramdisk and unpack the ramdisk. No warnings are issued, nothing suggests there is any problem.

repack_ramdisk to repack ramdisk, no problems here either.

mkbootimg to create new boot.img; no arguments are specified since apparently it would automatically create the right image.

tar -cf to create ODIN flashable tar.

Flashing this would succeed in ODIN, but the device would reboot in Download Mode with "Unable to boot normal mode" showing on the device. 3 suggests an explanation why.

3) To extract the kernel and ramdisk, used umkbootimg instead of split_boot from the same toolset. This time, it issued a warning about the original img being created with a non-standard mkbootimg, said I should edit mkbootimg.c before making the new image. Despite the warning, it also provided a mkbootimg command to use to ensure the new img is created correctly. Googling the warning suggested downloading android source code to get the mkbootimg.c file, but nothing beyond that on what needs to be done.

While not optimistic, I still tried the mkbootimg command it gave me, as well as with extra arguments to correct the addresses till boot_info in the toolkit matched for the stock and new images. SAME outcome as with 2.

4) Modding_My_Mind/SHM's toolset

This one claimed to automatically make the necessary corrections for a non-standard boot image and definitely did something different. Unlike the other generated images which were smaller in size than the original, this one was the same size. Making a tar and flashing it though failed with Unsupport dev_type showing on the device. I have contacted SHM to see if he can shed some light on this.

NOTE: In the thread where I got this from, when dealing with a non-standard image, his output seems to show this warning. BUT, I got no such warning when I did this on my image.

5) Carliv's as in the first item here. It generated a boot.img that matched in size and failed with the same error as the previous, suggesting it is definitely making SOME changes to the mkbootimg arguments to work with the 'non-standard stock image', BUT I have no idea what these changes are, nor where to look for them.

Next Step?

I never tried a full manual repacking of the ramdisk and generation of the image. Not sure if the error could be in the way the ramdisk is being repacked (which seems improbable, since its a gzip + cpio command that does this, not much to mess up there), or if its the way in which the new img is being created (seems probable, given that many arguments need to be passed here and Im using binaries that I do not know and understand at all).

I tried to look for other ways to create the img file, BUT pretty much everything keeps pointing to these same toolsets and binaries. With regards process, I have not been able to find anything on how to make 'manual adjustments' to the addresses/offsets.

Any advice on where to go/look next?