HTC Legend: full r/w access via overlay filesystem - Legend Android Development

Hey all,
No idea at all if this is possible or even applicable to the Legend [I'm not a dev, but still learning about Android ], but I thought it deserves a thread of its own just in case the method allows us to run metamorph on the Legend...
ValMar73 posted the quoted text below HERE
ValMar73 said:
Dear All,
I just noticed that people applied a trick to desire roms to obtain a kind of writing permissions on /system. Essentially, they create a "shadow" /system dir and the system looks for files in this dir before getting the ones from system.
See the details here:
http://forum.xda-developers.com/showthread.php?t=748025
People could run metamorph on the Desire with this and they applied to CM6 nightlies (Desire version)
Now, this should be applicable also to the Legend, right? All that is needed is the aufs module for the kernel. Does anyone know if this module is in the kernel in CM6 for the Legend?
Valerio
Click to expand...
Click to collapse
If the above is not applicable to the Legend... MOD: please feel free to delete thread.

I. they havn't succeed.
II. our kernel didn't include aufs, neither desire. you should compile module. it's called cross compile to get binaries via a pc.
or you can use aufs module for desire, with your own risk. anyway, it couldn't turn your legend to a bomb.
III. you should remount aufs to "the right mountpoint".
you should change fstab with update.zip <------ it could damage your system.
IV. sorry for my pool english.

Theta did succeed. The thread is listed as Fixed. On Page 6 they are discussing how to best implement it.
Sent from my Desire using Tapatalk

thx i ll try later
it could be used on legend after "cross compile".

Yes, it could be done. The principle is the same as on those Asus EEE PCs. Haven't read that Desire thread in all but I'm familiar with procedure to achive this. But the question is... is it worth? What would one gain with this? You still won't be able to remove fileas from system partition for real and you'll have references to "deleted" files on data partition which also will take space and inodes. So basically for any "deleted" file from system partition, you'll have less space on data partition.
First as lucloner said, you need aufs module. Then you'll need rw store. It can be directory on data partition or small image with file-system in it also on data partition. Then you have to mount aufs and mount-move partitions to the right places. It is imperative that this procedure is done as soon as possible in init.rc before any other service is run. Guys at Desire thread put the script into run-parts init.d script (I believe) which I wouldn't suggest. The possibility to damage the system is really infinitesimal and everything can be reversed. Also fstab is not an issue as there is no fstab in initramfs environment.
When I have time (possibly beginning of next week) I will prepare myself a cross-compiling environment for compiling kernel and try to compile aufs module for Legend's 2.6.29-5f084974 kernel. Then I will try to prepare init.rc with integrated aufs procedure.

if you will compile a kernel, plz add compcache module which already included in the kernel.
i'm lazy lucloner. lol

Have you tried compcache on some embedded device yet? I mean what's the actual gain? You have to take into acount that you have slow processor and compression would take time thus battery would drain faster.

compcache is great! it performans in my pIII laptop with 480 ram and ubuntu 10.04.
if you want to more ram, compcache is faster and better than swap. and drain battery faster for sure.
as a module, it could be disabled. i just decide to try.
in wiki:
wiki.cyanogenmod.com/index.php?title=Swap_and_Compcache
-------------
no i've not tried it on embedded device.
forgive my damn english.

OK guys, I managed to cross-compile Legend's kernel and add aufs module. I tried it and it worked.
You can download kernel and aufs module for Legend 2.03.405.3 (kernel version 2.6.29-5f084974) and give it a shot. Be advised, that there is only kernel image (not boot.img) and actual module aufs.ko in this zip archive.
You can try aufs like this (of course you have to be root and know what you are doing):
Code:
insmod /<dir_to_aufs_module>/aufs.ko
mount -o remount,rw rootfs /
mkdir /aufs
mkdir /rw
mount -o dirs=/rw:/data=ro -t aufs none /aufs
...now you should see contents of /data in /aufs. Any changes to /aufs should now be reflected in /rw and /data stays intact. Be careful not to drain all RAM as you are playing on initramfs
Please report back or feel free to continue the implementation.

Thread Closed.
New thread from BlaY0 Here: http://forum.xda-developers.com/showthread.php?p=7983387

Related

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.

[Q] CIFS support in kernel

I am not a developer, and I know NC just rooted in few days but we have made great progress to make NC as a full function tablet. I am just curious to know how far we leave to have a CIFS supported kernel.
My dream is quite simple, I want my NC can play tons of video files in my NAS via wifi, so CIFS kernel is the first step to make it true.
Kernel version
If someone can tell me the Android kernel version that is on the NookColor I can experiment with CIFS.
Thanks in advance,
according Nookdevs,
Operating system Android 2.1 (Eclair based on Linux kernel 2.6.29)
ctos said:
I am not a developer, and I know NC just rooted in few days but we have made great progress to make NC as a full function tablet. I am just curious to know how far we leave to have a CIFS supported kernel.
My dream is quite simple, I want my NC can play tons of video files in my NAS via wifi, so CIFS kernel is the first step to make it true.
Click to expand...
Click to collapse
If we can get CIFS support then we can use CIFS manager to mount shares locally.
and use rockplayer or the built in media player to play videos over wifi.
http://forum.xda-developers.com/showthread.php?t=756158
I wonder if we can compile the CIFS.ko module from the source released by B&N.
I will have a look over the weekend if time permits.
hi dascud,
nice to hear you will have a try and waiting for your good news.
i'm not a *nix developer, but since we can install Optware on the NC can we install the samba packages and achieve this?
Samba is probably too fat for the nook. CIFS kernel support shouldn't bo difficult. Mounting the shares directly is way more efficient.
ctos said:
hi dascud,
nice to hear you will have a try and waiting for your good news.
Click to expand...
Click to collapse
So I downloaded the source and compiled the cifs module and the nls_utf8 modules.
modinfo shows that the modules version is
vermagic: 2.6.29-omap1 preempt mod_unload ARMv7 which matches with the running nook kernel.
Unfortunately no luck trying to insmod the modules.
I think the running kernel may have no support for loadable modules and we may need to recompile and replace the stock kernel for loadable module support.
If anyone else wants to give it a shot here are the links to the compiled modules.
http://dl.dropbox.com/u/16190398/cifs.ko
http://dl.dropbox.com/u/16190398/nls_utf8.ko
dascud said:
Unfortunately no luck trying to insmod the modules.
I think the running kernel may have no support for loadable modules and we may need to recompile and replace the stock kernel for loadable module support.
Click to expand...
Click to collapse
I only dabble in Linux so I may be way off here, but I'm pretty sure there's loadable modules in the firmware that are being used.
clockworx said:
I only dabble in Linux so I may be way off here, but I'm pretty sure there's loadable modules in the firmware that are being used.
Click to expand...
Click to collapse
Ok. We have a working cifs.ko and nls_utf.ko . I was able to mount my win7 share using cifs manager and play a few movies using mvideoplayer from the mounted share.
My initial problem seemed to be that I used the android ndk toolchain and the nook kernel is compiled with the codeSourcery toolchain.
After I re-compiled using the codeSourcery toolchain everything works (at least for now)
For those who want to try this.
Download the cifs.ko and nls_utf8.ko modules.
http://dl.dropbox.com/u/16190398/cifs.ko
http://dl.dropbox.com/u/16190398/nls_utf8.ko
Mount /system as read write and create a directory under /system/lib called modules. Just copy the cifs.ko and nls_utf8.ko modules under this directory.
Type the following from your windows or linux console.
adb shell
#mount -o remount,rw /dev/block/mmcblk0p5 /system
#su
#cd /system/lib
#mkdir modules
#exit
#exit
Now you are back in your windows or linux command prompt
adb push cifs.ko /system/lib/modules
adb push nls_utf8.ko /system/lib/modules
adb shell
#su
#insmod /system/lib/modules/cifs.ko
#insmod /system/lib/modules/nsl_utf8.ko
if everything went well you should see no errors.
#lsmod
(THis should give you a list of running modules)
You should see something like
nls_utf8 1856 0 - Live 0xbf153000
cifs 240060 0 - Live 0xbf113000
#exit
#exit
Download cifs_manager from the android market and follow the instructions from
http://forum.xda-developers.com/showthread.php?t=756158
BTW, you can copy the modules anywhere you like even under /sdcard/modules but the default path used by cifs_manager is /system/lib/modules.
Awesome! I am eager to try this out. I have CiFs working on my EvO and it rocks.
Sent from my LogicPD Zoom2 using Tapatalk
Cool! Dascud, you are the man!
I will have a test after upgrading my NC to 1.0.1.
Thanks a million for your efforts!
Nice.
Installed the modules and cifs manager (which I haven't used before.)
Just set up a test share...
NC rebooted.
Booting again now, not sure what is up. I have not had any file sharing configured on my network for a while so its entirely possible that I have a share misconfigured or something not installed. Late now, so I will try more tomorrow.
can somebody please reupload
cifs.ko
nls_utf8.ko
They are not on dropbox any longer.
Thanks.
There you go....
thank you ser
Does anyone know if this will work in rooted 1.2? tried the steps as described, have cifs.ko and nls_utf8.ko in /system/lib/modules, but all I get is "Exec format error"
Any ideas? Thanks!

Disable charge led CWM flashable zip

Hello everyone,
I am trying to create a CWM flashable zip that will disable the charge led. My wife hates the led shinning all night long on the bedside table.
Consider this a 1.0 version that does not work.
Any help correcting the zips would be greatly appreciated!
http://dl.dropbox.com/u/56179974/Disable green charge LED.zip
http://dl.dropbox.com/u/56179974/Disable red charge LED.zip
http://dl.dropbox.com/u/56179974/Enable charge LEDs.zip
Thanks!
You shouldnt be modifying /sys files in that manner, you should be echoing values into them via a script.
Unfortunately there's no particularly reliable way of execing scripts on boot,
not all the kernels have the init script or install-recovery.sh
Depending on the kernel you could plug the entries into that and have them feed values into /sys
Edit: /sys is a virtual filesystem, it gets built on boot at every boot. You cant write to it during recovery as it disappears when you reboot.
What would be a good kernel to try?
From what I gather I could for instance use a terminal emulator to change the value or I could modify the init script to apply the value at boot?
It's not the kernel specifically, it's the ramdisk it includes.
Here's a quick rundown of how booting works:
Device is powered on -> bootloader starts loading kernel -> kernel loads ramdisk -> ramdisk scripts start loading android core -> boot time scripts and services are loaded
Dell devices have an init.device.post-boot.sh (or something along those lines), but a quick peek though the stock 5xx ramdisk shows that it's not enabled in it (I believe)
They also have flash-recovery.sh, but it might be missing in the HS kernels, so it's the same situtation.
I'd say the simplest way is to make them in scripts and just use a script pharser (like gscript) and load them that way.
Otherwise you would need ramdisk mods and reflash the kernel with the new ramdisk that lets you load more scripts at boot.
/data, /cache, and /system are mounted
/dev and /sys are spawned as they're virtual FS's containing telemetry from the kernel.
Thank you again for the useful information!
When you say "the stock 5xx ramdisk shows that it's not enabled in it (I believe)" does that mean that the init scripts are inaccessible after boot? I am working with the devs on getting Boot Manager working for the DS7 and we keep running into issues building the file system.
The ramdisk has a whitelist of scripts to exec:
The init.<device>.post-boot.sh script was added by dell in most kernels, they simply didnt add it into the stock 5xx ramdisks as they didnt have anything to put into them apparently.
If you check init.<device>.rc or init.rc on "/", look for these two entries:
Code:
service streak-post-boot /system/bin/sh /system/etc/init.streak.post_boot.sh
user root
disabled
oneshot
and
Code:
on property:init.svc.bootanim=stopped
start streak-post-boot
As it demonstrates, it feeds /system/etc/init.streak.post_boot.sh to sh when the boot animation has completed.
But they removed those entries from the stock 5xx ramdisk, they're simply not there anymore.
It still loads /system/etc/install-recovery.sh, you could use that as it does get loaded by the stock kernel.
At least on my rom the file doesnt exist at all, so you could simply replace it.
But if you were to do that the right thing to do is simply have the user modify it themselves, if they already have one with things they added. (this isnt that likely though)
Thanks again TheManii!
I would be working on this but unfortunately my DS7 bent a pin so as of now it is out of commission
I have new connectors on order (10 pack was the minimum) so I am hoping to have it going again soon
why not just implement duct-tape over the light? low-tech solution to your high-tech approach
Because that wouldn't involve me learning to code, etc
Too bad it isn't a problem now anyway considering my DS7 is a goner....
Wetzel402 said:
Because that wouldn't involve me learning to code, etc
Too bad it isn't a problem now anyway considering my DS7 is a goner....
Click to expand...
Click to collapse
check batterystats.bin, it might be related, didnt get a good look at it with my battery dying on the train home
I would but as I stated my DS7 took a dive. The charging port bent a pin and is now shot. A parts tablet on ebay maybe....
Wetzel402 said:
I would but as I stated my DS7 took a dive. The charging port bent a pin and is now shot. A parts tablet on ebay maybe....
Click to expand...
Click to collapse
How much would you want for parts?
PM sent
suggest removing block "# Eric Liu+" -> "# Eric Liu-" in init.rc might help those who are still using their S7.. the nexus7 probably stole the interest though
Anything proceeded with a "#" is a comment and doesnt do anything

[MOD][P905] enable init.d support for stock rom LTE QUALCOMM ONLY!

At first, I am not liable for any harm or damage that may happen to your device!
If you have su and didn't trigger knox, I CANNOT guarantee that running this script won't cause 0x1!
Requirements:
1) P905/viennalte/Qualcomm based model ONLY (won't work on Exynos devices. MIGHT work on other Qualcomm LTE deices from Note Pro and Tab Pro series - feel free to repost but give credits!) running 4.4.2 stock;
2) root access with SuperSU (using cf-root - credits to chainfire);
3) busybox installed (I do recommend this paid installer: https://play.google.com/store/apps/details?id=stericson.busybox.donate , MOST PROBABLY free version will be more than enough, too, but I haven't tested it as I have license...)
4) Android Terminal Emulator installed ( free at: https://play.google.com/store/apps/details?id=jackpal.androidterm )
Installation:
1) download file init.d_qcom.sh using below link and put it in the root of internal memory (so it will be placed in: /sdcard/init.d_qcom.sh)
2) run Android Terminal Emulator
3) at command line, type:
Code:
su -c /sdcard/init.d_qcom.sh
(give it an access if requested)
4) voila.
Additional info for advanced users:
1) scripts in /system/etc/init.d shall be root:root 755 (and NOT 777 as stated in A LOT of sources, thou has to be a heavy idiot to give write access for system files to "world"...)
2) init.d is handled from one of the /system/etc qualcomm additional scripts as it refused to work using regular install-recovery.sh method...
3) scripts are triggered paralelly but I am using different method (find/nohup/su combination...), as this damn rom refused to simply execute "run-parts" applet...
4) init.d permission helper script included (just put your scripts in init.d and they'll receive proper permissions on reboot)
Download:
http://www12.zippyshare.com/v/32009778/file.html
Nice to see some developement for this tab!
Anyway to port it to exynos? :fingers-crossed:
prohackerbro said:
Nice to see some developement for this tab!
Anyway to port it to exynos? :fingers-crossed:
Click to expand...
Click to collapse
+1
sent from my amazing NotePro 12.2 via Tapatalk
Criminal23 said:
+1
sent from my amazing NotePro 12.2 via Tapatalk
Click to expand...
Click to collapse
I might try, however I do not own the device and the file structure is completely different.. Can you first enter via Android Terminal:
Code:
su
ls -l / >/sdcard/content.txt
ls -l /system/etc >>/sdcard/content.txt
And post the /sdcard/content.txt file which will be created (or its contents only)?
Also, i would be glad if you copy every *.rc file from root of filesystem to a dir , compress it to one file and post it too
esgie said:
I might try, however I do not own the device and the file structure is completely different.. Can you first enter via Android Terminal:
Code:
su
ls -l / >/sdcard/content.txt
ls -l /system/etc >>/sdcard/content.txt
And post the /sdcard/content.txt file which will be created (or its contents only)?
Also, i would be glad if you copy every *.rc file from root of filesystem to a dir , compress it to one file and post it too
Click to expand...
Click to collapse
Here you are
Criminal23
Criminal23 said:
Here you are
Criminal23
Click to expand...
Click to collapse
Criminal23 said:
Here you are
Criminal23
Click to expand...
Click to collapse
After looking into sent (and posted) files, I have to say that the init process in our devices are ABSOLUTELY different.
Qualcomm version triggers about 7-8 scripts lying in /system, which are provided by Qualcomm, which are pointed in configuring all the hardware provided with their chipset - in addition to init.???.rc files from the kernel. The clue was to add init.d execution command at the very end of one of those scripts (and that is done automatically with script attached in the first post).
Exynos version does not launch (almost - see below) ANY external script during the boot. Whole process seems to be performed by rc files lying in root of the filesystem, which are embedded in kernel's ramdisk and any edits won't preserve the reboot, so it cannot be done without repacking the kernel and that is something far more troublesome to perform without device in hand, without the firmware on disk and without a plenty of time.
BUT
it still runs /system/etc/install-recovery.sh which is an Android standard and which genuine purpose was to reflash recovery back to stock if a custom one was detected. Now, it is sometimes utlized to run somehing at boot, especially: it is used by SuperSu (in addition with other methods) to run its daemon. The problem is that kitkat introduced enforcing SELinux, that Samsung SELinux policy adds special security context for this file, that install-recovery.sh won't be launched if the file has no proper security label - and that while installing SuperSu, the context is set in a different way and in final, install-recovery.sh isn't launched, until we restore /system context, and restoring context to the system ends with... non working su, so we have to flash it again, breaking install-recovery.sh context... Did you get it? - it's a loop as fixing one thing breaks the second, and fix to the second breaks the first That is why on my qualcomm device i have chosen another script file to run the init.d - and as you don't have any other script except install-recovery.sh, I don't know where it might be put...
BUT also I cannot guarantee that the behavior above is not qualcomm-exclusive and it is possible that on exynos device everything will work without problem!
That's why you may want to try standard method for all the devices (term init - uses install-recovery.sh method described above):
http://forum.xda-developers.com/showthread.php?t=1933849
and if it won't work then you have to wait for - at least - repacked kernel with init.d support embedded into init.rc files or run your script by an external app, ie SManager. Just be aware that even if term init work, it may stop working every time you flash SuperSu, so remember to run the script again then.
Sorry for not being too helpful.

[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..

Categories

Resources