[LB] The definitive root Remount-Reboot fix! - Xperia Z Original Android Development
As I've been working on the Stock ROM release of 10.1.1.A.1.307 some of my users started reporting that the issues I fixed for my 10.1.1.A.1.253 release started popping up again: whenever anyone with a locked bootloader tried to remount /system writable (remount,rw) it spontaneously sprung a reboot... very annoying, to say the least!
It gets even better (or worse, depends on how you look at it) when you consider any CWM version ever released for our Z/ZL models will ask us if we want it to prevent the ROM from flashing STOCK recovery... /system/etc/install-recovery.sh is the culprit here as it is what CWM disables by making it non-executable when you say YES to the question 'ROM may flash stock recovery on boot, fix?'. It actually is an important part of the rooting process we all know. It stopped the RIC service and prevented the reboots from happening. If someone said YES, the issue mentioned in the previous paragraph would also start happening and some users have even reported loss of root and even bootloops because of this...
I've set out to find a fix for it, one that eliminates the chance a regular run-of-the-mill CWM user will ever encounter the question ever again.
For all of the regular users, download one of these:
Warning for Xperia T [ALL VERSIONS] Users: There is a problem with this patch combined with the CWM package for your phones, it seems to be busybox related. @garik.007 found the solution to this issue: BusyBox by Robert Nediyakalaparambil. Install that app, update your busybox and it will fix CWM and the remount-reboot fix
WINDOWS INSTALLER: [NUT]'s definitive remount-reboot fixer!
Make sure you have USB debugging turned ON.
Download the package, save it somewhere you remember
Unzip it somewhere you remember
Run the install.bat file and choose the superuser app you are using.
Done!
The phone should do what the installer tells you it's doing, so if it says your phone will reboot, it will. If it did NOT explicitly say that it would then something went wrong!
RECOVERY FLASHABLE: [NUT]'s definitive remount-reboot fixer!
This is a flashable ZIP, install using CWM or TWRP and you're done!
It is safe to use on any STOCK (Read: NOT CM Based) ROM version released for all Xperia phones with the ric binary incorporated in the ramdisk (/sbin/ric) up to now. To see if this fix will work for your device, check if the 'ctrlaltdel' command is executed from the init.sony[anything].rc scripts. If it is, this will work!
NOTE: As this fix needs busybox to function and will install or update busybox in /system/xbin if no busybox or no busybox binary which supports the 'nohup' applet was found in /system/bin, /system/xbin or /sbin.
NOTE 2: As soon as you have installed this rootfixer and you saw it replace the already installed busybox, remove any and all busybox installer apps you have, it will probably break the rootfixer if you update busybox using that app. The version this rootfixer installs is rock solid and is used by most if not every kernel dev working on Xperia line kernels.
NOTE 3: If you have an unlocked bootloader, you can actually also install it, it won't hurt and you'll be protected from the reboots if you re-lock your phone!
XDA:DevDB Information
The definitive root Remount-Reboot fix!, Tool/Utility for the Sony Xperia Z
Contributors
[NUT]
Version Information
Status: Stable
Stable Release Date: 2013-06-25
Created 2013-06-27
Last Updated 2015-02-05
Reserved
For the ROM chefs and other devs on XDA:
I'm proud to donate the following to the dev-community on XDA, for anyone who wants to integrate it in his/her ROM or rooting tool, there is no need to ask for permissions: you can!
This hijacks the toolbox command 'ctrlaltdel' executed from init.sony-platform.rc line 13. It will take it's place in a similar way as the chargemon gets replaced to make the recoveries possible on locked bootloaders. As it is a symlink to /system/bin/toolbox there is NO need to create a copy to something else to make this work. The script that takes it's place is this:
Code:
#!/system/bin/sh
#####
#
# Completely demolish the RIC service and make sure the phone will survive a remount of /system
#
# Author: [NUT] from XDA
#
ARGS="$1 $2"
# Check busybox path and export it
if [ -x "/system/xbin/busybox" ]; then
export BUSYBOX="/system/xbin/busybox"
elif [ -x "/system/bin/busybox" ]; then
export BUSYBOX="/system/bin/busybox"
elif [ -x "/sbin/busybox" ]; then
export BUSYBOX="/sbin/busybox"
fi
# Mount rootfs rw, if it isn't already
ROOTFSMOUNTEDRO=`$BUSYBOX grep "rootfs ro,relatime" /proc/mounts | $BUSYBOX wc -l`
if [ "$ROOTFSMOUNTEDRO" = "1" ]; then
$BUSYBOX touch /tmp/remountedrootfs
$BUSYBOX mount -o remount,rw /
fi
# Edit the init.rc so the service never gets to start
$BUSYBOX sed -i '/"# Start RIC"/N;s/service ric /sbin/ric/#service ric /sbin/ric/g' /init.sony.rc
$BUSYBOX sed -i '/"#service ric /sbin/ric"/N;s/ class main/# class main/g' /init.sony.rc
$BUSYBOX sed -i '/"# class main"/N;s/ user root/# user root/g' /init.sony.rc
$BUSYBOX sed -i '/"# user root"/N;s/ group root/# group root/g' /init.sony.rc
# chmod the ric binaries so they can't start anymore, as a failsafe
if [ -x "/sbin/ric" ]; then
$BUSYBOX chmod 644 /sbin/ric
fi
if [ -x "/system/bin/ric" ]; then
$BUSYBOX chmod 644 /system/bin/ric
fi
# Make sure the RIC service gets killed if it manages to start up...
# This process will drop in the background and keeps running untill it did!
$BUSYBOX nohup /system/bin/killric.sh &
# Execute the actual command now
exec /system/bin/toolbox ctrlaltdel $ARGS
As you can see I'm spawning a process into the background to kill the RIC service. Even though I commented out the service in init.sony.rc it still manages to start up as init reads and buffers all of it's scripting before it actually starts to do anything... so the service will run regardless of the changes we make to it. This step was just for any form of runlevel change to prevent that from triggering a restart. As a secondary measure it disables the binary all the way by setting 644 permissions on it.
Code:
#!/system/bin/sh
#####
#
# Check RIC looper, it will exit as soon as it found and killed it!
#
# Author: [NUT] from XDA
#
DoesFileExist() {
if [ -f "/tmp/killedric" ]; then
return 0
else
return 1
fi
}
# As the init.rc scripts seem to be running parallel, lets kill ric if it got started.
until DoesFileExist
do
RICCHECK=`$BUSYBOX ps | $BUSYBOX grep "/sbin/ric" | $BUSYBOX wc -l`
if [ $RICCHECK -gt 1 ]; then
$BUSYBOX pkill -f /sbin/ric
fi
if [ $RICCHECK -eq 1 ]; then
$BUSYBOX touch /tmp/killedric
fi
$BUSYBOX sleep 2
done
exit 0
This does a loop every 2 seconds and tries to pkill /sbin/ric. When successful it will exit.
To double check if these 2 scripts did their job you can check /tmp for 2 empty files:
- /tmp/remountedrootfs
and
- /tmp/killedric
If they exist, checking the processlist should end up empty when trying to find killric.sh, ctrlaltdel and /sbin/ric. If so, on a locked bootloader, you can now safely remount /system and rootfs (/) and survive it
This is my gift to the community, enjoy a trouble free root experience with it!
Thanks go to:
@DooMLoRD for the chat about the init process
@RoberM for testing and suggestions, he found out pkill does successfully kill the ric process in .307
@fards for the brainstorming in my .307 ROM thread
@Carceri for the brainstorming in my .307 ROM thread
Has this fix been implemented in latest dual boot recovery for locked boatloader?
Sent from my C6603 using xda app-developers app
shoey63 said:
Has this fix been implemented in latest dual boot recovery for locked boatloader?
Sent from my C6603 using xda app-developers app
Click to expand...
Click to collapse
No, but it will
XZDualRecovery 2.4 will get this fix as well.
In the mean time you can flash this just as well
Ok
Reason I ask is this:-
I Flashed stock .434, rooted it, flashed your dual boot recovery and did an OTA update to .253.
To my amazement, update worked, plus Root and your dual recovery were still intact! Also no reboot when accessing system as R/W:good:
I will apply your patch and see what happens when OTA for .307 comes through (eventually)
My phone switches off after the Xperia wave animation.
Facts:
Locked BL
on .253
Rooted
Did not have the R/W mount issue, but I flashed it anyway
Latest CWM/TWRP recovery
I have Fidelity V4 (If that is of any consequence here)
While flashing it detected that I had busybox (If that is of any consequence as well)
Restoring system from old backup fixed it.
Great job with fixing this and making it easy for other people to use in their ROMs.
At first I thought there was a problem with this fix due to a race condition: As far as I can see rootfs is mounted r/w before ric is killed, so I would expect that sometimes ric might start early, see that / is rw and reboot the phone. I was surprised that this did not happen, but actually it seems that ric does not check permissions on rootfs (I could mount it r/w with ric running without getting a reboot).
chmod 644 /sbin/ric is (for me at least) not just a failsafe. It is needed because otherwise ric keeps being respawned whenever it's killed giving another race condition where sometimes it might have time to reboot the phone before it is killed again.
So: This fix should work as long as ric behaves as it does on the kernel that comes with 307.
As I said I also made my own version of a fix in parallel. I wrote it in C as I needed access to some system calls. Basically it is an executable that can be run from whereever one wants to start a program. It runs as a daemon that waits for /sbin/ric to be started. Once it sees ric, it forces ric and itself to run on the same CPU, schedules itself with realtime priority on that CPU so ric never gets a chance to run, replaces the ric executable in /sbin/ric by a dummy version that justs sleeps and kills the original ric process. I could also have deleted it, but whatever respawns ric now don't have to try to start a new process all the time, since it will see that ric is still running.
I have tested my own solution for the past day or so and it seems to work fine. I'll probably post the binary and source code for it later.
008bond said:
My phone switches off after the Xperia wave animation.
Facts:
Locked BL
on .253
Rooted
Did not have the R/W mount issue, but I flashed it anyway
Latest CWM/TWRP recovery
I have Fidelity V4 (If that is of any consequence here)
While flashing it detected that I had busybox (If that is of any consequence as well)
Restoring system from old backup fixed it.
Click to expand...
Click to collapse
Hmm, maybe your ROM chef built in something that conflicts with this script. His own solution to RIC maybe?
Sent from my C6603 using xda app-developers app
[NUT] said:
Hmm, maybe your ROM chef built in something that conflicts with this script. His own solution to RIC maybe?
Sent from my C6603 using xda app-developers app
Click to expand...
Click to collapse
I'm using stock. I think the issue lies with me flashing Fidelity V4.0.
EDIT: I can confirm that Fidelity patch is the issue.
008bond said:
I'm using stock. I think the issue lies with me flashing Fidelity V4.0.
EDIT: I can confirm that Fidelity patch is the issue.
Click to expand...
Click to collapse
Cr*p, I'm out of thanks to give the usual way today, so:
Thanks for the useful info, you scared me a bit there
Carceri said:
Great job with fixing this and making it easy for other people to use in their ROMs.
At first I thought there was a problem with this fix due to a race condition: As far as I can see rootfs is mounted r/w before ric is killed, so I would expect that sometimes ric might start early, see that / is rw and reboot the phone. I was surprised that this did not happen, but actually it seems that ric does not check permissions on rootfs (I could mount it r/w with ric running without getting a reboot).
chmod 644 /sbin/ric is (for me at least) not just a failsafe. It is needed because otherwise ric keeps being respawned whenever it's killed giving another race condition where sometimes it might have time to reboot the phone before it is killed again.
So: This fix should work as long as ric behaves as it does on the kernel that comes with 307.
As I said I also made my own version of a fix in parallel. I wrote it in C as I needed access to some system calls. Basically it is an executable that can be run from whereever one wants to start a program. It runs as a daemon that waits for /sbin/ric to be started. Once it sees ric, it forces ric and itself to run on the same CPU, schedules itself with realtime priority on that CPU so ric never gets a chance to run, replaces the ric executable in /sbin/ric by a dummy version that justs sleeps and kills the original ric process. I could also have deleted it, but whatever respawns ric now don't have to try to start a new process all the time, since it will see that ric is still running.
I have tested my own solution for the past day or so and it seems to work fine. I'll probably post the binary and source code for it later.
Click to expand...
Click to collapse
The way i do the remount of / is no problem in 2 ways: it only remounts when really needed and as it is indirectly executed by init, it will never cause ric to intervene and trigger a reboot. If you have the reboot issue, remounting rootfs (/) from any root explorer app actually does cause a reboot.
About your ric killer application: nice! I've never programmed in C, otherwise I might have attempted something similar. But I know bash/ash scripting, so I fixed it the way I knew best
From my perspective you could make your daemon exit once it has killed /sbin/ric after changing it's permissions to 644. I've been testing my fix for a few days now (on stock kernel and re-locked bootloader) and the method in this thread completely prevents it from starting /sbin/ric ever again :victory:
My daemon does exit once it has killed ric and made sure it cannot start again.
Whatever respawns init keeps checking, so deleting the file, making it non executable or replacing it with a dummy all works. If you chmod 755 it again, ric does respawn on my phone, so something (probably init) keeps trying to start it if it isn't running.
On my phone (before killing ric) mounting / rw does not cause a reboot, but mounting /system rw does. Weird.
Carceri said:
My daemon does exit once it has killed ric and made sure it cannot start again.
Whatever respawns init keeps checking, so deleting the file, making it non executable or replacing it with a dummy all works. If you chmod 755 it again, ric does respawn on my phone, so something (probably init) keeps trying to start it if it isn't running.
On my phone (before killing ric) mounting / rw does not cause a reboot, but mounting /system rw does. Weird.
Click to expand...
Click to collapse
That would be init indeed, as it's a service without 'oneshot' (fires only once, then init stops monitoring) or 'disabled' (init never fires it but it waits for an explicit call to get that service started).
I've found a guide on the Android init daemon/process, I'll post a link to it in this thread tonight, it's an interesting read
I never tried to restart the init process to be able to disable the service though, might be attempting to do so some day. It is what the recoveries do with the chargemon hijack method, they stop all services, unmount everything, cleans up the ramdisk and then unpacks the recovery to start it's init binary.
I'll try that some time soon and see if that will work as well, that would probably be the cleanest way, it would render killric.sh and your application useless as they would no longer be needed, simplifying and 'niceifying' the entire process.
Yep, this fix works perfectly!
Flashed stock .307, unlocked bootloader, flashed @DooMLoRD kernel then rooted through recovery, flashed root fix, flashed stock .307 kernel and then restored TA partition.
Rebooted and used Root explorer in system with R/W permissions. No reboots
Congrats @[NUT] :good:
@Carceri
[NUT] said:
I never tried to restart the init process to be able to disable the service though, might be attempting to do so some day. It is what the recoveries do with the chargemon hijack method, they stop all services, unmount everything, cleans up the ramdisk and then unpacks the recovery to start it's init binary.
I'll try that some time soon and see if that will work as well, that would probably be the cleanest way, it would render killric.sh and your application useless as they would no longer be needed, simplifying and 'niceifying' the entire process.
Click to expand...
Click to collapse
I've been experimenting with that and so far I have not been very successful... apart from not working as i hoped (it reboots after the second init attempt), it also repeats a few parts of the boot process as crtlaltdel is executed too late during the init and thus it will allow you to enter recovery twice for example :silly:
It might be needed to re-hijack the chargemon process as this is executed precisely at the right time for this idea to work... but doing so will break compatibility with all available recoveries... and throws in some caveats for the recovery users... just the thing i was trying to fix for all and any of the Z/ZL lovers
Stuff to ponder on...
*ponders on* Maybe I can use the ctrlaltdel script to 'fix' anything that breaks and then trigger a reboot to make sure the user gets to boot in to a good working android...
chargemon would be my new rickiller script, it checks for the flagfile it creates itself, if it's not found it will do the RIC fix, then create's the flagfile and restarts init. With the second init it will find the flagfile and will execute the re-hijacked chargemon hijack script to offer recovery. If not chosen to enter recovery it will just continue boot.
Once ctrlaltdel gets started it checks if the md5sum of the chargemon script is what it's supposed to be. If not, it will create a backup of that chargemon file for execution by the re-hijacked chargemon script that it copies from a backup file somewhere (probably simply in /system/bin) corrects permissions and then triggers a reboot...
PRECAUTION: This post is on the file attached, it has no meaning regarding the OP: that fix works just fine.
Well, I'm putting my scripting online that i wrote on the above idea for those in the know, I'm not sure why it does not work but
THIS DOES NOT WORK
For anyone who wants to help out, you are welcome to take a look... you can even try it (put the 2 files inside /system/bin) but note the warning above...
To recover from the tantrum it throws, be sure to have an unlocked bootloader and DooMKernel installed. You will need TWRP to get you out of trouble, which is easy: mount system, use advanced -> filemanager and look inside /system/bin. chmod chargemon and ctrlaltdel to 644. Reboot and you're out of trouble.
Who has any idea why this does not work?
well, it sadly doesn't help me.. I'm on Odexed Stock ROM .307
if I try to rename / delete / add an apk into /system/app/ my phone still reboots..
FSN said:
well, it sadly doesn't help me.. I'm on Odexed Stock ROM .307
if I try to rename / delete / add an apk into /system/app/ my phone still reboots..
Click to expand...
Click to collapse
Can you check if there is a file called killedric in /tmp?
Sent from my C6603 using xda app-developers app
[NUT] said:
Can you check if there is a file called killedric in /tmp?
Sent from my C6603 using xda app-developers app
Click to expand...
Click to collapse
I don't have this file. Locked BL, flashed w/ TWRP 2.4.0.0
FSN said:
I don't have this file. Locked BL, flashed w/ TWRP 2.4.0.0
Click to expand...
Click to collapse
Right, then check things in succession, stop and report which you stopped at:
1. Check if /system/bin/killric.sh exists.
2. Open /system/bin/ctrlaltdel to see if it looks like the one on the OP.
3. Open a terminal app and see if killric.sh is running by typing the command 'ps | grep killric.sh'
If you have to say no to 1 and 2, reflash the zip. Then try again, if it still fails send me the logs from /cache/recovery
Sent from my C6603 using xda app-developers app
[NUT] said:
Right, then check things in succession, stop and report which you stopped at:
1. Check if /system/bin/killric.sh exists.
2. Open /system/bin/ctrlaltdel to see if it looks like the one on the OP.
3. Open a terminal app and see if killric.sh is running by typing the command 'ps | grep killric.sh'
If you have to say no to 1 and 2, reflash the zip. Then try again, if it still fails send me the logs from /cache/recovery
Sent from my C6603 using xda app-developers app
Click to expand...
Click to collapse
1. Yes
2. Yes
3. If it returns 1 it runs, right?
Could it have something to do with the exFAT patch (for 64GB sd cards)?
Related
[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.
Working with su.d
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.
[Q] Does the S6 root work for Edge?
I was checking out the Root Thread for S6 and realized that my Edge's ROM version matched one on there except for the G925 vs G920. Would that root work on my Edge's similar ROM?
Never EVER try to root your phone unless it meets ALL the requirements! Mine is a SAMSUNG-SM-G925V. Unless that root is developed for a SAMSUNG-SM-G925V, you're taking a chance on bricking your phone. There are things you can do to remove bloatware and improve battery performance, which are a couple of the main reasons for installing a different ROM. I've done it myself and find battery performance has drastically improved. Do some research and you'll find what settings you can change and which apps you can either uninstall or disable. I'm happy with the snappiness and performance of this phone and find with some simple adjustments, it makes this phone even better. We will just have to be patient to see if the bootloader can be unlocked. Who knows when or if that will happen any time soon! Hope that addresses your question. Sent from my SM-G925V using XDA Free mobile app
MaverickCoast said: Never EVER try to root your phone unless it meets ALL the requirements! Mine is a SAMSUNG-SM-G925V. Unless that root is developed for a SAMSUNG-SM-G925V, you're taking a chance on bricking your phone. There are things you can do to remove bloatware and improve battery performance, which are a couple of the main reasons for installing a different ROM. I've done it myself and find battery performance has drastically improved. Do some research and you'll find what settings you can change and which apps you can either uninstall or disable. I'm happy with the snappiness and performance of this phone and find with some simple adjustments, it makes this phone even better. We will just have to be patient to see if the bootloader can be unlocked. Who knows when or if that will happen any time soon! Hope that addresses your question. Sent from my SM-G925V using XDA Free mobile app Click to expand... Click to collapse I didn't realize that was the case and went ahead installing the apk. Bad news, it didn't work. Good news, the app tells you it doesn't work for G925V yet.
mngdew said: I didn't realize that was the case and went ahead installing the apk. Bad news, it didn't work. Good news, the app tells you it doesn't work for G925V yet. Click to expand... Click to collapse iambugsy said: I was checking out the Root Thread for S6 and realized that my Edge's ROM version matched one on there except for the G925 vs G920. Would that root work on my Edge's similar ROM? Click to expand... Click to collapse There's been an update. Version 3.2 of the app works fine on current Verizon S6 Edge software. I currently am sitting on one with root.
Berzerker7 said: There's been an update. Version 3.2 of the app works fine on current Verizon S6 Edge software. I currently am sitting on one with root. Click to expand... Click to collapse That's awesome news, thanks! I'll try it out when I get home today.
Yup - just used the updated APK and it worked like a charm. Went ahead and swapped out King for SuperSU.. that too works great.
How did you swapped king for super su?
furialfil said: How did you swapped king for super su? Click to expand... Click to collapse Check out the Q&A area of the PINGPONGROOT thread.. its all listed in there. I copied/pasted from it, but it might not transfer the code exactly correct.. http://forum.xda-developers.com/galaxy-s6/general/root-pingpongroot-s6-root-tool-t3103016 Q: I'd like switching to SuperSU, what shall I do? A: Kinguser does not have a "swtich" function. Follow these steps to do so manually: (if you are not familiar with adb, see this version: http://forum.xda-developers.com/show...&postcount=269) 1. Download supersu.7z and extract it. You will get the files needed to install Supersu. 2. Using adb to push su and busybox (if not installed) to /data/local/tmp. Code: adb push su /data/local/tmp adb push busybox /data/local/tmp 3. Start a su session and run the following commands: Code: mount -o remount,rw /system cat /data/local/tmp/su >/system/xbin/daemonsu && chmod 0755 /system/xbin/daemonsu cat /data/local/tmp/busybox >/system/bin/busybox && chmod 0755 /system/bin/busybox daemonsu -d & Then keep the session running. 4. Open Kinguser, go to Settings -> Root authorization setting -> Remove Root permission. Click to remove root permission. Your su session should be still running. 5. Uninstall Kinguser app. 6. Go back to the su session and run following commands to replace su and cleanup: Code: cat /data/local/tmp/su >/system/xbin/su && chmod 0755 /system/xbin/su busybox chattr -ia /system/bin/ddexe busybox chattr -ia /system/bin/ddexe_real cat /system/bin/ddexe_real >/system/bin/ddexe busybox chattr -ia /system/xbin/ku.sud rm /system/xbin/ku.sud rm /system/xbin/pidof rm /system/xbin/supolicy 7. Install Supersu apk 8. Open Supersu apk to update files. 9. Reboot.
wait a minute so we now have root ?
XTRoRDiNAiRE said: wait a minute so we now have root ? Click to expand... Click to collapse yes
If your version matches what's in the pingpong root thread then yes. I rooted my S6E a few min ago.
Zmnypit said: If your version matches what's in the pingpong root thread then yes. I rooted my S6E a few min ago. Click to expand... Click to collapse rooted. has anyone installed TWRP? what's the best way to go about doing that? TWRP manager doesn't list verizon specific s6. I want to flash the no-deep-sleep fix
I believe you can't install a custom recovery yet as it will trip knox. Might want to go through the posts on the root thread.
Thanks. Yeah sorry it's a bit hard to follow the latest news since there are a thousand threads on all the s6/edge forums talking about the same issue. If the recovery is untouched, do we need to worry about the deep sleep problem? I've read it was caused by recovery.
[DEVS-ONLY] SuperSU developer discussion
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.
Creating /system/xbin on Android 9
Hoo roo, Am currently trying to install a custom version of BusyBox to get Linux Deploy working. The installation script is slightly buggy, but you can workaround it by changing the .sh script slightly and creating the folder /system/xbin. However, having a bit of trouble. Using su in Termux and mounting / as rw, then attempting to mkdir /system/xbin softlocks my Boox Max 3. This appears to be as a result of android 9 doing system-as-root. Using TWRP, so bootloader is unlocked, and dm-verity is disabled as well. There's also most definitely enough space on /system, can't even make the folder though. I'm following the instructions mentioned in this Github issue. To be clear, you need this custom version of busybox to get this working, it's quite strange. Am so close to getting working Arch Linux on my eink tablet, can anyone point me in the right direction? Thank you in advance