Originally Posted by KenMacD
That sounds right to me though. The new boot.img is the one to check the signature, so it would make sense that you'd be able to install and use the new system.img (or any system.img) with the old boot.img. You just can't (yet) use any system.img with the new boot.img.
So, in this spirit, I wanted to try modifying the new boot.img to modify the way it mounts the system back to the old way (or alternatively still via device mapper but without the verity module so it does not integrity checking). I unpacked a boot.img using unpackbootimg from mkbootimg
and tried repacking it without any modification to see if the tooling can at least get a bootable image. Diffing it with the original boot.img shows that I probably didn't have the arguments right as the cmdline was stored at a different hex offset, but I tried anyway. I used cc-mangle-bootimg
(assuming that it's required as a second step after mkbootimg) but it seems that I still don't have the right steps, rebooting still shows the "Chromecast..." screen, only this time it's flickering.
- any idea how to generate a bootable boot.img (and/or modify the official one from 84839)?
My thinking is also if somehow we can modify the later boot.img to correctly mount the system without verification we can potentially get it working again reliably. Or at least install further debugging into the initramfs so we can work out what's going wrong.
---------- Post added at 01:13 AM ---------- Previous post was at 12:24 AM ----------
Also.. seems like bad news incoming.. after updating to 84839 with kernel from 80438, I got a new ota from Google, 88007. This one seems to not work with the older kernel and stays on the "Chromecast..." screen. I couldn't capture the original ota url but I copied the zip off if anyone wants to see what's changed: https://mega.nz/#!x34zVKzA!1Do37qYyX...kKBdjdkdn_mLuw