Database Develop

tun.ko for NEXUS ONE available?

as I am behind the GFW of CN I am eager to get openvpn to work (trying with TunnelDroid, with vpn binaries of WITOPIA...
unfortunately i can't get the connection to work, and apparently it is because of the lacking tun.ko
I took the only tun.ko I can find online (vpn connnections, for DROID...), but apparently the current Nexus One kernel does not support.
Does anybody have a tun.ko file that works on Nexus One?
thanks....

I have the exact same problem.......I need a tun.ko to start using witopia to get through the stupid ISP block on google Voice !!
So if anyone has any working tun.ko PLEASE PLEASE help us out !!

I got it !!
Finally......I managed to extract the tun.ko from Modaco's latest build, so credit goes to Modaco for this, I just extracted it for those who like to stick to Stock Roms (like myself for now).
I tested it and it works

How do you guys like openvpn on android? is it pretty stable? Has anyone tried using Access Server?

Are you sure you're running the stock OS?
I am still getting those messages:
insmod: init_module 'tun.ko' failed (Exec format error)
and in dmesg:
tun: version magic '2.6.29.6-cm-teknologist-0.1 preempt mod_unload ARMv7 ' should be '2.6.29-01117-g4bc62c2 preempt mod_unload ARMv7 '

@chirayu : Well, I dont like it so much right since it still needs ALOT of work. Its lacking ALOT of things right now.
@sjakub : Yep, im running the latest ERE36 update. But yea its a stock image.
I didnt see any of the errors you mentioned. I got differnet errors while I was trying it with Witopia, which didnt really work out, but it doesnt seem like a tun driver issue, it was something about an encryption key not available, still working on that.

I have ERE27, that could be why. Where did you get that update from?
Can you get some other module from that phone (like bcm4329.ko) and look for 'vermagic' string inside?

Also, how did you extract tun.ko from that build? Maybe it's possible to extract one from the ERE27-based build?

sjakub said:
Also, how did you extract tun.ko from that build? Maybe it's possible to extract one from the ERE27-based build?
Click to expand...
Click to collapse
Well, the tun.ko is tested and works fine on ERE27 and ERE36 updates so that shouldnt be the problem.
As for the other files, like bcm4329.ko . Why would you need that ? It should be there by default ? as far as i know that module is responsible for certain wireless activities, I do have that file with me if you need it.
As to how i extracted, its simple.....I made a NAND backup of my stock image then flashed Modaco's latest update including the tecknologist kernel which supported tunneling and therefore included the tun.ko. Copied the file to the sdcard, then restored the backup and copied the files to /system/lib/modules

I don't NEED that module.
I would like to know what is the value of "vermagic" inside.
This is the string that describes the version of the kernel used.
Now, if it's something like '2.6.29-01117-g4bc62c2' and the one in the tun.ko you posted is '2.6.29.6-cm-teknologist-0.1' it means that you're somehow able to load module that has a different vermagic than a kernel. If the vermagic in bcm4329.ko is '2.6.29.6-cm-teknologist-0.1' it means that you have a different version of the kernel (and not the stock one). I have no idea why it would be working with ERE27 in that case, unless it was modified ERE27, not the stock one. Or, you were able to load an incompatible module somehow. In that case I would start investigating how to do that with my kernel as well

Hm, or you could check you phone's info:
Could you, on your phone, go to "Settings->About phone" and check what it says under "Kernel version"?
Thanks!

Finaly! I figured out how to build tun.ko module for the stock kernel.
If anybody wants to repeat that:
* I have Android OpenSource installed in /opt/android
* In /opt/android I did: git clone git://android.git.kernel.org/kernel/msm.git kernel-nexus
* In kernel-nexus I did:
- git checkout -b origin/android-msm-2.6.29-nexusone
- git checkout HEAD^
(The last operation reverses one revision, I needed a previous revision from the tree. Different revisions generate modules with different vermagic values)
(Actually, instead of previous two this should work as well - it should checkout the correct revision: git checkout 4bc62c230b2942bea72c3b5258e3e4f1d6cb534b )
- make ARCH=arm CROSS_COMPILE=/opt/android/prebuilt/linux-x86/toolchain/arm-eabi-4.4.0/bin/arm-eabi- distclean
- adb pull /proc/config.gz
- gunzip config.gz
- mv config .config
- Edited .config: changed "# CONFIG_TUN is not set" to: "CONFIG_TUN=m"
- make ARCH=arm CROSS_COMPILE=/opt/android/prebuilt/linux-x86/toolchain/arm-eabi-4.4.0/bin/arm-eabi- modules
- The driver ends up in: drivers/net/tun.ko
- You can verify if it is going to match the kernel by running:
+ strings drivers/net/tun.ko | grep 2.6.29
+ It should produce "vermagic=2.6.29-01117-g4bc62c2 preempt mod_unload ARMv7"
+ The "2.6.29-01117-g4bc62c2" should be the same as the "Kernel version" in "Settings->About phone" on your phone.
* Now you can upload the module to your phone. I did:
- adb shell mount -o remount,rw /dev/block/mtdblock3 /system
- adb push drivers/net/tun.ko /system/lib/modules/
- adb shell mount -o remount,ro /dev/block/mtdblock3 /system
- And you can use adb shell, enter /system/lib/modules and run: insmod tun.ko
- It should work
The module is attached.

hey Sjakub..
I have tried using your module and I got the same thing like with the one i extracted from Modaco's mod. The tunnel droid gets stuck at "Connecting" any ideas?
Thanks again for all your work mate appreciate it !

Cyanogen Roms have built-in openvpn support. I don't have any problem using Tunneldroid on CM 5.0.4.1. I got the tun.ko error only when I was on the stock ROM. I'm also behind the GFW. Witopia does the trick for me.

thank you sjakub~i used to use your tun.ko working very well with tunneldroid.but after i update the kernel that supports tethering.the tun.ko doesn't work... the new kernel version is:2.6.29-gad36b87-dirty...

The tun.ko module has to be compatible with the kernel you have. Where did you get the kernel from? You need to find a source of exactly that kernel version and compile tun.ko yourself.

sjakub said:
The tun.ko module has to be compatible with the kernel you have. Where did you get the kernel from? You need to find a source of exactly that kernel version and compile tun.ko yourself.
Click to expand...
Click to collapse
i download the kernel for my nexus one from here ——code.google.com/p/android-wifi-tether/
and i follow the steps in the site to flash my rom :code.google.com/p/android-wifi-tether/wiki/NexusOneKernelUpdate
finally...i'm not able to use the previous workable tun.ko which you built...and i'm afraid that i was too amateur to complie tun.ko myself even though you have already list out the compiling steps...

Try asking authors of the wifi-tether for that module. That's probably the easiest way

sjakub said:
Try asking authors of the wifi-tether for that module. That's probably the easiest way
Click to expand...
Click to collapse
okay~i manage to browse that source in google code,though,i can't found tun.ko module.or maybe i will flash cyanogen rom which consist of all the necessary things

anyone brewing a tun.ko for nexus one froyo stock kernel. I don't see aosp code to build right now.

why hasnt anyone compiled modules for new ics kernel.

This is the edit to make modules work in the new kernel you must make the edit in the config.gz, tgen recompile the kernel with the new config
ACTIVATING MODULE LOADING SUPPORT IN THE KERNEL
Module loading support is previously disabled in the kernel, if we want to load modules in the kernel we have to enable it:
edit .config file and set: CONFIG_MODULES=y
We have the new ics, but no overclock or webtop without dock, and some other issues that tge older roms have. And its not because the new leaksare locked. Someone is just lazy or ignorant. So here it goes
You will need alot of free space 100GB or more of free space NO JOKE.
First go here: http://source.android.com/source/initializing.html
You may want androids kernel or cyanogens
androids kernel: http://android.git.kernel.org/
$git clone git://android.git.kernel.org/kernel/common
We check which branch we have downloaded: $git branch it shows * android-2.6.27, not the one we are searching for:
To list all remote available branches: $git branch -r
This is only refernce the kernel number for the bionic is up to 3.0 so when you git branch-r choose one for the bionic
$git checkout --track -b android-goldfish-2.6.29 origin/android-goldfish-2.6.29 $git branch
Cyanogens Follow all steps and restart computer then go here: http://wiki.cyanogenmod.com/wiki/Building_Kernel_from_source
After you have installed everything you are ready to create a complete distro from scratch.
Now go to adb and pull your working config.
adb pull /proc/config.gz
$gunzip config.gz # uncompressit. $cp config .config # renameitinto.config
Now you can edit .config file the way it suits you the most.
But really all we want is the modules for overclock and symsearch to be compiled for our new kernel
CROSS_COMPILE environment variable stores the path to the arm cross compiling toolchain. I use the one which comes with android source code.
$ARCH=arm CROSS_COMPILE=/path/to/mydroid/prebuilt/linux-x86/toolchain/arm-eabi-4.4.0/bin/arm-eabi- make
Executing make will build the kernel.
Last lines will show:
Kernel: arch/arm/boot/Image is ready Kernel: arch/arm/boot/zImage is ready
So we have obtained Image and zImage kernel binary files.
ACTIVATING MODULE LOADING SUPPORT IN THE KERNEL
Module loading support is previously disabled in the kernel, if we want to load modules in the kernel we have to enable it:
edit .config file and set: CONFIG_MODULES=y
$ ARCH=arm CROSS_COMPILE=/path/to/mydroid/prebuilt/linux-x86/toolchain/arm-eabi-4.4.0/bin/arm-eabi- make
I am asked about some options when executing make. I ask yes for module related options.
After compiling I see several modules have been built.
MODPOST 6 modules CC drivers/video/fb_sys_fops.mod.o LD [M] drivers/video/fb_sys_fops.ko CC drivers/video/syscopyarea.mod.o LD [M] drivers/video/syscopyarea.ko CC drivers/video/sysfillrect.mod.o LD [M] drivers/video/sysfillrect.ko CC drivers/video/sysimgblt.mod.o L drivers/video/sysimgblt.ko CC drivers/video/vfb.mod.o LD [M] drivers/video/vfb.ko
Ok so now we have a kernel that supports modules, but we still need the overclock.so or opptimizer.so compiled for this kernel. This is wete I stop because I dont have any of those modules and this was merely for information really. To get someone to compile our kernel for modular support.

I'm not even sure how Motorola phone devs even get the option to recompile the kernels seeing as how the locked bootloader doesn't let us modify the stock kernel in any way.
If/when we get Kexec, I could see this being an option, however.

It is easy to compile the kernel and edit it and even put it to the motorola droid.
There is actualy 2 ways not just 1.
1. first use follow steps compile kernel and apply it to a boot.img using an android-kitchen.( google android-kitchen) Once you allpy it to a boot.img we can flash in recovery or use an rsd lite and flash using the .xml just replace the boot.img with the modified kernel boot.img. The boot.img for the .875 is 8.3 megs as is the .902 boot.img.
2. use any kernel updater from kuash in recovery wich will replace the current zImage with the new kernel compiled in the steps you just followed.(google android any kernel updater)
So Like I said why hasnt anyone compiled a new kernel.

The Motorola Droid has an unlocked bootloader. The Droid Bionic does not. That is why kernel development barely ever happens on Moto devices.
Feel free to try to flash unsigned images to your Bionic. Let us know how that goes.

Booting .4.5.2 Kernel (Apollo - Old Bootloader)

@Cpasjuste,
In the image headers I noticed that the ramdisk and tag addresses have changed.
ramdisk addr: 0x02000000 -> 0x01000000
tags addr: 0x01e00000 -> 0x00000100
Please correct me if I'm wrong...
The bootloader (lk) loads the ramdisk and kernel tags (device tree) at these physical RAM locations.

@ggow
Yes i saw that but it have no effect. I'm focusing on the .dt part because I found a few things :
- The DT images can correctly be extracted with a tool named "mkboot".
- When using the DT image from kk kernel, the bootloader complains about DT not found (fastboot boot boot.img)
- Opened both DT image in hex editor, noticed some differences in the headers. I switched kk DT headers by jb DT headers, the bootloader don't complain
anymore so I guess it can now found it. But the kernel will just hang immediately.
- The DT syntax seems to have changed (arch/arm/boot/dts/thor.dtsi), this may be the problem for our old bootloader ?!
- Now I'd like to use compiled dt from kk kernel, but has you may have noticed the DT compilation fail about "fb_mem" not declared. I think I need to fix this, then maybe use old jb tools ( $KERNEL_OUT/scripts/dtc/dtc -p 2048 -O dtb -o thor-v1.dtb arch/arm/boot/dts/thor-v1.dts) to compile them, unlike kk kernel which now compile them with the kernel.
From what iv read dt, kernels and bootloaders are linked together, so there is also maybe some changes to be done in the dt sources. But this start to be out of my knowledge.
I asked to hashcode for that but I guess he is very busy.

Cpasjuste said:
@ggow
Yes i saw that but it have no effect. I'm focusing on the .dt part because I found a few things :
- The DT images can correctly be extracted with a tool named "mkboot".
- When using the DT image from kk kernel, the bootloader complains about DT not found (fastboot boot boot.img)
- Opened both DT image in hex editor, noticed some differences in the headers. I switched kk DT headers by jb DT headers, the bootloader don't complain
anymore so I guess it can now found it. But the kernel will just hang immediately.
- Now I'd like to use compiled dt from kk kernel, but has you may have noticed the DT compilation fail about "fb_mem" not declared. I think I need to fix this, then maybe use old jb tools ( $KERNEL_OUT/scripts/dtc/dtc -p 2048 -O dtb -o thor-v1.dtb arch/arm/boot/dts/thor-v1.dts) to compile them, unlike kk kernel which now compile them with the kernel.
From what iv read dt and kernels are linked together, so there is also maybe some changes to be done in the dt sources. But this start to be out of my knowledge.
Click to expand...
Click to collapse
I noticed the "fb_mem" not declared error and couldn't find any reference to it anywhere. I switched the dt.img header also and got to the point where the kernel was not dumping out to fastboot any more, but instead bootloops.
I have messaged amazon once again to post the source code for apollo and thor for update .4.1.1 .

Hehe we are at the same point it seems (nowhere)

Today I did spent a lot of time on this. After a lot of dt hacks/test I'm unable to resolve this problem for now. So I had another idea and started to port kexec hardboot for our device. I'm at the point where is successfully load kernel and DT (something is different for our device, the msm_id struct, which I solved) and reboot but will hang or restart just after a few seconds of the reboot. I think I'm almost there but I may have some problem to find correct memory addresses which are not overwritten by the boot loader. Let me know if you want to take a look I'll upload patches. But well even if we succeed we may still encounter the same DT problem.
In the "dt.img" there is 3 dtb files in, which are scanned by the bootloader for the correct hw revision. I did find that our device use the "thor-v2-apq.dts/.dtb" dt file for booting (not the thor-v1 nor v2) which correspond to our hardware revision. This is in correlation to the 4.1 kernel which only compile this dtb.
When loading the 4.1 dt image with kexec I was able to debug and see that while the header of each dtb parts have changed, there's still the correct hw revision included (of course!?). This one is correctly loaded by kexec and so probably by the bootloader (but in the new dt.img we still need to modify the img header for our bootloader to find it). By the way, I wonder how this final dt.img is built !?
I just don't know yet what is the thor.dtsi file in the 4.1 kernel, the one missing the fb_mem def. This is not included in the dt.img so should it be modified to match our old thor-v2-apq.dts instead the new one ?
By the way manual compilation (and decompilation!) does work with the dtc utility (apt-get install device-tree-compiler).

Yes, upload the the patches for kexec. Definitely interested in taking a look. I have configured a kernel last night with kexec config enabled (great minds think alike)
This DT problem is troubling me. Perhaps not everything is included in this kernel for Apollo or Thor to boot.
I received a reply from amazon, they said they will post the missing source for the last 3 updates very soon (no idea of time frame).
Sent from my Full Android on C6603 using Tapatalk

I don't think the sources are the problem as we have it on stock 4.1 boot.img. I'll upload the patches tomorrow with a little briefing.

@ggow : 4.1.1 kernel booted (not from sources. As you noted this sources may be incomplete).
I'll post the kernel this night, with a clean 4.1.1 system if i have the time.

Cpasjuste said:
@ggow : 4.1.1 kernel booted (not from sources. As you noted this sources may be incomplete).
I'll post the kernel this night, with a clean 4.1.1 system if i have the time.
Click to expand...
Click to collapse
Good News, well done

ggow said:
Good News, well done
Click to expand...
Click to collapse
Finally, sorry for the delay So here is the modded 4.1.1 boot image. In short : binary extract correct dts from 4.1.1 stock dt image and happend it to 4.1.1 stock zImage.
Didn't had the time to finish my gapps rom based on 4.1.1 but should not be too long
http://android.mydedibox.fr/hdx/boot-4.1.1.img

Cpasjuste said:
Finally, sorry for the delay So here is the modded 4.1.1 boot image. In short : binary extract correct dts from 4.1.1 stock dt image and happend it to 4.1.1 stock zImage.
Didn't had the time to finish my gapps rom based on 4.1.1 but should not be too long
http://android.mydedibox.fr/hdx/boot-4.1.1.img
Click to expand...
Click to collapse
Good work looking forward to testing it out.
Sent from my Optimus G using XDA Free mobile app

cdub50 said:
Good work looking forward to testing it out.
Sent from my Optimus G using XDA Free mobile app
Click to expand...
Click to collapse
This is a wip for you. You need to wait for a root exploit on 4.1.1 for using it !

Cpasjuste said:
This is a wip for you. You need to wait for a root exploit on 4.1.1 for using it !
Click to expand...
Click to collapse
Ah gotcha. Hopefully that will be sooner than later.
Sent from my Optimus G using XDA Free mobile app

Cpasjuste said:
Finally, sorry for the delay So here is the modded 4.1.1 boot image. In short : binary extract correct dts from 4.1.1 stock dt image and happend it to 4.1.1 stock zImage.
Didn't had the time to finish my gapps rom based on 4.1.1 but should not be too long
http://android.mydedibox.fr/hdx/boot-4.1.1.img
Click to expand...
Click to collapse
Thanks for that
Which number dts is the correct one (there are 3). I need to do the same for Apollo...

ggow said:
Thanks for that
Which number dts is the correct one (there are 3). I need to do the same for Apollo...
Click to expand...
Click to collapse
From what i remember this is the third (which is thor-v2-apq.dtb)

Well, cm is still a ***** to get ported :/, tree days on it without success.
Else the new odex framework is not deodexable by baksmali. If you ever have a solution let me know (You may not need that but I'm in a dead end).

So @ggow, did you made some progress on resurecting your device ?
In the meantime i did get msm aosp up and running ! (but no wifi, qcmediaplayer not found for no apparernt reason which prevent some audio to work, slow ui transitions and probably more stuff to fix).

Cpasjuste said:
So @ggow, did you made some progress on resurecting your device ?
In the meantime i did get msm aosp up and running ! (but no wifi, qcmediaplayer not found for no apparernt reason which prevent some audio to work, slow ui transitions and probably more stuff to fix).
Click to expand...
Click to collapse
So far no...
What I think could have happenned is the synaptic dsx firmware and configuration has been updated or corrupted by the new kernel.
I am in the process trying to figure out exactly what I need to do to fix it. I have found a utility which can be used to force an update to an older version of synaptic firmware.
I might have to write a utility to extract the firmware and configuration area from a working device.
Will let you know what I find.
Sent from my Kindle Fire HDX 7 using Tapatalk

ggow said:
So far no...
What I think could have happenned is the synaptic dsx firmware and configuration has been updated or corrupted by the new kernel.
I am in the process trying to figure out exactly what I need to do to fix it. I have found a utility which can be used to force an update to an older version of synaptic firmware.
I might have to write a utility to extract the firmware and configuration area from a working device.
Will let you know what I find.
Sent from my Kindle Fire HDX 7 using Tapatalk
Click to expand...
Click to collapse
Yep i was just going to talk you about this. I'm trying to fix wifi on the aosp build and discovered this lines in dmesg :
<6>[ 6.404807] synaptics_dsx_i2c 2-0020: fwu_start_reflash: Requesting firmware image Synaptics.3.B.thor.img
<6>[ 6.414184] synaptics_dsx_i2c 2-0020: Firwmare size 45056, config size 512
<6>[ 6.421216] synaptics_dsx_i2c 2-0020: Device firmware id 1509905.
<6>[ 6.427045] synaptics_dsx_i2c 2-0020: Device config ID 0x13, 0x07, 0x00, 0x02
<6>[ 6.434233] synaptics_dsx_i2c 2-0020: .img config ID 0x13, 0x07, 0x00, 0x02
<6>[ 6.441127] synaptics_dsx_i2c 2-0020: Nothing needs to be updated
<6>[ 6.447230] synaptics_dsx_i2c 2-0020: fwu_start_reflash: No need to do reflash.
Click to expand...
Click to collapse

Thank you for your work! I hope your problem will spill over into different firmware for our device. With the support of LTE I hope.

[Q] Init.d Support & SELinux

I am sure this will soon be moved into general ware it will sit among questions not related to compiling or Rom building but I am in hope it is her long enough to be read and maybe addressed.
I rely a bit on init.d support for my Rom's especially CM12. I do this so changes can be made without changing the code or default.xml as much as possible in adition to Google Apps I would like not included. My basic philosophy is if it can be installed via Play Store than I would like the first boot only to include the Google Core files and Play Store so for example if you look at the below github link will see the changes I needed in CM11 to replace the default launcher with the Now Launcher, Replace Stock Camera with Google Camera and the same for the Calendar but would like the users to decide if they would like to include whatever apps they would like as oposed to needing to remove the APK. Anyhow in short I use init.d to avoid making as little changes to code or default.xml as possible as well as what gapps package is used. Many include incompatible libs as a few for my CM based incarnation need to be replaced using either the Stock lib or libs taken from data/app that are more current so the script on first boot after flashing gapps will move files from a staging directory and place or replace ware needed and then remove the staging directory.
CM11
https://github.com/Starship-Android/android_device_starship-common/blob/cm-11.0/app-update
https://github.com/Starship-Android/android_device_starship-common/blob/cm-11.0/cleanup
CM12
https://github.com/Starship-Android/android_device_starship-common/blob/cm-12.0/app-update
https://github.com/Starship-Android/android_device_starship-common/blob/cm-12.0/cleanup
So far have done a decent amount of Google work and have learned my problem with both AOSP and CM is that SELinux is blocking init.d but have not found anything on how to address steps on fixing for what I use it for. The above links are just a small part but give enough of an idea of what I am trying to accomplish via init.d.
Any help would be appreciated. Until now I had fought a bit with SELinux once introduced to apply to the Kernel for the device I was developing at the time HTC EVo V 4g & EVO 3D but since then is still unfamiliar territory as I have not needed to learn much about it other than implementing into a Kernel when cm-10.2 was released. Both Devices had not been updated past ICS by HTC. I am thinking that maybe I need to add or change permissions in one of the rc files in the boot.img but honestly not sure as mentioned I have found plenty of mentions that SELinux is what is causing my init.d problems but have not seen anything on a solution or even just a link to an explanation of what specific changes had been made regarding SELinux or a further more detailed explanation specific to what in SELinux is responsable so can try to understand enough to figure out myself how to make the necessary changes .
Otherwise like my previous thread on What needs to be done differently developing with AOSP for developers who have gained all their experience bringing Cyanogen to new devices and other Sources who are now trying to develop AOSP Rom's for Nexus devices think this is a topic that would help developers save time and research but will probably be moved to general Q&A. Is off topic but with other Devices if questions or topics required basic knowledge of compiling source, Kernel changes or github would see the opposite in the threads being moved into developer discussions and not for example move a thread discussing say compiling the AOSP Kernel in line compiling both Rom and Kernel together or code changes needed in the build repository / Directory to stop custom recovery from being replaced with Stock recovery when users flash a custom Rom and reverting from Block based update zips to using the old school non Block based update zips. So far though I have posted these topics here as you don’t see members with such knowledge looking through the general Q&A section. Maybe I just inadvertently made an enemy of an admin as was surprised almost besides myself when a previous thread in the middle of discussing what changes would be needed for in line AOSP Kernel compiling in line like CM does compiling the Kernel along with the Rom and doing away with pre built Kernels. Needless to say the discussion was moved and died in general Q&A so if this is actually read I am asking that this thread remain in Developer Discussion long enough for an answer or at least a link to a resource covering the topic as a topic regarding the implementation of SELinux policy in a custom Rom will surely die in general Q&A, Thanks!

Are you OK with just disabling selinux? That's what I ended up doing. I recompiled the kernel with the option of using a boot command-line parameter to enable or disable as I see fit.

Gene Poole said:
Are you OK with just disabling selinux? That's what I ended up doing. I recompiled the kernel with the option of using a boot command-line parameter to enable or disable as I see fit.
Click to expand...
Click to collapse
When you have the option to disable or enable it, how do you set it to "disabled" afterwards?
I tried to compile a kernel+rom with selinux disabled many times but got only bootloops. With Kitkat it was working flawless.

L changed a partition entry adding a selinux policy to the mounting information. You need to change this entry int fstab.hammerhead to keep it from hanging on boot:
Code:
/dev/block/platform/msm_sdcc.1/by-name/modem /firmware vfat ro,shortname=lower,uid=1000,gid=1000,dmask=227,fmask=337[COLOR="Red"],context=u:object_r:firmware_file:s0 [/COLOR] wait
Code:
/dev/block/platform/msm_sdcc.1/by-name/modem /firmware vfat ro,shortname=lower,uid=1000,gid=1000,dmask=227,fmask=337 wait
Then your kernel should boot. You can add a command line entry to the boot image to turn it off or on.
Edit:
You may also have to comment out a line at the top of init.rc. I'm not sure, but mine is commented so I must have done it for some reason.
Code:
# Copyright (C) 2012 The Android Open Source Project
#
# IMPORTANT: Do not create world writable files or directories.
# This is a common source of Android security bugs.
#
import /init.environ.rc
import /init.usb.rc
import /init.${ro.hardware}.rc
import /init.${ro.zygote}.rc
import /init.trace.rc
on early-init
# Set init and its forked children's oom_adj.
write /proc/1/oom_score_adj -1000
# Apply strict SELinux checking of PROT_EXEC on mmap/mprotect calls.
[COLOR="Red"]#write /sys/fs/selinux/checkreqprot 0[/COLOR]
# Set the security context for the init process.
# This should occur before anything else (e.g. ueventd) is started.
setcon u:r:init:s0
# Set the security context of /adb_keys if present.
restorecon /adb_keys
start ueventd
# create mountpoints
mkdir /mnt 0775 root system

Thanks, will give it a shot!
Any downside on disabling it?

Well, obviously, anything that selinux might be protecting you from would be able to get through, but as developers, we're pretty pessimistic about what we run on our devices.

Gene Poole said:
Well, obviously, anything that selinux might be protecting you from would be able to get through, but as developers, we're pretty pessimistic about what we run on our devices.
Click to expand...
Click to collapse
So its only f*** the NSA for us then!
So i add this to boardconfig: androidboot.selinux=disabled
Then do those things you said. Would i need to put on kernel defconfig :
#CONFIG_SECURITY_SELINUX=is not set
Or will i have to add that "allow selinux disabled on boot"
Or is it enough to have that boardconfig parameter and your things.
Thank you very much mate!
Oh and yes im building a full rom with inline kernel

I think that should do it. I've got a pretty hacked up boot.img so I can't be sure what's in there for what.
I have the following setting in my kernel config:
Code:
CONFIG_SECURITY_SELINUX=y
CONFIG_SECURITY_SELINUX_BOOTPARAM=y
CONFIG_SECURITY_SELINUX_BOOTPARAM_VALUE=1
CONFIG_SECURITY_SELINUX_DISABLE=y
CONFIG_SECURITY_SELINUX_DEVELOP=y
CONFIG_SECURITY_SELINUX_AVC_STATS=y
CONFIG_SECURITY_SELINUX_CHECKREQPROT_VALUE=1
# CONFIG_SECURITY_SELINUX_POLICYDB_VERSION_MAX is not set
CONFIG_DEFAULT_SECURITY_SELINUX=y

Ok thanks for all the Selinux help but may look like I’m not able to run init.d scripts because root is disabled by default. So bringing up a new topic about starting first boot with root access. I have been looking over the CM github for a commit that turns it off so I can either manually revert or rebase a clone.

Gene Poole said:
L changed a partition entry adding a selinux policy to the mounting information. You need to change this entry int fstab.hammerhead to keep it from hanging on boot:
Code:
/dev/block/platform/msm_sdcc.1/by-name/modem /firmware vfat ro,shortname=lower,uid=1000,gid=1000,dmask=227,fmask=337[COLOR="Red"],context=u:object_r:firmware_file:s0 [/COLOR] wait
Code:
/dev/block/platform/msm_sdcc.1/by-name/modem /firmware vfat ro,shortname=lower,uid=1000,gid=1000,dmask=227,fmask=337 wait
Then your kernel should boot. You can add a command line entry to the boot image to turn it off or on.
Edit:
You may also have to comment out a line at the top of init.rc. I'm not sure, but mine is commented so I must have done it for some reason.
Code:
# Copyright (C) 2012 The Android Open Source Project
#
# IMPORTANT: Do not create world writable files or directories.
# This is a common source of Android security bugs.
#
import /init.environ.rc
import /init.usb.rc
import /init.${ro.hardware}.rc
import /init.${ro.zygote}.rc
import /init.trace.rc
on early-init
# Set init and its forked children's oom_adj.
write /proc/1/oom_score_adj -1000
# Apply strict SELinux checking of PROT_EXEC on mmap/mprotect calls.
[COLOR="Red"]#write /sys/fs/selinux/checkreqprot 0[/COLOR]
# Set the security context for the init process.
# This should occur before anything else (e.g. ueventd) is started.
setcon u:r:init:s0
# Set the security context of /adb_keys if present.
restorecon /adb_keys
start ueventd
# create mountpoints
mkdir /mnt 0775 root system
Click to expand...
Click to collapse
Bumb to this method. Something is changed in Nougat, after editin all these stuff, i will loose data and cell connections..

node.js for rooted Chromecasts

For anyone interested, I've built a node v4.1.1 binary[1] that works on a rooted Chromecast. It's the binary only, so no npm (npm won't work with the default shell anyway since npm expects a more featured shell like bash). It's also compiled statically (with musl libc) so you cannot load compiled addons with it unfortunately (compiling statically was a heck of a lot easier to do than trying to link against the Chromecast's existing glibc).
Other than those two limitations, everything else should work (including HTTPS/TLS).
EDIT: For anyone who wants to build their own binary, here is what I did:
1. Download a node.js (4.0.0 or newer) source tarball and extract it
2. Download a pre-built musl-based (glibc alternative) cross-compiler for armhf[2] and extract it (compiling your own musl-based cross-compiler is not hard either but does take some additional time)
3. Set up the environment:
export CXXFLAGS="-march=armv7-a -mfpu=vfpv3"
export CC=/path/to/arm-linux-musleabihf/bin/arm-linux-musleabihf-gcc
export CXX=/path/to/arm-linux-musleabihf/bin/arm-linux-musleabihf-g++
Click to expand...
Click to collapse
4. Change to the node.js source root dir and configure with: ./configure --dest-cpu=arm --dest-os=linux --fully-static --with-arm-float-abi=hard
5. Compile: make -j8
6. Copy out/Release/node to your Chromecast (you may want to strip the binary to reduce the footprint further)
It's also worth noting this same binary should work on any armv7 device (it's a completely static binary -- no dependencies).
[1] mediafire(dot)com/download/igx3gasz723d60b/node.tar.xz
[2] e82b27f594c813a5a4ea5b07b06f16c3777c3b8c.googledrive(dot)com/host/0BwnS5DMB0YQ6bDhPZkpOYVFhbk0/musl-1.1.6/crossx86-arm-linux-musleabihf-1.1.6.tar.xz