[LB] The definitive root Remount-Reboot fix!

[[NUT]]

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!

1. Make sure you have USB debugging turned ON.
2. Download the package, save it somewhere you remember
3. Unzip it somewhere you remember
4. Run the install.bat file and choose the superuser app you are using.
5. 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

 

[[NUT]]

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:

#!/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.

#!/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

 

[shoey63]

Has this fix been implemented in latest dual boot recovery for locked boatloader?

Sent from my C6603 using xda app-developers app

 

[[NUT]]

Has this fix been implemented in latest dual boot recovery for locked boatloader?

Sent from my C6603 using xda app-developers app

No, but it will

XZDualRecovery 2.4 will get this fix as well.

In the mean time you can flash this just as well

 

[shoey63]

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)

 

[008bond]

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.

 

[Carceri]

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.

 

[[NUT]]

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.

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

 

[008bond]

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

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.

 

[[NUT]]

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.

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

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.

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:

 

[Carceri]

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.

 

[[NUT]]

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.

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.

 

[shoey63]

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:

 

[[NUT]]

@Carceri

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.

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

 

[[NUT]]

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?

 

[FSN]

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

 

[[NUT]]

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

Can you check if there is a file called killedric in /tmp?

Sent from my C6603 using xda app-developers app

 

[FSN]

Can you check if there is a file called killedric in /tmp?

Sent from my C6603 using xda app-developers app

I don't have this file. Locked BL, flashed w/ TWRP 2.4.0.0

 

[[NUT]]

I don't have this file. Locked BL, flashed w/ TWRP 2.4.0.0

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

 

[FSN]

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

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)?