Related
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)?
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've spent the past couple of hours trying to get various tools (busybox, supersu, xposed, etc) installed in the microsoft android emulator, including SuperSu, and all I've managed so far is busybox (all I had to do was copy it over and rename it). The microsoft android "emulator" is a hyper-v virtual machine with an x86-based android installed in it. You can get root simply by running
Code:
su
and/or
Code:
adb shell
. Unfortunately, it doesn't have a recovery. It has a simple script to install binaries by running install_zip.sh, but this doesn't seem to be calling updater-binary at all, and I'm not sure how to fake my way around that. Is there any chance of getting a flashable zip file (or a command to manually run the updater-binary script) for installing SuperSu in such an environment? A large number of root apps expect a su daemon like SuperSu and will not work without it, even if the su binary doesn't require it.
Follow this guide to flash SuperSU on the latest version of android wear for your watch, it should have the same OS compatibility as normal SuperSU and should work all the way upto android 7.1.1
(from PC)
1.Unlock the bootloader if not already unlocked
(Make sure to set up device with phone after unlocking bootloader otherwise no boot!)
Code:
adb reboot bootloader
fastboot oem unlock
2.flash TWRP for your device (REQUIRES read only access to system!, will post working builds in post below)
Code:
fastboot flash recovery recoveryname.img
3.Download SuperSU with busybox YDS included HERE and move it to watch with adb push to /sdcard while TWRP is booted and then install as normal zip
Code:
adb push nameofzip.zip /sdcard/
4.IGNORE SYSTEM NOT INSTALLED Boot watch to system and Now your root apps from 5.1 should work perfect. THERE WILL BE NO SUPER SU APP, IT HAS NOT BEEN PORTED TO ANDROID WEAR
REMEMBER squashfs is read only even with root so don't bother trying to modify system files like the build.prop.
If you would like to modify system use any Linux distro and unsquash the system then resquash it (will make guide if enough interest)
If you would like to change pixel density perform this command in either adb shell or a terminal emulator:
Code:
wm density <dpi>
Please leave thanks if it helped!
Feel free to submit links to twrp for squashfs watch with model name, codename and original developer's name
Will add them to this post
THESE ARE THE ONLY BUILDS THAT WILL WORK UNTIL TWRP IS UPDATED!
I DID NOT CREATE ANY OF THESE BUILDS!
LG G Watch dory (courtesy of @rbox)
LG G watch R lenok
In regards to Busybox on Rails, I compared the link provided and Google Play (which I assume is latest), they are the same versions. Is there a trustworthy place to find the old version suggested?
Not sure if I will need it, just covering my bases. Upgrading to 6.0.1 tonight.
Thanks.
First post and Thanks to you!!!
This is my first post in the community, i thank you all for all you do! I have successfully rooted lg g watch with android 6.0.1 build mec23d using your method. busy box pro installed after uninstalling superuser.
OfficerJimLahey said:
In regards to Busybox on Rails, I compared the link provided and Google Play (which I assume is latest), they are the same versions. Is there a trustworthy place to find the old version suggested?
Not sure if I will need it, just covering my bases. Upgrading to 6.0.1 tonight.
Thanks.
Click to expand...
Click to collapse
Oh I thought it was an older version will edit that as the latest did not work On 5.1.1 wear but I guess it those on 6.0.1
itsthamessenger said:
This is my first post in the community, i thank you all for all you do! I have successfully rooted lg g watch with android 6.0.1 build mec23d using your method. busy box pro installed after uninstalling superuser.
Click to expand...
Click to collapse
Glad I could help! I was not aware the busybox pro worked on wear is it the one by stericson?
Xmaster24 said:
Glad I could help! I was not aware the busybox pro worked on wear is it the one by stericson?
Click to expand...
Click to collapse
Yes it is!
itsthamessenger said:
Yes it is!
Click to expand...
Click to collapse
Thanks for the info will add to post
Unless I am missing something, system access is needed for the LG G Watch.
Tried with TWRP 3.0.0 and 2.8.7, SuperSU 2.65 flash was successful in spite of /system not mounting (notice was given in red letters), rebooted, with same result across both versions:
Code:
[email protected]:~$ Build/android-sdk-linux/platform-tools/adb uninstall eu.chainfire.supersu
Failure [DELETE_FAILED_INTERNAL_ERROR]
[email protected]:~$ Build/android-sdk-linux/platform-tools/adb install Downloads/BusyBox%20On%20Rails_5.1.74_apk-dl.com.apk
1087 KB/s (2287614 bytes in 2.053s)
pkg: /data/local/tmp/BusyBox%20On%20Rails_5.1.74_apk-dl.com.apk
Success
[email protected]:~$ Build/android-sdk-linux/platform-tools/adb shell
[email protected]:/ $ su
/system/bin/sh: su: not found
127|[email protected]:/ $
Looks like SuperSU is not even bothering with system-less mode:
http://pastebin.com/T7k0cWHv
OfficerJimLahey said:
Unless I am missing something, system access is needed for the LG G Watch.
Tried with TWRP 3.0.0 and 2.8.7, SuperSU 2.65 flash was successful in spite of /system not mounting (notice was given in red letters), rebooted, with same result across both versions:
Click to expand...
Click to collapse
Huh I used a modified version of the latest TWRP from a member that allowed the system to be mounted read only as squashfs is a read only file system ie. The system image has to be rebuilt to make changes. I assumed that since supersu is now system less it those not require system access but maybe it those but I really didn't see the use of mounting it read only as it cannot make any changes to system. Will edit thread thanks for info. Link to squashfs twrp above
It is strange though the other poster managed to root without system access.
Xmaster24 said:
Huh I used a modified version of the latest TWRP from a member that allowed the system to be mounted read only as squashfs is a read only file system ie. The system image has to be rebuilt to make changes. I assumed that since supersu is now system less it those not require system access but maybe it those but I really didn't see the use of mounting it read only as it cannot make any changes to system. Will edit thread thanks for info.
Click to expand...
Click to collapse
The third time I flashed to get the log, I attempted to mount /system as read only, since it didn't mount properly otherwise. The onscreen messages looked the same anyway...successful flash, but could not mount /system. And upon leaving TWRP, it warned that no OS was installed. Nothing different for all intents and purposes.
Thanks, I will try your TWRP and report back.
UPDATE:
Your TWRP made all the difference:
Code:
[email protected]:~$ Build/android-sdk-linux/platform-tools/adb uninstall eu.chainfire.supersu
Success
[email protected]:~$ Build/android-sdk-linux/platform-tools/adb shell
[email protected]:/ $ su
[email protected]:/ #
Thank you!
OfficerJimLahey said:
The third time I flashed to get the log, I attempted to mount /system as read only, since it didn't mount properly otherwise. The onscreen messages looked the same anyway...successful flash, but could not mount /system. And upon leaving TWRP, it warned that no OS was installed. Nothing different for all intents and purposes.
Thanks, I will try your TWRP and report back.
UPDATE:
Your TWRP made all the difference:
Thank you!
Click to expand...
Click to collapse
No problem guess SuperSU those require system access to work it seems to be for SE Linux patching and also the build.prop
Xmaster24 said:
<snip>
4.Boot to system and open Busybox on rails app and install busybox
<snip>
Click to expand...
Click to collapse
Thanks for this guide! Rooted AOK :good:
This Step 4 is to install Busybox on Rails onto the phone? or Watch?
drewski_1 said:
Thanks for this guide! Rooted AOK :good:
This Step 4 is to install Busybox on Rails onto the phone? or Watch?
Click to expand...
Click to collapse
Welcome and watch the whole process only requires pc and watch no phone involved. My modified supersu installer should have installed busybox on Rails app to the watch
Xmaster24 said:
Welcome and watch the whole process only requires pc and watch no phone involved. My modified supersu installer should have installed busybox on Rails app to the watch
Click to expand...
Click to collapse
got it. thanks again!!
Highly recommend everyone to get invisiblek's kernel its top notch gets rid of the horrible lag of 6.0.1's kernel And is fully supported by my root method so even better!
Sent from my GT-S5830i using XDA Free mobile app
Where do supersu and busybox get installed
Xmaster24 said:
Welcome and watch the whole process only requires pc and watch no phone involved. My modified supersu installer should have installed busybox on Rails app to the watch
Click to expand...
Click to collapse
Since the new wear has a read only system, where do the supersu and busybox get installed?
ganovim said:
Since the new wear has a read only system, where do the supersu and busybox get installed?
Click to expand...
Click to collapse
SuperSU is now system less if you haven't been following it recently so system access is not required also bits of supersu are stored in the kernel disk and others just at /data. Busybox is stored with the SU mounted image to /su/xbin once installed via the app
/moved to specific lg g watch thread
Hi, Forgive me as I've been off the android scene for a while, at least to the point I have had to keep up with developments.
I want to replace /etc/hosts on my device to save using a vpn, etc. to block ads. On my Nexus 6P this was easy, remount rw, replace, or adfreezip.
On my S10 this is not so easy. I am unable to remount system as rw, I presume as this is 'systemless', I am also unable to remount the entire filesystem '/' as rw.
Does anyone know how I achieve this or how I replace a hosts file?
I am rooted with magisk but not with TWRP (I did flash TWRP before but could not install zips to the filesystem from twrp so just did not bother this time).
Comedy- said:
Hi, Forgive me as I've been off the android scene for a while, at least to the point I have had to keep up with developments.
I want to replace /etc/hosts on my device to save using a vpn, etc. to block ads. On my Nexus 6P this was easy, remount rw, replace, or adfreezip.
On my S10 this is not so easy. I am unable to remount system as rw, I presume as this is 'systemless', I am also unable to remount the entire filesystem '/' as rw.
Does anyone know how I achieve this or how I replace a hosts file?
I am rooted with magisk but not with TWRP (I did flash TWRP before but could not install zips to the filesystem from twrp so just did not bother this time).
Click to expand...
Click to collapse
AdAway works if you want a much easier solution.
Joe333x said:
AdAway works if you want a much easier solution.
Click to expand...
Click to collapse
Thanks. I actually realised though that Magisk has an option to generate a systemless hosts file so I've turned that on and it has done what I need.
I run a pihole at home that has a script which generates a standard hosts file from the blocklist. I can just on occasion save it to /sdcard/ and then cat /sdcard/hosts > /etc/hosts
When I get around to it I will probably just add this as a cron job