Related
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
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.
Hi @Chainfire,
So, a while ago, I posted in the Liveboot thread inquiring as to how I'd go about incorporating liveboot into a ROM so that it could just run on first boot.
Your instructions were to chmod 0770 both the files and folders in su.d, and it should work:
If /system/su.d/0000liveboot.script exists (chmod 0644, not 0700 like other files in /system/su.d/ !), this script will be run instead of logcat and dmesg, and its output will be shown in white (stdout) and red (stderr).
Click to expand...
Click to collapse
However, I tried this, and never got it to work, and essentially moved on to other stuff for a while.
Today, I tried to revisit it, and while I was at it, replace my current init.d stuff with su.d.
So, I created the folder in /system which gets copied with t he rest of the ROM on install. I'm setting folder and file permissions to 0700, owner and group to root, SE context to ubject_r:system_file:s0, which, is exactly the same as what I'm seeing on 0000liveboot when I look at it's info.
This leaves two questions.
One, the above quote you say to set it to 0644, but liveboot itself sets it to 0700 when it installs it.
Two, what is the trick to getting other scripts to work? In your "How to SU" guide, you mention this:
From versions 2.22 onwards, after the policies have been patched and the daemon is ready to go, all executables in the /system/su.d/ directory are executed (chmod 0700 both the directoy and the scripts), followed by setprop supolicy.loaded 1. This is akin to /system/(etc/)init.d/, though execution of those scripts is both kernel-dependent and they may run before the SELinux are patches and/or su is available.
Click to expand...
Click to collapse
Setprop supolicy.loaded. Where am I supposed to do that? You say execution of those scripts is kernel-dependent - you're referring to init.d, yes? So, again, what am I missing?
This is 5.0.1 GPE for M8VZW. I have selinux set to permissive via boot image in init.rc, and verify that "getenforce" returns "permissive" from shell.
Any help you could lend would be greatly appreciated - which is also why I'm posting this as a thread...because su.d sounds like an awesome idea, and I bet more devs would like to start using this method over init.d.
Thank!
digitalhigh said:
One, the above quote you say to set it to 0644, but liveboot itself sets it to 0700 when it installs it.
Click to expand...
Click to collapse
liveboot sets the script that gets run by SuperSU to 0700. The script which I said to be set 0644 is a different script, and is not executed by SuperSU, but by liveboot.
Setprop supolicy.loaded. Where am I supposed to do that?
Click to expand...
Click to collapse
You don't. SuperSU sets this. Kernel developers can hook this event to run their own code.
You say execution of those scripts is kernel-dependent - you're referring to init.d, yes?
Click to expand...
Click to collapse
Yes, not all kernels support init.d, and init.d stuff generally runs before SuperSU patches policies, so there's no guarantees about any SELinux state.
So, again, what am I missing?
Click to expand...
Click to collapse
I don't know. Make sure you are running the latest version of SuperSU (2.46 at the time of writing). Make sure /system/su.d is chmod 0700. Make sure the scripts you want to run are also chmod 0700 and #!'d to a working shell executable. Keep in mind that the scripts are called one-by-one, in a blocking way. So if a script never exits, the next script isn't run.
Deleted
Say I have SU v2.62. I have 2 files in my /system/su.d folder. The first file doesn't have an exit, neither does the second. The second file DOES get executed as it sets selinux to permissive at boot as directed. First file is 0700 (text file), second is 0755 (a .sh file).
Now, I want to take an init.d setprop script and try it via su.d.
1) Do the other files need exit commands?
2) What should the third file (setprop file) be set to, 0755? A .sh or text file?
3) Are the other two set to the correct chmod?
Thank you for any input!
EDIT: Left it as text, and 0755. No exits, and it worked?
Using su.d to disable doze
Is it possible to use su.d in order to load a script that disables Android doze mode?
I'm trying to run this script:
Code:
#!/system/bin/sh
dumpsys deviceidle disable
Script file is located in root\su\su.d
Permissions are set to 0700.
However, script is not loaded automatically during the boot, because if I run the script manually in SManager I get a response Idle mode disabled, which means su.d script wasn't loaded.
Currenlty I use SManager to execute this doze disabling script automatically on every boot, but I wonder why wouldn't the same script work using su.d?
I use another su.d script that disables LED back-lights of hardware navigation buttons and the script works just fine.
I'm using SuperSU v2.82
Thanks for your input.
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..
Hello dear Chainfire and community!
I have a rather obscure issue: I want to run a root script at very early init.
The script (predictably) runs afoul of Selinux policy (who'd have thought) and since it's a chinese phone no sources are available.
Good things:
I can unpack/repack boot.img without issue, and can add/start services from .rc
Phone is rootable and after proper boot, SuperSu works fine (and so does setenforce 0)
Bad things:
This is lolipop 5.0 so install-recovery.sh and anything else of that general kind is not available
Source (and thus opportunity to change sepolicy) not available
SuperSu daemon's normal start is waaaaay too late for what I'm trying to do.
Question:
Given that I can add my own service and run it as I please, is there a way to "kickstart" su functionality early-on (so I can set Selinux to permissive and run my stuff), without breaking functioning of supersu after boot completes?