Editing build.prop did not solved "failed" message when trying to flash. I like TWRP 2.6.3.0 and won't go backward just to try new kernel
Alright, so I went ahead and did a little thinking on this. Right now I'm not running any sort of custom kernels on CM... So I won't actually be trying to flash this until this weekend.
...However...
@Azoller:
I'm looking at the updater-script in your kernel package.... wth is going on in here?
It looks like you just kept the same one from the rom install zip. This is FULL of errors for what you have in your zip. Pretty much the only line that shouldn't throw an error is
Code:
package_extract_file("boot.img", "/dev/block/mmcblk0p8");
Also, you've included a folder for /system/etc/init.d however, the folder itself is blank. That won't really do anything, especially without some form of a modification to the ramdisk (maybe it is in the boot.img) to run sysinit, as well as a modified sysinit to run the busybox run-parts command. Which, is actually a pretty unreliable way of adding init.d support, but it's the easiest and most commonly used one.
If you're providing a custom kernel, it's a good idea to also include the newly built drivers (in case anything changed there) which would be /system/lib/modules I believe, off the top of my head. Not really a necessity, but not bad to have.
For what you're doing here though, your update-script doesn't need to be anything more than: (and this is assuming you want to be nice and make sure that you're installing it on a spec)
Code:
assert(getprop("ro.product.device") == "vs920" || getprop("ro.build.product") == "vs920");
package_extract_file("boot.img", "/dev/block/mmcblk0p8");
With whatever friendly printouts you want to include.
I apologize if any of this is overly critical, but if the recovery doesn't want to be nice, most of the rest of that will just through errors. Especially the parts calling files/paths/etc that don't exist.
