Related
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.
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?
After a bit of tinkering and some insight from Chainfire and imoseyon i was finally able to get SuperSU working on AOSP roms without being permissive or having to use Chainfire's prebuilt sepolicy
sepolicy patch is here: https://github.com/PureNexusProject...mmit/0f5072de4580a5db7348917e77e4c1c35d3e3c1a
Stickied.
sorry to be that guy, but how does this affect the average joe?
does it mean theres going to be a new version of supersu with this or does this mean that custom rom makers can use this patch to make there roms not need the the custom boot.img?
WarningHPB said:
sorry to be that guy, but how does this affect the average joe?
Click to expand...
Click to collapse
It doesn't, this is for ROM devs only, they know what to do with this.
Chainfire said:
It doesn't, this is for ROM devs only, they know what to do with this.
Click to expand...
Click to collapse
Welcome back! Hope you had a good break.
Chainfire said:
Stickied.
Click to expand...
Click to collapse
Thanks after including this in my AOSP builds i have noticed a few things, certain "root" app still dont function and get selinux denials. i originally had noticed this with logcat extreme. i was getting read and write denials on logd so i did an audit2allow on my sepolicy and came up with the following allow
Code:
#============= logd ==============
allow logd init:fifo_file { read write };
i did a quick google search on this and came up with https://gist.github.com/poliva/fc5b7402bde74be27518 which is apparently an sediff of your sepolicy, which is heavily modified beyond just what i had for supersu to work in enforcing for aosp roms. so i guess my real question is do us "AOSP" devs have to update our sepolicys with these 300+ additions to get all current root apps working or is this something that you can overcome in an update to SuperSU.
thanks in advance :good:
BeansTown106 said:
Thanks after including this in my AOSP builds i have noticed a few things, certain "root" app still dont function and get selinux denials. i originally had noticed this with logcat extreme. i was getting read and write denials on logd so i did an audit2allow on my sepolicy and came up with the following allow
Code:
#============= logd ==============
allow logd init:fifo_file { read write };
i did a quick google search on this and came up with https://gist.github.com/poliva/fc5b7402bde74be27518 which is apparently an sediff of your sepolicy, which is heavily modified beyond just what i had for supersu to work in enforcing for aosp roms. so i guess my real question is do us "AOSP" devs have to update our sepolicys with these 300+ additions to get all current root apps working or is this something that you can overcome in an update to SuperSU.
thanks in advance :good:
Click to expand...
Click to collapse
There is no such thing now as "all current root apps working".
If SuperSU's deamon can be launched, and it can in turn launch the supolicy tool, most of the rules from the diff will be modified by SuperSU as needed.
What your patch needs to do (and you have already done) is make sure SuperSU can be launched in the right context, and can modify the sepolicy. You do not need to implement those 300+ additions - it will be done at boot automagically.
As for those additions themselves, they are primarily needed to:
- make sure SuperSU can work, internal communications between the different processes and such
- make processes running as the "init" context (where root apps run by default) as powerful as possible
- specifically "allow" a number of things that would otherwise still work, but would be logged (everything that starts with "allow init" or "allow recovery")
Now, even with the above, still not everything works out of the box. Everything that goes from "init" to "non-init" context should already work, but going from "non-init" context to "init" may not. In your example case, we go from "logd" to "init", which isn't specifically allowed. Often apps can be fixed to work around an issue such as this.
Generally speaking, the solution is not to fix the source sepolicy or the supolicy tool, the solution is for the "logcat extreme" app to run the following at launch (as documented in How-To SU):
Code:
supolicy --live "allow logd init fifo_file { read write }"
In this specific case, maybe it could be added to supolicy, it depends on what exactly generates the audit. If it's a simple logcat command, it's a candidate for inclusion. The problem might even be solved by switching contexts rather than modifying any SELinux policies. But that is something for the app developer to figure out.
In either case, it is not something you need to fix in the AOSP patches. Those already do what they need to do.
Since they started doing SELinux Enforcing though, the policies in AOSP have generally been a tad stricter than on retail devices (this was specifically the case during 4.4 days). This may lead to you sometimes having to add/remove a rule manually somewhere that was not added to SuperSU yet. It could happen, but it's unlikely, probably temporary, and it probably should not go into this AOSP patch.
A note on pof's sediff, I'm not sure it was done cleanly, as I see some modifications in there that are not done by supolicy. Either way, such a post is informative, not leading, as supolicy may do more or less modifications depending on various runtime variables (such as Android version). Additionally, due to context names and availabilities changing between Android versions, any rule modification referencing a context not available in the to-be-patched sepolicy will not be applied, and thus will not show up in an sediff.
@BeansTown106
Have you checked by any chance if this patch is enough to allow 2.61 (systemless) to work still ?
Chainfire said:
@BeansTown106
Have you checked by any chance if this patch is enough to allow 2.61 (systemless) to work still ?
Click to expand...
Click to collapse
thanks for the description above now i understand. have never developed a root app so i had not read that part of how to su, but it makes perfect sense that the root apps would handle the denials live via your supolicy
as for system less root i have not tried that yet but i will give it a shot tonight, and report back, i know some people in my ROM thread have used system less root. but i am not sure if you had packaged your sepolicy in the install script for 2.61+ and if it is overwriting mine in the kernel, if that is the case i will modify the installation to not patch the sepolicy and see if it works with my pre compiled one based on the source above
Starting 2.64, I think this addition to init.te is all that is needed:
Code:
allow init kernel:security load_policy;
Confirmation needed though. The original patch will also work with 2.64, and the ZIP installer should default to /system installation mode.
Of course, this also requires that /system isn't verified by dm-verity, and init reloads sepolicy from the standard /data/security/current location.
the link in OP its no longer working...
Also in CM13 tree we have:
Code:
# Reload policy upon setprop selinux.reload_policy 1.
# Note: this requires the following allow rule
# allow init kernel:security load_policy;
and over my builds have no problem with SuperSU system less...
Chainfire said:
Starting 2.64, I think this addition to init.te is all that is needed:
Code:
allow init kernel:security load_policy;
Confirmation needed though. The original patch will also work with 2.64, and the ZIP installer should default to /system installation mode.
Of course, this also requires that /system isn't verified by dm-verity, and init reloads sepolicy from the standard /data/security/current location.
Click to expand...
Click to collapse
will build and test with only load policy enabled, is this for system, and systemless root?
danieldmm said:
the link in OP its no longer working...
Also in CM13 tree we have:
Code:
# Reload policy upon setprop selinux.reload_policy 1.
# Note: this requires the following allow rule
# allow init kernel:security load_policy;
and over my builds have no problem with SuperSU system less...
Click to expand...
Click to collapse
updated link, so your saying systemless supersu works with no selinux modifications?
BeansTown106 said:
updated link, so your saying systemless supersu works with no selinux modifications?
Click to expand...
Click to collapse
Over my builds yes, no issues at all in cm13, although my kernel it's in permissive mode. Maybe it's why it works all good?
Enviado do meu A0001 através de Tapatalk
danieldmm said:
Over my builds yes, no issues at all in cm13, although my kernel it's in permissive mode. Maybe it's why it works all good?
Enviado do meu A0001 através de Tapatalk
Click to expand...
Click to collapse
that is why, these patchs are to allow you to run in enforcing
I dont know if a should post here this question: there is any way to fix this problem with the rom already installed?
Thanks
Garzla said:
I dont know if a should post here this question: there is any way to fix this problem with the rom already installed?
Thanks
Click to expand...
Click to collapse
Try the following. It works for me when needed...
http://forum.xda-developers.com/showthread.php?t=3574688
Thank you for your work!
Link in OP its no longer working...
Is there any actual guide how to add SU directly to AOSP build. I have found bits and pieces but those are mainly 4.x releases.
I'm using Android M release and quite much struggling to get it working.
I have tried to make SU default on AOSP 6.0 by using this guide.
http://forum.khadas.com/t/gapps-and-su-on-soc/118/3
I'm using user build and enabled selinux permissive on that.
i have made also ro.secure=0 ro.debuggable=1 and security.perf_harden=0 (Not sure if needed)
I have also modified to change the su permissions in fs_config.c
I managed to get this work so that when flashing rom SuperSu ask for updating su binary and after that su works.
but i then cleaned work area to verify build by deleting out dir and recompiled. No go anymore.
Why it's so hard to add su by default on AOSP rom. I woud like to have it by default so i would not need to do any tricks everytime i flash new rom.
It reminds me of Korean dramas ,
THIS THREAD IS FOR DEVELOPERS ONLY. IF YOU ARE NOT A DEVELOPER (or very tech-savvy and well-versed), MOST LIKELY YOU SHOULD NOT POST HERE.
By request, I am creating this thread for developer discussion. This is the place for developers to ask questions about how to handle/implement/embed SuperSU, discuss the operation of SuperSU, suggest improvements to compatibility, etc.
This thread hopefully reduces important developer related matters from being buried in the more user-oriented threads.
Please always include the version number of SuperSU you are referring to, even if it's the latest version right now. If applicable, also include information about phone and firmware you are testing with.
Chainfire said:
The stop-gap solution is to disable this caching completely, which is what the 000000deepsleep script does, which you can find mentioned or quoted in many posts around the forum. From SuperSU 2.66 onwards, that script is automatically installed on Samsung devices when systemless root is used.
Click to expand...
Click to collapse
Please forgive me for posting (in a cf-auto-root thread) and digging afterwards. I had thought I'd just dump the info and forget about it, but I couldn't stop digging...
...which led me to the quoted material.
Digging in the supersu 2.66 update-scriptbinary, I see that you're detecting "samsung" in the build fingerprint, and if true, doing a systemless install AND applying a deepsleep fix. This works for Galaxy S6 devices, but not for some other similar platform devices. In particular, the Note5 has THREE devices that need caching disabled in order for deep sleep to function. (0:0:0:3 as well as :2 and :1.)
My first question is: does the SGS6 even have a file named "/sys/class/scsi_disk/0:0:0:3/cache_type"? If not, just write to all three files and don't worry about it. The third write would fail on the SGS6 and all would be good. It'd be no worse of a work-around than already exists (and I think it's a bad work-around.)
If that file DOES exist in the SGS6, then something would have caching turned off that really shouldn't. Of course, existing or not, automatically tossing in this deepsleep patch for every single device that has "samsung" in the build fingerprint would seem likely break proper caching in some yet unknown samsung device. Perhaps the SGS7 will change things up so that :1 should be left cache flushable, and :2 would be the only one that should block cache flushing.
As well, it's also possible that Samsung will pull in the kernel fix to resolve this issue before they release Android M. (Okay, perhaps it'd be more likely for Samsung to open source touchwiz... but we can always have fantasies.)
My problem with the work-around is expressed above: it can break something in the future (and cause a support headache when some ONE exynos7420 device is fixed, but the rest aren't.) As well, it sets precedent of having platform specific hacks in the generic update.zip (but only allowing for a single platform and not in an easily expandable way.)
Obviously, it would be a maintenance nightmare to have different "00000deepsleep" files for every different device model. (if 'zerolte.*', SGS6. If 'nobellte.*', Note5, etc.)...
In keeping with what I tell other people, I feel I now have an obligation to suggest A Better Way. (a person shouldn't complain about something unless they can make a reasonable suggestion on how it'd be better.)
So, here's my slightly convoluted (but expandable) suggestion:
You currently use /data/.supersu to read certain variables that modify the supersu.zip installer script. Perhaps those "platform specific lines" could be added to that file, and the installer script would put them in place. So, I could do the following in a recovery root shell before installing supersu.zip:
Code:
echo PLATFORMSTARTUP='echo "temporary none" > /sys/class/scsi_disk/0:0:0:1/cache_type' >> /data/.supersu
(I'd have included both (or all three) needed lines for samsung deep sleep, but I forget how to include CR in a shell cmdline.. )
Then, the supersu installer script would just read PLATFORMSTARTUP and write it's contents to /su/su.d/00000platformstartup (and set perms.)
Given this type of thing, the existing 000000deepsleep hack would be removed. Then, individual devs could easily create simplistic "pre-installers" for supersu for specific platforms that need changes. Those "pre" installers would just write the needed PLATFORMSTARTUP lines to /data/.supersu...
... and then supersu.zip no longer needs platform specific hacks.
Some random XDA developer could then generate a simple "SGS6-supersu.zip" would only contain an edify script to mount /data and add/edit the .supersu file's PLATFORMSTARTUP variable to contain the two lines needed for deep sleep (and another dev could write a Note5 for the 3 lines needed on that platform... and so on..)
Take care
Gary
garyd9 said:
You currently use /data/.supersu to read certain variables that modify the supersu.zip installer script. Perhaps those "platform specific lines" could be added to that file, and the installer script would put them in place. So, I could do the following in a recovery root shell before installing supersu.zip:
...
Click to expand...
Click to collapse
The only problem with that is that it requires users to have two brain cells to rub together. We've seen time and time again on these forums that you can't assume this is always the case.
I think that Chainfire is doing pretty much the right thing here. At worst, disabling write-back caching will make I/O a bit slower, but that's better than not having deep sleep. The only suggestion I'd have is to add more devices (maybe up to 5), and to check for their existence before writing to them.
NZgeek said:
The only problem with that is that it requires users to have two brain cells to rub together. We've seen time and time again on these forums that you can't assume this is always the case.
I think that Chainfire is doing pretty much the right thing here. At worst, disabling write-back caching will make I/O a bit slower, but that's better than not having deep sleep.
Click to expand...
Click to collapse
The problems with the existing solution are:
1. It blindly alters the system kernel behavior for every single device samsung manufactures.
2. It only actually does any good for a single one of the dozens of devices from that sam manufacturer.
3. It completely ignores every OTHER device that might need a bit of help (and potentially does more harm than good for those devices.)
4. It encourages device developers (users on XDA) to download SuperSU.zip and re-package it to have device specific hacks in the .zip archive (creating a mess.)
Actually, I don't think I need to explain all the problems with the existing hack. I'd imagine (hope) that it was done as something quick to test out an idea, and was never intended to be left in place in it's current form.
NZgeek said:
The only suggestion I'd have is to add more devices (maybe up to 5), and to check for their existence before writing to them.
Click to expand...
Click to collapse
Which 5 devices? Who maintains that list? Who updates it for each firmware change that might require an update? Will there be a new "SuperSU.zip" package each time a firmware change on a device requires that one of those 5 be changed? Who deals with the support nightmare of saying "use SuperSU v a.bc for device X firmwawre Y" and "superSU v d.ef for device X firmware Z", etc?
My proposed solution takes all the device-specific stuff completely out of the SuperSU package. It changes it from a device-specific solution to be a more generic and expandable solution that requires LESS support from SuperSU and places the device specific burden outside.
Instead of encouraging device developers to repackage supersu to device specific packages, it encourages device developers to package something else alongside supersu that would work with the existing (and unaltered) supersu.zip (and would be future compatible.)
Take care
Gary
spiral777 said:
would there be a way to get kexec/ multirom working with systemless root?
and would flashing a modified boot image to a rom also effect the kexec hardboot partch of the kernel?
Click to expand...
Click to collapse
1- the current versions of systemless root make changes/additions to the kernel, but you're not "flashing a modified boot img", so kexec is not broken, since the kernel is in essence the same as before
2- yes it is possible for systemless root (tested with 2.65) to get it working on multirom, however some changes were needed; we're still debugging the problem to try to narrow down the issue, to get it to work with as little changes as possible
EDIT: I'll just mention the problems encountered in case @Chainfire wants to be aware of them
a) line 1170: dd if=/dev/zero of=$BOOTIMAGE bs=4096
since MultiROM creates a symlink, the above command actually starts nulling out a "dummy boot.img" file, which basically continues on, untill all free space in internal storage (or external sdcard where applicable) is filled out
b) when MultiROM-TWRP finishes installing SuperSU, the fake /data is still "busy" (some open file or something else keeping it busy), since it's busy, it can't be unmounted properly, and the real mount points don't get restored
at that point mrom injection will fail
using a lazy unmount helped alleviate that (as a workaround), but obviously not the best solution
c) the setprop sukernel.mount 1 (in launch_daemonsu.sh) doesn't trigger the mount properly, workaround was to mount it in the launch_daemonsu.sh using "mount -t ext4 -o loop /data/su.img /su" instead of the setprop
EDIT2: thanks @Captain_Throwback for the reminder
d) the attempted remount read-only, will cause a bootloop; workaround: had to comment that out
just FYI, but I'll check more thoroughly when I get a chance
@garyd9 @NZgeek
Some good points are raised. I am not going to go into them all individually.
There is one core point of disagreement though. While I do not think device-specific patches generally have a place in the SuperSU ZIP installer, the deep sleep issue affects so many million users it is too big to ignore. (By the way, as far as I know this issue affects all recent high-end Samsungs).
While I don't disagree with your ideal of custom pre/post installers, in reality most users will never discover the issue, and just blame SuperSU for suddenly bad battery life. This leads to many support emails, thread posts, bad rep, etc.
Contrast this to for example the LG G3 compatibility patch, which requires the user to indeed write a file to /data or use a pre-installer that does that, the device will simply not boot, which forces the user to either go back to stock, or search for and discover the fix.
Either way, you are right, the patch doesn't even work right for Note users. Thank you for pointing that out - nobody else ever did. I have come up with the following improved script. If for the moment, we put aside our differences regarding the inclusion of any device-specific fixes, what do you think of the following?
It will perform the cache_type change for any scsi_disk, but will skip the ones not set to write protected. This should catch the problem with devices that have a different disk layout, and prevent accidental reduced I/O speed for devices that are not affected.
Note that it is my understanding that the write protection mode cannot be reset without a flash chip power cycle, and as the protection is set by the bootloader long before our check, checking once at boot should suffice.
I would be grateful if you gave that a shot on an affected Note/Edge+ and report back. It successfully sets the cache_type for :1 and :2 on my S6.
Code:
for i in `ls /sys/class/scsi_disk/`; do
cat /sys/class/scsi_disk/$i/write_protect 2>/dev/null | grep 1 >/dev/null
if [ $? -eq 0 ]; then
echo 'temporary none' > /sys/class/scsi_disk/$i/cache_type
fi
done
Chainfire said:
I would be grateful if you gave that a shot on an affected Note/Edge+ and report back. It successfully sets the cache_type for :1 and :2 on my S6.
Click to expand...
Click to collapse
I won't be able to properly test this until at least tomorrow (Wed) evening... However, in the meantime, the following screenshots suggest that it'd also work on the Note5:
https://goo.gl/photos/61JWzoA5ir3PcDNr9
(This is with a custom kernel, however. I'll post a query in the Note 5 section asking people who are running a stock kernel to run similar commands to post the output here: http://forum.xda-developers.com/showpost.php?p=64773152&postcount=138 - I'll relay the results.)
Let me know when you'd like to debate on if SuperSU should fix (non-root related) bugs in only specific devices, all devices, no devices, or if it should just support a hook to allow third parties to fix both current and future/past devices. (Please don't get the wrong impression from that statement. SuperSU is your product, not mine... However you implement things is up to you.)
Please do let me know if I can be of further assistance to fix compatibility.
nkk71 said:
a) line 1170: dd if=/dev/zero of=$BOOTIMAGE bs=4096
since MultiROM creates a symlink, the above command actually starts nulling out a "dummy boot.img" file, which basically continues on, untill all free space in internal storage (or external sdcard where applicable) is filled out
Click to expand...
Click to collapse
I guess the script can be modified to detect a link and then check if said link is still pointing to /dev/...
Do double symlinks need to be taking into account? i.e. what is a symlink, /dev/block/platform/.../boot, /dev/block/mmcblk0pX, both?
b) when MultiROM-TWRP finishes installing SuperSU, the fake /data is still "busy" (some open file or something else keeping it busy), since it's busy, it can't be unmounted properly, and the real mount points don't get restored
at that point mrom injection will fail
using a lazy unmount helped alleviate that (as a workaround), but obviously not the best solution
Click to expand...
Click to collapse
Complete guesswork, but the backing file may need to be released for the loop device.
c) the setprop sukernel.mount 1 (in launch_daemonsu.sh) doesn't trigger the mount properly, workaround was to mount it in the launch_daemonsu.sh using "mount -t ext4 -o loop /data/su.img /su" instead of the setprop
Click to expand...
Click to collapse
Any idea why?
I'm specifically using the setprop / init.rc way because mount -o loop doesn't work on many firmwares.
d) the attempted remount read-only, will cause a bootloop; workaround: had to comment that out
Click to expand...
Click to collapse
Where is this?
Chainfire said:
Please do let me know if I can be of further assistance to fix compatibility.
Click to expand...
Click to collapse
Thank you, I will let you know once I've had a chance to properly debug further
I initially only wanted to get systemless root to work, which using the workarounds (even though not ideal), was proof it can be done
(at the time it was SuperSU v2.65)
Chainfire said:
I guess the script can be modified to detect a link and then check if said link is still pointing to /dev/...
Do double symlinks need to be taking into account? i.e. what is a symlink, /dev/block/platform/.../boot, /dev/block/mmcblk0pX, both?
Click to expand...
Click to collapse
No need to take double symlinks into account, only the real one is changed as follows:
the real one is renamed with a "-orig" extension, and a symlink is created to an imaginary normal file:
Code:
cd [B][COLOR="Blue"]/dev/block[/COLOR][/B]
ls -l
...
brw------- 1 root root 259, 24 Jan 12 18:18 mmcblk0p40
brw------- 1 root root 259, 25 Jan 12 18:18 mmcblk0p41
[B]lrwxrwxrwx 1 root root 67 Jan 12 18:19 mmcblk0p42 -> /realdata/media/0/multirom/roms/HTC_One_M8_GPe_Marshmallo1/boot.img[/B]
[B]brw------- 1 root root 259, 26 Jan 12 18:18 mmcblk0p42-orig[/B]
brw------- 1 root root 259, 27 Jan 12 18:18 mmcblk0p43
...
all other symlinks to the block device remain as is:
Code:
cd[B][COLOR="Blue"] /dev/block/platform/msm_sdcc.1/by-name[/COLOR][/B]
ls -l
...
lrwxrwxrwx 1 root root 21 Jan 12 18:18 adsp -> /dev/block/mmcblk0p16
lrwxrwxrwx 1 root root 20 Jan 12 18:18 board_info -> /dev/block/mmcblk0p3
[B]lrwxrwxrwx 1 root root 21 Jan 12 18:18 boot -> /dev/block/mmcblk0p42[/B]
lrwxrwxrwx 1 root root 21 Jan 12 18:18 cache -> /dev/block/mmcblk0p46
...
Chainfire said:
Complete guesswork, but the backing file may need to be released for the loop device.
Click to expand...
Click to collapse
Will check, thanks.
Chainfire said:
Any idea why?
I'm specifically using the setprop / init.rc way because mount -o loop doesn't work on many firmwares.
Click to expand...
Click to collapse
Not really, everything else in init.rc get's executed properly; (and obviously the in launch_daemonsu.sh as well)
Chainfire said:
Where is this?
Click to expand...
Click to collapse
at the beginning of launch_daemonsu.sh:
Code:
if [ ! -d "/su/bin" ]; then
# if we fstab'd system/vendor/oem to rw, remount them ro here
remount_ro /system
remount_ro /vendor
remount_ro /oem
^^ I commented all three of them out, which worked out fine.
MultiROM's secondary ROMs always have system mounted rw, and the above remount_ro will force an immediate reboot
I need to do further testing on these issues, as soon as I come up with something more concrete, I will report back.
EDIT: forgot to mention, can confirm this for the HTC One M7, M8 and M9
garyd9 said:
I'll post a query in the Note 5 section asking people who are running a stock kernel to run similar commands to post the output here: http://forum.xda-developers.com/showpost.php?p=64773152&postcount=138 - I'll relay the results.)
Click to expand...
Click to collapse
So, two replies. I've edited the results to just show the device and value of write_protect. The first one is a KNOX tripped device with completely stock firmware/kernel (no root):
Code:
scsi_disk/0:0:0:0 0
scsi_disk/0:0:0:1 1
scsi_disk/0:0:0:2 1
scsi_disk/0:0:0:3 1
The second is from a stock device where KNOX has never been tripped (the results are expected, but nice for confirmation):
Code:
scsi_disk/0:0:0:0 0
scsi_disk/0:0:0:1 0
scsi_disk/0:0:0:2 0
scsi_disk/0:0:0:3 0
So far, all indications are that the change suggested would work.
Can I have your permission to modify the superSU 2.66 archive to change the deepsleep script to use the script above and forward it to a couple people to validate? (Or, I can just wait until tomorrow night and do it on my own device.)
garyd9 said:
So far, all indications are that the change suggested would work.
Can I have your permission to modify the superSU 2.66 archive to change the deepsleep script to use the script above and forward it to a couple people to validate? (Or, I can just wait until tomorrow night and do it on my own device.)
Click to expand...
Click to collapse
Knock yourself out. I'm not in a rush though. I don't expect to release another update for another few days at least.
Chainfire said:
Code:
for i in `ls /sys/class/scsi_disk/`; do
cat /sys/class/scsi_disk/$i/write_protect 2>/dev/null | grep 1 >/dev/null
if [ $? -eq 0 ]; then
echo 'temporary none' > /sys/class/scsi_disk/$i/cache_type
fi
done
Click to expand...
Click to collapse
Confirmed working for all cache_types 1,2 and 3 but sorry I have patched kernel myself to fix so I have tested reverse just to prevent kernel swap.
Code:
echo 'write back' > /sys/class/scsi_disk/$i/cache_type
and it was write back for all 3. Indeed four including cache_type 0.0.0.0 as well)
So if i had test with
Code:
echo 'temporary none' > /sys/class/scsi_disk/$i/cache_type
then 0000 also get cached right?
It shouldn't be problem right? Just references to this post last line.
Regards
dr.ketan said:
Confirmed working for all cache_types 1,2 and 3 but sorry I have patched kernel myself to fix so I have tested reverse just to prevent kernel swap.
Code:
echo 'write back' > /sys/class/scsi_disk/$i/cache_type
and it was write back for all 3. Indeed four including cache_type 0.0.0.0 as well)
So if i had test with
Code:
echo 'temporary none' > /sys/class/scsi_disk/$i/cache_type
then 0000 also get cached right?
It shouldn't be problem right? Just references to this post last line.
Regards
Click to expand...
Click to collapse
I don't know, since you changed it up, and your statement is a bit confusing.
Try this:
Code:
for i in `ls /sys/class/scsi_disk/`; do
cat /sys/class/scsi_disk/$i/write_protect 2>/dev/null | grep 1 >/dev/null
if [ $? -eq 0 ]; then
echo Write protected: $i
else
echo Write enabled: $i
fi
done
Copy/paste the output.
No problem. I will go to office in couple of hrs. Remove deep sleep fix from kernel and then test script as per said.
dr.ketan said:
No problem. I will go to office in couple of hrs. Remove deep sleep fix from kernel and then test script as per said.
Click to expand...
Click to collapse
That's not needed, just run the other script I pasted above. It'll show what we need to know regardless of your kernel being patched or not.
[email protected]lelte:/ $ su
[email protected]:/ # ls -l /sys/class/scsi_disk/
lrwxrwxrwx root root 2016-01-13 15:35 0:0:0:0 -> ../../devices/15570000.ufs/host0/target0:0:0/0:0:0:0/scsi_disk/0:0:0:0lrwxrwxrwx root root 2016-01-13 15:35 0:0:0:1 -> ../../devices/15570000.ufs/host0/target0:0:0/0:0:0:1/scsi_disk/0:0:0:1lrwxrwxrwx root root 2016-01-13 15:35 0:0:0:2 -> ../../devices/15570000.ufs/host0/target0:0:0/0:0:0:2/scsi_disk/0:0:0:2lrwxrwxrwx root root 2016-01-13 15:35 0:0:0:3 -> ../../devices/15570000.ufs/host0/target0:0:0/0:0:0:3/scsi_disk/0:0:0:[email protected]:/ # cat /sys/class/scsi_disk/*/write_protect
0
1
1
1
[email protected]:/ #
dr.ketan said:
...
Click to expand...
Click to collapse
Seems fine!
I had some time to check a few things, so please find below my findings / possibly solutions
Chainfire said:
a) line 1170: dd if=/dev/zero of=$BOOTIMAGE bs=4096
since MultiROM creates a symlink, the above command actually starts nulling out a "dummy boot.img" file, which basically continues on, untill all free space in internal storage (or external sdcard where applicable) is filled out
Click to expand...
Click to collapse
I guess the script can be modified to detect a link and then check if said link is still pointing to /dev/...
Do double symlinks need to be taking into account? i.e. what is a symlink, /dev/block/platform/.../boot, /dev/block/mmcblk0pX, both?
Click to expand...
Click to collapse
Fixed it by using the following code (perhaps the readlink -f is redundant, but it worked fine)
(at line 1199 of SuperSU 2.66 updater-binary):
Code:
if [ -b `readlink -f $BOOTIMAGE` ]; then
dd if=/dev/zero of=$BOOTIMAGE bs=4096
fi
Chainfire said:
b) when MultiROM-TWRP finishes installing SuperSU, the fake /data is still "busy" (some open file or something else keeping it busy), since it's busy, it can't be unmounted properly, and the real mount points don't get restored
at that point mrom injection will fail
using a lazy unmount helped alleviate that (as a workaround), but obviously not the best solution
Click to expand...
Click to collapse
Complete guesswork, but the backing file may need to be released for the loop device.
Click to expand...
Click to collapse
Turns out the loop device was in fact the problem; after umount /su, it still showed:
Code:
~ # [6n[B]losetup -a[/B]
losetup -a
/dev/block/loop0: 0 /data/su.img
so I just used/added (at line 1218 of SuperSU 2.66 updater-binary)
Code:
umount /su
[B]losetup -d /dev/block/loop0[/B]
I know it was on loop0 so I didnt need to account for anything else, but maybe using
Code:
LOOPDEVICE=`losetup -f`
or something similar, and continuing from there could be an option
Haven't tried checking on the other issues, but will report back when I have something on those
@Chainfire, early results on the deep sleep script change are 100% positive for both the Note5 and the edge+ devices.
nkk71 said:
I had some time to check a few things, so please find below my findings / possibly solutions
Click to expand...
Click to collapse
Thanks for the update. I'll have a look at those commands. losetup -f is specifically not used because I have already encountered devices/recoveries where the built-in losetup does not support this flag. So just loop0 and loop1 are tried, on failure, too bad (guess that could use improvement, hehe). The same goes for the -b test for if, and the -f flag for readlink. While I have not specifically tested the block device test, I know the symlink test fails on some devices. So I need to do some testing.
This is why some things in the ZIP are done is such weird ways instead of just using standard command, they're all work-arounds for encounted recovery versions that didn't support command X or flag Y ...
garyd9 said:
@Chainfire, early results on the deep sleep script change are 100% positive for both the Note5 and the edge+ devices.
Click to expand...
Click to collapse
Good news, as expected.