View Single Post
Old 01-02-2013, 05:42 AM   #34
ixtab
(offline)
ixtab ought to be getting tired of karma fortunes by now.ixtab ought to be getting tired of karma fortunes by now.ixtab ought to be getting tired of karma fortunes by now.ixtab ought to be getting tired of karma fortunes by now.ixtab ought to be getting tired of karma fortunes by now.ixtab ought to be getting tired of karma fortunes by now.ixtab ought to be getting tired of karma fortunes by now.ixtab ought to be getting tired of karma fortunes by now.ixtab ought to be getting tired of karma fortunes by now.ixtab ought to be getting tired of karma fortunes by now.ixtab ought to be getting tired of karma fortunes by now.
 
ixtab's Avatar
 
Posts: 2,903
Karma: 6677485
Join Date: Dec 2011
Device: K3, K4, K5, KPW, KPW2
It would be much simpler - and safer - to "extract" the kernel from the official 4.1.0 update.bin using kindletool This is the only way to ensure that future upgrades will work smoothly.

Explanation: While it is possible to determine the size of the actual "required" kernel image, the kernels bundled in update files are usually padded with 0xFF bytes up to some boundary (IIRC, that's *usually*, but not always, the next multiple of 0x400). And, all the updates I've seen so far check for MD5 sums of the installed kernel (*including* the padding) to verify that the device is in a "known good" state, before performing the update. If you now flash a kernel obtained using the getkernels tool, that kernel *might* actually be shorter than what the update file provides, resulting in some of the "padding" bytes not being overwritten. And if you're out of luck, the next update will fail to install, because the md5sum of "kernel+padding" on the device does not match the expected one. I've seen it happen.
ixtab is offline   Reply With Quote