So, now that all the stuck ones can go up, and eventually leave GB for good and be solely on ICS, are we done? I kinda feel the need to keep working on an ICS2GB method.
Essentially, whatever version your boot.img is, you can install (by force) whatever build that the boot.img is from. If you are on .84, and you want to go to .85, you would have to patch .181GB-boot.img with .85ICSboot.img.p, flash new boot.img, proceed with recovery (by force) of .85. .84 cannot go to .85 and vice versa unless you issue a new boot.img.p patch off of original .181GB-boot.img and then proceed with that ota version recovery install correct?
Now, if u wanted to go backwards, is this where the CDT.bin file would prevent you from doing that? Because if we fastboot a .181 boot.img, it seems to take fine correct? The only issues are cdt.bin, devtree, cdrom, and recovery.
So since we successfully bypassed the CDT.bin preflash validation by copying (DD) a .181GB mmcblk1p18 to (whatever version of ICS leak you're on), rebooting in to fastboot, and flashing old cdt.bin, no issue arrises.
Now, once at that stage when we (by force) fastboot .181 GB files on after replacing cdt.bin, we receive customer ID error on boots, but cdt.bin is flashed, so customer id error keeps popping up because of the other 3 partitions being mismatched (devtree, cdrom, recovery?) I'm thinking out loud...
So, we if DD .181 cdt.bin (p18) along with recovery, devtree, and cdrom, reboot into fastboot, would the .181 fastboot files then be able to pass preflash validation? At that stage, force OTA update of .181GB over passed validated partitions, and then we would have a full 181 OTA install?
I understand the concept of having a locked bootloader, but when we DD these images out of .181GB, wouldn't these images retain their signature? Phew, that's a lot of typing, and then again, thinking out loud.
So does the no corruption bspatch posted in the op make a flashable boot.img? i used it to patch the bionic 5.9.905 boot.img with boot.img.p from the latest 6.7.235 leak and it does create a file; however the new boot.img is different than the boot.img included in matt's DroidBionicUnstuck.zip utility. I know i can just use the image from this utility, but want to have the technique ironed out for future reference.
is the method from this post...
...still the only way to successfully patch boot.img?