Smoothest Rom recently got a new update with a better new kernel. However; if you are familiar with it Smoothest Rom, you should know that smoothest rom gives you the option of choosing your own kernel. So If I were to update Smoothest Rom with a new kernel, would I have to factory reset before flashing? Or what would I have to do?
Thank you!
TL;DR No need to factory reset. YMMV, so take a complete Nandroid backup before you begin. You won't be sorry for doing that.
The most compatible kernels are distributed as just the kernel zImage file, and rely on the installer to pick apart the existing boot image (kernel+ramdisk), and then re-assemble it back into a boot image (new_kernel+old_ramdisk) for flashing. Almost nothing changes - except perhaps features available in the kernel.
For better or for worse though, some kernels are distributed as both a kernel and a new ramdisk - a complete boot image. This is done because the dev wants to alter the userspace activity taking place in the early phase of booting; things like setting default values by writing tweak parameters into the /sys filesystem, or perhaps setting a property (e.g. in /default.prop), or plumbing a new device node into the /dev tree, launching oneshot services, or making sure that the init process launches scripts in /system/etc/init.d as the very last thing it does.
That means that any dependency that a given ROM (files in /system) has on activities taking place as a result of dev customizations placed into the ramdisk are at risk of being snuffed out when you flash a full boot image for a "different kernel".
Moral of the story? Take a backup. If stuff goes to ell in a handbasket, you can go back to where you were.
Related
Hi,
When you want to perform some scripts at boot-time, there is two possibilities :
- modify init.rc, but it requires to reflashing the rootfs image (modification in / does not hold after a reboot),
- using an android app like script manager, which will load your scripts at java/dalvik platform boot-time.
I've managed to find a way based on activating tf-daemon, which is a script called by the asus/ventana initrc, but disabled at boot-time. Basically, we're re-enabling this daemon by setting the property tf.enable to yes, and then creating a script called tf-daemon and put it in /system/bin. Since this script is called by init.ventana.rc as root, you can put whatever you want inside this script.
I don't know what is the original purpose of this daemon, but probably it's used by the asus team for internal and debugging purpose.
Be aware that in the next firmware update, this possibility could disappear.Let's hope the asus team does not read this post. Or at least they could allow power users to call custom scripts at boot-time.
As a case study, you will find as attachment a script for loading nfs modules at boot-time.
PS: damn, can't upload. Here is a temporary link : http://dl.free.fr/hwTZ0YBq2
Untar the archive, then su, and sh install.sh
At reboot, you should have nfs modules loaded.
Good find:
I gave this a try just to load a couple of my own modules that work with the kernel I'm using. Works fine -- Thanks, -
Another method is to make a script and just call it in the init.rc. After a firmware update you only have to add the "exec myscript.sh" line to init.rc. I personally prefer this method because it allows me to control when the script is executed, whereas the tf-daemon method is always executed at the same point(AFAIK). Good research though, always nice to know all the boot calls.
Modifying the init.rc was my first shot, but the problem is that init.rc lies in ramdisk. So when trying to modify, the modification does not hold
after reboot. So a real modification involves to reflash rootfs with nvflash, too much hassle for me. The method I'm providing is for lazy ones. ;-)
nice find, but the link is dead, could you please provide a new link for the script?
also, how do I load nfs module for there is none under /lib/modules, compile the kernel myself?
[Size=+2]A500 Public Recovery v0.2 based on Koush's CWM v5.5.0.4[/Size]
Here is a new Clock Work Mod for the ICS unlocked bootloaders only.
Features:
* cleanup tab option: shortcut to try to fix forcequits after updates, return to recovery and select on the main screen (Wipes Cache, dalvik, and fixes permissions)
* Standard options to backup and restore to either the SD card or internal storage
* Mount points match those of most running roms
* adb shell works as root (with or without system mounted)
* set boot mode menu to select the boot partition (hidden on know non-multiboot bootloaders)
* setbootmode and itsmagic command line tools for advanced users
* /data/linux directory is not deleted on erase userdata, nor backed up on nandroid backup (just like /data/media) to allow a space for linux files for dual boot and chroot linux installes.
While there may not be much fantastic yet about the recovery it appears funcitonal at this point. (Features such as touch ui may appear in the future)
Why is it called Public: its public in the sense that all the scripts and code required for anyone to build it have been made avalible. (note some linux knowledge may be needed to build it yourself)
[Size=+2]Installation[/Size]
There are to main ways to install
1) using fastboot or nvflash you can install the image
A500PubRecovery_v0.2.img MD5: 0e40a494cd066b1c8e1a8d01493f1452
2) using a any exiting recovery (as long as you have one of the unlocked bootloaders) you can install with an update.zip
A500PubRecovery_v0.2_update_S.zip MD5: 349d0d6284fc6d1e071827a37a8a55e5
** (FYI the fastboot command to run on your computer is 'fastboot flash recovery A500PubRecovery_v0.2.img')
[Size=+2]Developers Additional Information:[/Size]
Build instructions (including how to fetch the source code) is here:
https://github.com/ezterry/AcerRecovery/blob/recovery_manifest/README.mkdn
(Thanks yous/Credits are also included)
Kernel:
as of version 0.2 the kernel is built from source (see above for information on fetching the build tree including the linux kernel)
the kernel in v0.1 was a patched for system r/w acer ICS Stock kernel
additional information can be seen on the commit:
https://github.com/ezterry/AcerRecovery/commit/402da6f73e752e80312318e177035ee02e4fbf89
The biggest thanks is as manythings in the Android World to Koush, and the CyanogenMod team. (They did the hard part, I've just tweaked it for the A500 configuration)
[Size=+2]Version List[/Size]
v0.2:
A500PubRecovery_v0.2.img 0e40a494cd066b1c8e1a8d01493f1452
A500PubRecovery_v0.2_update_S.zip 349d0d6284fc6d1e071827a37a8a55e5
v0.1:
A500PubRecovery_v0.1.img 4414bdbdd3aa7b7d7d1166595e6ccb2a
A500PubRecovery_v0.1_update_S.zip f45e7e3b640b42a68ec9bb08bd4b88ce
for details on the source commits used in the builds please see:
https://github.com/ezterry/AcerRecovery/blob/recovery_manifest/VERSIONS.mkdn
I will put it in the guide ,so when you flash the unlocked boot loader you can chose to install this with it , the more options for the user the better.
Thanks for the hard work.
Awesome !!! im curious to look at source so thanks for this
Sent from my SCH-R760 using XDA
btw,
The a501 is a very similar device.. is some more advanced user wishes to test things out and let me know if and changes is needed or if its good as is (fastboot boot may be useful if you wish to boot it without actually saving it to the tab)
Other Acer devices probably need slight modifications, if you help I can look into adding it to the codebase/builds..but I can only test the a500 as it's the only tab I own.
Just try to make sure you have a link to the source code of any kernel..and failing that that it Lisa stock kernel from an official OTA image.
I have a A500 with the Build.Number "1.033.00_EMEA_DE".
I have Problems to get the CWM with that Tutorial:
http://www.brutzelstube.de/2012/acer-iconia-a500-mit-android-4-0-ics-rooten/
Its all running fine but when i want to boot into the CWM it seems to work but then the Android Guy with open Stomach and the Red ExclamationPoint is showing.
I wonder if i can use this Public Recovery v0.1??
Maybe someone can help me that.
Basian Mile said:
Its all running fine but when i want to boot into the CWM it seems to work but then the Android Guy with open Stomach and the Red ExclamationPoint is showing.
Click to expand...
Click to collapse
If you are running a stock ICS rom you need to make sure you don't have the recovery patch still installed, otherwise the stock recovery will be installed on reboot if any other recovery is installed.
If you have the script and patch.. this recovery as any other custom recovery will be overwritten.
Sent from my Galaxy Nexus using Tapatalk 2
The CWM (v5 from Thor2002ro) is running now. I was using the wrong CPUID. That was my falut. But now its ok.
So i can flash this new Recovery just in this right?
If you have one of the the unlocked ics bootloader you can flash this recovery.. either directly or with the update.zip from a working custom recovery.
Sent from my Galaxy Nexus using Tapatalk 2
Great Job!
If you want to build an A510 version, just change the data partition to point to /dev/block/mmcblk0p10. Everything else stays the same. If it doesn't boot, i may need to have the A510 recovery kernel.
BTW.. the recovery kernel doesn't really need to be patched for r/w, because /system never gets mounted as readonly, so it never does a remount to r/w. I've repacked recoveries with stock ICS kernels and they work fine. == Although, it doesn't hurt to patch them. ==
Euclid's Brother said:
BTW.. the recovery kernel doesn't really need to be patched for r/w, because /system never gets mounted as readonly, so it never does a remount to r/w. I've repacked recoveries with stock ICS kernels and they work fine. == Although, it doesn't hurt to patch them. ==
Click to expand...
Click to collapse
Part of it is I intend the kernel for my own ics rom. (Safer anyway in my opinion to not find any surprises as a user but not the biggest issue)
Tested it and installed fine , it's barebones recovery but I think A lot will love it , clean and simple. I used fastboot to install it .
Thanks Ez.
BTW I'm working on the next release
1) Some minor bug fixes (partitioning sdcard and full wipe are a bit strange at present.. in most cases we don't re-partition sdcards.. and wipe if you are installing a rom after will fix its self)
2) Now that acer has released their source, I've dropped the pre-built tweaked stock kernel, and added a source build, mostly still stock but I've changed to lZMA to allow some more space for the recovery ramdisk. (also system remount is allowed by default in this kernel so no postbuild acrobatics .. ie KPatch script)
3) add setbootmode/itsmagic binaries to the system. A500 (this is in github as is the kernel so building from synced source will give you a recovery with these pre-installed)
4) hopefully add an interface to call said binaries
Also I have an A510 test version I need someone (with the tab) to try.. PM me
Edit (Feature Idea):
whould anyone be interested in recovery when wiping not only skiping /data/media (internal /sdcard) but also skiping /data/linux ?
The idea is dual boot people bootling linux could use a ramdisk to run some bindmount/piviot root hackery to make /data/linux the root directory
also anyone using chroot to run a linux distro along side android could use the /data/linux directory as the chroot jail
let me know and I'll look into making APR here support such a feature
Is it posible to add app cwm for install.zip,backup,restore since rom ?
For exemple,the same app into sgs2 with siyha kernel or another kernel ??? Big thanks
Envoyé depuis mon A500 avec Tapatalk
ezterry said:
3) add setbootmode/itsmagic binaries to the system. A500 (this is in github as is the kernel so building from synced source will give you a recovery with these pre-installed)
Click to expand...
Click to collapse
Ehm, definitely don't put itsmagic next to setbootmode, it corrupts the kernel image in AKB.
ezterry said:
Edit (Feature Idea):
whould anyone be interested in recovery when wiping not only skiping /data/media (internal /sdcard) but also skiping /data/linux ?
The idea is dual boot people bootling linux could use a ramdisk to run some bindmount/piviot root hackery to make /data/linux the root directory
also anyone using chroot to run a linux distro along side android could use the /data/linux directory as the chroot jail
let me know and I'll look into making APR here support such a feature
Click to expand...
Click to collapse
Yeah I'm actually thinking to install linux to /data/linux and chroot there, too, exactly the same way.
micky387 said:
Is it posible to add app cwm for install.zip,backup,restore since rom ?
For exemple,the same app into sgs2 with siyha kernel or another kernel ??? Big thanks
Click to expand...
Click to collapse
I'm not exactly sure what you are talking about,
If you want to use this recovery with RomManager (as an unofficial 3.x+ recovery) you may. (In rom manager select flash recovery, select a500, select that you have manually installed a CWM recovery, select 3.x) To make it "official" koush needs to update his repo.. and I'm not going to poke that until I fix some minor outstanding bugs.
Actions will by default happen on the /data/media partition (as that is usually /sdcard) and no roms are yet in the system.. but I may work on fixing that after I make the next release. Currently running a backup myself.
If you want some other app to do this.. it needs to be compatible with the clockwork mod API.
Skrilax_CZ said:
Ehm, definitely don't put itsmagic next to setbootmode, it corrupts the kernel image in AKB.
Click to expand...
Click to collapse
next to as in both the "itsmagic" and "setbootmode" binaries are in /sbin? .. I hope you can live with that.
I don't intend to automatically run it *ever* in this recovery, just want it to exist for anyone cleaning the system to return to a HC bootloader.. probably won't even add it to the GUI as its not something you want to do by mistake (and really I don't want to promote anyone to do.. its just there for some advanced users doing advanced operations). Boot mode however will be in the gui.
ezterry said:
next to as in both the "itsmagic" and "setbootmode" binaries are in /sbin? .. I hope you can live with that.
I don't intend to automatically run it *ever* in this recovery, just want it to exist for anyone cleaning the system to return to a HC bootloader.. probably won't even add it to the GUI as its not something you want to do by mistake (and really I don't want to promote anyone to do.. its just there for some advanced users doing advanced operations). Boot mode however will be in the gui.
Click to expand...
Click to collapse
Very clever... i was worried myself at first when i saw you mention itsmagic... i'm so happy we have an open bootloader now with no tricks... oh, except the original hacking
Thanks so much for your work on this!
ezterry said:
I'm not exactly sure what you are talking about,
If you want to use this recovery with RomManager (as an unofficial 3.x+ recovery) you may. (In rom manager select flash recovery, select a500, select that you have manually installed a CWM recovery, select 3.x) To make it "official" koush needs to update his repo.. and I'm not going to poke that until I fix some minor outstanding bugs.
Actions will by default happen on the /data/media partition (as that is usually /sdcard) and no roms are yet in the system.. but I may work on fixing that after I make the next release. Currently running a backup myself.
If you want some other app to do this.. it needs to be compatible with the clockwork mod API.
next to as in both the "itsmagic" and "setbootmode" binaries are in /sbin? .. I hope you can live with that.
I don't intend to automatically run it *ever* in this recovery, just want it to exist for anyone cleaning the system to return to a HC bootloader.. probably won't even add it to the GUI as its not something you want to do by mistake (and really I don't want to promote anyone to do.. its just there for some advanced users doing advanced operations). Boot mode however will be in the gui.
Click to expand...
Click to collapse
OK.
I want to know if it's possible to add the same app (a part of recovery)
Thanks
ezterry said:
next to as in both the "itsmagic" and "setbootmode" binaries are in /sbin? .. I hope you can live with that.
I don't intend to automatically run it *ever* in this recovery, just want it to exist for anyone cleaning the system to return to a HC bootloader.. probably won't even add it to the GUI as its not something you want to do by mistake (and really I don't want to promote anyone to do.. its just there for some advanced users doing advanced operations). Boot mode however will be in the gui.
Click to expand...
Click to collapse
Yeah that's ok, I meant next to as in GUI, that would bring only problems.
v0.2 is out (see op)
Bugfixes:
~ wipe full data fix
~ fix on formating the external sdcard
~ cleaned up some warnings
Features:
~ added multiboot support (select boot partition)
~ added itsmagic binary (command line only)
~ switch to kernel source build rather than pre-built kernels
~ added /data/linux support (skip on wipe data, and nandroid backup)
kernel was built from:
https://github.com/ezterry/AcerTabKernel/commit/a6312764aa19ea7fe581b9931723c206a12b11ef
config file: apr_a500_defconfig
besides the configuration the kernel source is thus far unchanged from the acer a500 ICS drop
The kernel is built along with the recovery, see developer notes in OP for a link to the build instructions.
v0.2 doesn't boot for me.
Using Skrilax v6 bootloader I can't boot v0.2 while v0.1 works fine, both flashed from fastboot.
I also tried flashing v0.2 from v0.1 recovery, same results.
As anyone who has tinkered around with android and linux will know there are tons of different security mechanism in place or even general lacks of features that dissallow the ability to start linux on boot instead of android. One of the features that will make booting our own OS easier is the use of RAM-Disk.
First we must consider the way that Android boots when we turn on our devices currently, The system powers on and depending on button combination or system state the bootloader decides where to start booting. In the case of my Samsung SM-T520 this means that I have 2 partitions that I can access in order to interrupt the Android boot sequence and boot instead into an OS of my choosing. Those two partitions are Labelled as Boot and Recovery and reside at /dev/block/mmcblk0p9 and /dev/block/mmcblk0p10, but it is not as simple as simply mounting the partition and modifying the contents, we have to Modify the stock Kernel as well a little bit to be able to achieve better performance in the Linux side of things.
In the case of the SM-T520 I have compiled a preconfigured Kernel for this and will upload it below, But for those of you who do Not have the SM-T520 I will upload a sample Kernel config that you can base your own off of.
That settles the Kernel side of things but there is still 1 other part missing, If we just modify the Kernel then we are really not making any difference so we must edit...
The Initial RAMDISK
The Initramfs as many know it is glued to the back end of our kernel zImage that we get from compiling our own kernel, and includes a few small files to set up the initial environment for Android, or our Guest OS to finish booting from. This means that we have a pretty good base to start out with booting Linux. We simply have to grab this base and modify to our will.
So to start I took an image of /dev/block/mmcblk0p9 using dd from recovery like so ‘dd if=/dev/block/mmcblk0p9 of=sdcard/mmcblk0p9.img’ and copied the file onto my linux development machine. I then used umkbootimg passing the file to it as input in order to deconstruct that file into the zImage and the Ramdisk. i then copied the Ramdisk which will be in a file called initramfs.cpio.gz into a new folder on my computer and ran unpack_ramdisk on it to get to the nitty gritty inside which is what we need. and i promptly threw out the old initramfs.cpio.gz and kept only the ramdisk folder. This allowed me to modify the “scripts” inside of it so that it would boot Linux by mounting the linux install location as / then telling if to boot using the init function that linux already has. while I was testing i decided to leave the android install mounted essentially, what that means is that the android install hides away in the filesystem inside the linux install if we ever want to boot Android into a chroot Jail of its own.
That is possible because Android’s file system and the linux filesystem being used are the same structure, but at different locations /system being empty for the Android system to occupy. This is all fine, but where do we put linux? The short answer, Wherever the heck ya want to!
My answer was to put the linux install onto my MicroSD card at /dev/block/mmcblk1p1 so that i could write an addition to the logic inside the Ramdisk to start linux or android based on whether the SD card was inserted at boot.
More yet to follow
Interesting read. It will be great to see where this leads.
Very interesting. If this develops in would love to test.
Hei @DJHenjin1 , any update on this? I would love to see ubuntu running native on my SM-T520, especially now that it is sure we are not going to get any firmware update. Anyway, nice job! Thanks
Force-Encrypt Toggler
Disclaimer: I have no experience in Android/ROM development. This is the first time i decided to share something (that i initially made for myself). Flash at your own risk. I am not responsible for boot loops, unexpectedly encrypted partitions, data loses, etc. Make sure you have a backup first!
Click to expand...
Click to collapse
Now that CyanogenMod developers stated that they are going to follow Google's guidelines about forced encryption in their ROM for Nexus 9, those of us who want their tablets unencrypted will have to flash a modified boot image every time they update CM. I hate doing such things manually every time, so i created a patch that disables forced encryption the right way - flash once and forget forever.
force-encrypt-toggler reads and unpacks your boot image, patches the ramdisk, creates a new boot image and flashes it back to the boot partition. And all that is done right on your tablet. Than it uses CM's addon.d framework, so that each time you flash a new CM zip, force-encrypt-toggler is invoked automatically to patch the newly flashed boot image. Thus, you can just upgrade through CM's built-in updater and everything will be patched automatically every time . Also, the script itself can be used on any Linux computer to patch (probably) any boot.img you have.
Thus far i have used it on my Nexus 9 to stay unencrypted starting from 20150216 through 20150224 nightlies. It seems to be quite stable, i believe . See some notes in the second post.
Download
force-encrypt-toggler-1.1-flounder.zip : https://goo.gl/bw7YDq
force-encrypt-toggler-1.1-flounder-dbg.zip : https://goo.gl/95JN34 - this one creates log files in /cache every time
force-encrypt-toggler-1.1-linux.tar.gz : https://goo.gl/3PF6ru - to be used on a desktop to patch arbitrary boot.img
old versions (for CM12): https://goo.gl/125eey
Sorry, it looks like i can not post clickable links yet. Remove space between "https" and colon.
Compatibility
I have tested this script only on my Nexus 9 Wi-Fi with TWRP recovery and CM stock boot image. However, i believe that it should be possible to make it work on other devices (e.g. Nexus 6) by just changing a few constants at the beginning.
Version 1.1 requires TWRP version >= 2.8.7.1 and a CM13 nightly >= 20160110. Version 1.0 will work for CM12.x (but not for recent CM13 nightlies).
Known issues
The addon.d script uses a dirty hack to trick the recovery. While this never happened to me, if you ever encounter a strange recovery behavior regarding installation or backup of boot images after flashing CM zip over CM with this mod, this might be it. Just reboot and it should be ok. See the second post for more info.
If CM changes something in their updater or if something changes in the recovery, this mod may easily break due to the hack mentioned above. Read the disclaimer.
Each time you flash a CM zip over a CM installation with this mod installed, TWRP recovery will hang for 5-10 seconds after reporting successful completion and before showing buttons at the bottom (or before rebooting in case of open recovery script execution). It is possible to fix this easily, but than this mod might be much easier to break.
Installation
First, you should read the disclaimer above and backup your data. Than you just have to flash the zip you downloaded with TWRP recovery. CyanogenMod must be installed first. If your /data is currently encrypted, you will have to do a full factory reset to decrypt it (backup your data first!).
Your current boot image will be patched during installation process (it should not hurt, if it's already patched). In case if something goes wrong, installation script will tell you. In any case you can get force-encrypt-toggler debug output by something like:
Code:
adb pull /tmp/fet.log
Be sure to do this before you reboot, because that file is created in the RAM.
Removal
In order to remove force-encrypt-toggler you have to delete the following files from your /system partition:
Code:
/system/xbin/mkbootimg (v1.1)
/system/xbin/unpackbootimg (v1.1)
/system/bin/force-encrypt-toggler
/system/addon.d/90-force-encrypt-toggler.sh
/system/bin/mkbootimg (v1.0)
/system/bin/unpackbootimg (v1.0)
And than restore your original boot image. You can also just format /system and flash CM again, but that is such an overkill .
Usage
Normally you will not need to run force-encrypt-toggler yourself, but in case you need, you should be able to run it both in Android and in recovery via adb shell. Just run it with --help option to see what it can do. In case you will have to debug some glitches, this command may be useful:
Code:
force-encrypt-toggler --set-not-forced --debug --dry-run --no-cleanup
If you use it on a Linux computer, this is what you will probably need:
Code:
sudo ./force-encrypt-toggler --set-not-forced [ --input path/to/boot.img --output path/to/new/boot.img ]
Note that Android and computer versions are functionally equivalent, so you can theoretically patch boot images for one Android device on another one...
Changelog
Code:
v1.1
+ use toybox instead of busybox because CM now ships only the later
+ mkbootimg and unpackbootimg are now installed to /system/xbin
+ the --help option can now be used without root privileges
v1.0 - initial release
Credits
mkbootimg is built from AOSP source
unpackbootimg is taken from this GitHub page: https://github.com/Dees-Troy/unpackbootimg
update-binary is taken from a CM zip
There is one problem with patching the new boot image from an addon.d script: CM's updater-script flashes boot image after it invokes all addon.d scripts. Therefore at a time, when the script is called, it is possible to patch only the old boot image, and than it will still be overwritten anyway. In order to overcome this, i used a very dirty hack. In short, i replace the device node with a fifo and let the updater write new boot image into it, and than... Ok, so, i think there must be a cleaner solution, so i will appreciate if a more experienced developer takes a look at my code and proposes a better solution.
As for the 5-10 second hang, it is (unexpectedly) caused by that line with "sleep 15" at the end of addon.d script. If it really annoys you, you can comment it out along with the line, where force-encrypt-toggler is called directly (not through the helper script). Updating will be a bit faster than, but if CM devs ever decide to flash boot image prior to calling addon.d scripts, you /data will be silently encrypted.
Download :: For the lazy
force-encrypt-toggler-1.0-flounder.zip : http://goo.gl/N4rZDk
force-encrypt-toggler-1.0-flounder-dbg.zip : http://goo.gl/4nXmkD - this one creates log files in /cache every time
force-encrypt-toggler-1.0-linux.tar.gz : http://goo.gl/hDFNOY - to be used on a desktop to patch arbitrary boot.img
While there was zero discussion in this thread, goo.gl tells me that there was some downloads, so someone might be actually using my small mod. If so, they might notice that it got broken around one month ago. So i decided to share a fixed version. See updated links in the description (links in the USBhost's post above are for the old version, if you wonder).
If you currently have v1.0 installed, you can just flash v1.1 over it. Note however, that if you was flashing recent nightlies while using v1.0, you /data probably have been silently re-encrypted. Also, if you current boot image is patched by v1.0, the initial patching by v1.1 during zip installation will fail, but it should work during system updates afterward. Flash stock boot image and try again if you want to be sure.
The reason for v1.0 malfunction was that around a month ago CM13 stopped shipping busybox in favor of toybox. New version is only compatible with CM nightlies >= 20160110. Also you need TWRP >= 2.8.7.1.
I never took notice to this thread before until your post in the FED thread. I am going to keep an eye on it as I have been issued lately with the FED patch saying that my device is not supported (Nexus 9 Wi-Fi). Hopefully I will have better luck with this. Thank you for sharing your.
When you put a kernel from one rom to another, you have to keep in mind the following:
Most custom roms rename the secondary init.cm.rc file with their custom name. That file is called by the main init.rc during boot and is responsible for several vital functions, such as sysinit/init.d; cpu frequencies; ril, dalvik and adb functions. So, if you put DU kernel in CM rom, the main init would call for init.cm.rc, but your boot image has no such file. Instead, you have init.du.rc. Your device will still boot, but permissions won't be set, services won't start and some functions won't work.
The proper way to change kernels is to decompile the new boot image and replace ramdisk,cpio with that from your rom where init.rc calls the proper file.