Database Develop

D4 Utility and ICS..........??

I used the D4 utility to root my Motorola Droid 4 running, at the time, GB. I then DL'd Titaninum Backup and Voodoo root keeper. I have recently gotten the OTA ICS and believe I preserved my root with voodoo. I did have some issues that root keeper seemed to resolve. My question is; do I need to factory reset and reroot with a different utility or am I good? The only issues I seem to have now is 1. My wallpaper seems to "zoom" in going from landscape view to normal portrait view 2. 4g/3g freezing and not opening websites without backing out and/or rebooting 3. My sound is sometimes off when going from muted to any volume (seems only with videos and or streaming music ie: youtube, iheart, etc)

A lot of people experience issues when upgrading to ICS. While the update is supposed to bring you to 4.x from 2.x as seamlessly as possible, the reality is there will always be issues.
Do a factory reset to give your ICS a "fresh" start and you'll find it should run much more smoothly. If you kept root via RootKeeper you should be good, but you can always re-root using the 4.0.4 root tool found here:
http://forum.xda-developers.com/showthread.php?t=1707214
Sent from my DROID4 using Tapatalk 2

DISCLAIMER: I have no clue so everything below is speculation. Hopefully I don't make someone's informed answer more difficult...
When you root you're going to get a su binary (or did I install Superuser?).
Voodoo OTA Rootkeeper lets you backup/protect the root (binary). Then you can temp un-root and subsequently restore root.
Before going to ICS one should:
- in Voodoo OTA RootKeeper: Delete su backup (delete the backed up su binary)
- in Superuser: check for updates and update to latest binary (updates su to the latest binary)
- in Voodoo OTA RootKeeper: Protect root (saves the updated su binary)
- in Voodoo OTA RootKeeper: temp un-root and then restore root (refreshes loaded/running copy to current binary?)
Since it worked for you after the upgrade I'm guessing you already had the latest su binary. and you don't need to do anything further with respect to root?
There are 2 versions of the D4 utility. One for GB and one for ICS. You want to be using the ICS one now
Apparently you did not have safestrap installed before the update to ICS.
My understanding for safestrap is that you have to completely uninstall it first or the update fails.
- in safestrap: uninstall recovery
- in Settings->Applications->Manage Applicaions: uninstall safestrap
- in a file explorer with root capabilities: delete /system/bin/logwrapper
- in a file explorer with root capabilities: rename /system/bin/logwrapper.bin -> /system/bin/logwrapper
...not real clear on that last one. I gather that installing or using safestrap moves logwrapper to logwrapper.bin and uses a modified logwrapper in it's place? So you need to restore the original one? Maybe because otherwise the updater's check for system files fails?
[Sorry about sort of hijacking your thread to verify my understanding of this but I'm getting ready to make the leap myself and it appears I have a similar setup to yours]

You don't really have to worry about updating the su binary as long as there is a back-up in voodoo. The ICS only utility should re-root without any trouble if you lost it in the update. You can also use RSD Lite and the ICS fastboot file to start over fresh if you like.

The Magician Type 0 said:
A lot of people experience issues when upgrading to ICS. While the update is supposed to bring you to 4.x from 2.x as seamlessly as possible, the reality is there will always be issues.
Do a factory reset to give your ICS a "fresh" start and you'll find it should run much more smoothly. If you kept root via RootKeeper you should be good, but you can always re-root using the 4.0.4 root tool found here:
http://forum.xda-developers.com/showthread.php?t=1707214
Sent from my DROID4 using Tapatalk 2
Click to expand...
Click to collapse
Sorry for my ignorance, but when I do a factory reset I will lose everything correct and will have to dl my apps and root again? or should I 1.unroot, 2.factory reset, 3.then root again?

You shouldn't loose root and will not lose superuser if it was installed as a system app. You will have reinstall any app you downloaded from the market or sideloaded. Otherwise your phone will be like the day you got it, without any user data.

jsnweitzel said:
You don't really have to worry about updating the su binary as long as there is a back-up in voodoo. The ICS only utility should re-root without any trouble if you lost it in the update. You can also use RSD Lite and the ICS fastboot file to start over fresh if you like.
Click to expand...
Click to collapse
If I were to root my droid with ICS only tool, will I be able to unroot and go to stock if needed, ie: warranty, etc.

[LB] The definitive root Remount-Reboot fix!

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

WIFI Suddently disabled after reboot

Hi all,
I hope I can get some help here.
Yesterday I rebooted my S4 Active after I installed some app updates, and suddenly WIFI can't be enabled anymore.
First I thought the phone might be broken, but I tested a factory reset and WIFI works again.
But I don't want to reinstall all apps and lose app settings and so on. I also want to know what is causing this issue, it might happen again.
I am on official Stock Rom (Android 4.4.2) I9295XXUCNE5 I9295PHNCNE1. I am using this rom without any problems since a half year.
So I did some testing with adb and usb debugging, and for some reason the wifi kernel driver cannot be loaded. I tried loading it manually with:
Code:
insmod /system/lib/modules/dhd.ko
But this fails with:
Code:
insmod /system/lib/modules/dhd.ko
insmod: init_module '/system/lib/modules/dhd.ko' failed (Exec format error)
I looked into output of kmesg, and it shows this when trying to load the wifi module:
Code:
<3>[ 614.365997] QSEECOM: qsee_disable_clock_vote: Client error.Extra call to disable SFPB clk
<3>[ 614.362304] QSEECOM: qseecom_ioctl: Failed to vote for SFPB clock-6
<3>[ 614.362060] QSEECOM: qsee_vote_for_clock: SFPB Bandwidth req failed (-6)
<3>[ 614.361816] AXI: msm_bus_scale_client_update_request(): Client 3720895680 passed invalid index: 3
Again when I do a factory reset, WIFI works fine again, so it has to be a software bug somewhere.

After factory reset and working WiFi disable Play Store auto update.
Do one app update, test wifi, next app update, test WiFi,...
Easier to identify if an app is source of issue than do all in one update.
Not sure if insmod or other module related commands might need su credentials provided by rooting.

O-T said:
After factory reset and working WiFi disable Play Store auto update.
Do one app update, test wifi, next app update, test WiFi,...
Easier to identify if an app is source of issue than do all in one update.
Not sure if insmod or other module related commands might need su credentials provided by rooting.
Click to expand...
Click to collapse
That's kind of pain in the ass when you have like 100 apps installed
Well I know the last apps that got updated. But how can this damage wifi system driver? And yes insmod needs root , and my phone was NOT rooted prior this issue. I rooted it know in order to properly debug the problem.
best regards,
Andre

delta_ray said:
That's kind of pain in the ass when you have like 100 apps installed
Well I know the last apps that got updated. But how can this damage wifi system driver? And yes insmod needs root , and my phone was NOT rooted prior this issue. I rooted it know in order to properly debug the problem.
best regards,
Andre
Click to expand...
Click to collapse
Try flashing the NE5_PHN_wifi_150107.zip in CWM from the NE5 folder on my GDrive.

JASONRR said:
Try flashing the NE5_PHN_wifi_150107.zip in CWM from the NE5 folder on my GDrive.
Click to expand...
Click to collapse
Thanks I tried this. Unfortunately, the problem persists.
Do you know which files are used by the WIFI kernel module?
My guess is that some config file causes this problem.

delta_ray said:
Thanks I tried this. Unfortunately, the problem persists.
Do you know which files are used by the WIFI kernel module?
My guess is that some config file causes this problem.
Click to expand...
Click to collapse
Those are the files in the zip file. You can also try deleting data/misc/wifi/wpa_supplicant.conf and rebooting or even try deleting the entire folder.
You can also try my ROM, super WizCyan that is based on the PHN firmware with mostly S5 apps.

Can your rom installed without factory reset over stock rom?
A side note, Play Store also does not work anymore. I am online over LTE and can use Internet, but Play Store gets timeout while loading.
Some more debugoutput from logcat, but not helping much:
Code:
E/WifiHW ( 848): ##################### set firmware type 0 #####################
I/WifiHW ( 848): module is semco
E/WifiHW ( 848): ==========[WIFI] Station firmware load ===========
E/WifiHW ( 848): ==========[WIFI] SEMCO MODULE ===========
E/WifiHW ( 848): return of insmod : ret = -1, Exec format error
If I just knew what is causing the driver fail.

delta_ray said:
Can your rom installed without factory reset over stock rom?
A side note, Play Store also does not work anymore. I am online over LTE and can use Internet, but Play Store gets timeout while loading.
Some more debugoutput from logcat, but not helping much:
Code:
E/WifiHW ( 848): ##################### set firmware type 0 #####################
I/WifiHW ( 848): module is semco
E/WifiHW ( 848): ==========[WIFI] Station firmware load ===========
E/WifiHW ( 848): ==========[WIFI] SEMCO MODULE ===========
E/WifiHW ( 848): return of insmod : ret = -1, Exec format error
If I just knew what is causing the driver fail.
Click to expand...
Click to collapse
Unfortunately not, as most of the stock apps have been replaced by S5 apps. You can try but will get a lot of fc's. If you want to try without factory reset use super backup to backup calls, call logs, contacts and calendar and clear cache and data for these before flashing ROM as well as clear cache and dalvic and restore these after flashing the ROM.
Any specific reason why you do not want to wipe data. I always do it once in a couple of months and reconfigure all apps except for a couple of banking apps that I redtore with titanium backup to save the hassle of contacting the banks again. This helps to clear the clogginf od data and keep the phone smooth.
For playstore you can wipe cache and data for google play & play services and stop them from running.
---------- Post added at 01:20 PM ---------- Previous post was at 01:08 PM ----------
Did you try deleting data/misc/wifi/wpa_supplicant.conf and rebooting and/or deleting the entire data/misc/wifi folder

JASONRR said:
Any specific reason why you do not want to wipe data. I always do it once in a couple of months and reconfigure all apps except for a couple of banking apps that I redtore with titanium backup to save the hassle of contacting the banks again. This helps to clear the clogginf od data and keep the phone smooth.
For playstore you can wipe cache and data for google play & play services and stop them from running.
Click to expand...
Click to collapse
Just pure lazyness . But it seems like that I have to go for the factory reset and backup/restore all apps after.
However I hope to find the source of this issue, who knows when it will happen again.

delta_ray said:
Just pure lazyness . But it seems like that I have to go for the factory reset and backup/restore all apps after.
However I hope to find the source of this issue, who knows when it will happen again.
Click to expand...
Click to collapse
If it works after factory reset, then I would say there is corruption in data. Try deleting 'data/misc/wifi' folder flash the wifi zip and restart

I restored the /data/misc/wifi folder from an older working backup.
Still the same error, there must be something else causing the problem.

delta_ray said:
I restored the /data/misc/wifi folder from an older working backup.
Still the same error, there must be something else causing the problem.
Click to expand...
Click to collapse
I would suggest that you delete thd folder itself. Also you could try with the Ktoonez kernel from here
http://forum.xda-developers.com/showthread.php?p=51925641

delta_ray said:
I restored the /data/misc/wifi folder from an older working backup.
Still the same error, there must be something else causing the problem.
Click to expand...
Click to collapse
Have you changed LTE-modem (NON-HLOS.BIN) from what's in stock *NE5 ROM you informed in OP?
http://forum.xda-developers.com/showthread.php?p=56955843

O-T said:
Have you changed LTE-modem (NON-HLOS.BIN) from what's in stock *NE5 ROM you informed in OP?
http://forum.xda-developers.com/showthread.php?p=56955843
Click to expand...
Click to collapse
No haven't change LTE-Modem Software, still have the stock NE5 installed.

JASONRR said:
I would suggest that you delete thd folder itself. Also you could try with the Ktoonez kernel from here
http://forum.xda-developers.com/showthread.php?p=51925641
Click to expand...
Click to collapse
I guess I should get KT-SGS4-KK4.4-AOSP-jactive_eur-04.19.2014.zip?
This kernel works with my Stock 4.4.2 rom?

delta_ray said:
I guess I should get KT-SGS4-KK4.4-AOSP-jactive_eur-04.19.2014.zip?
This kernel works with my Stock 4.4.2 rom?
Click to expand...
Click to collapse
Not that one, get KT-SGS4-KK4.4-TW-eur-01.03.2015.zip, there is an issue with touchscreen which is being looked into, I am currently using KT-SGS4-KK4.4-TW-eur-01.09.2015_debug2.zip from the debug folder.

JASONRR said:
Not that one, get KT-SGS4-KK4.4-TW-eur-01.03.2015.zip, there is an issue with touchscreen which is being looked into, I am currently using KT-SGS4-KK4.4-TW-eur-01.09.2015_debug2.zip from the debug folder.
Click to expand...
Click to collapse
The kernel did not work on stock rom. Anyway I did another factory reset and restored most apps and settings using TitanBackup Root.
And guess what happened after restore of all the apps & settings?
WIFI is broken again.
Does somebody know all data files are used by WIFI?

delta_ray said:
The kernel did not work on stock rom. Anyway I did another factory reset and restored most apps and settings using TitanBackup Root.
And guess what happened after restore of all the apps & settings?
WIFI is broken again.
Does somebody know all data files are used by WIFI?
Click to expand...
Click to collapse
It seems that something in the settings is breaking the wifi. You can wipe the data of settings and wifi individually and check if it fixes the issue.
If you are doing factory reset, I always recommend to redo the settings again rather than restoring through TB.
Can you take a logcat and send the entire one to check if there is anything there.

Not sure if I mentioned it but I removed "wpa_supplicant.conf" multiple times, it doesn't solve the problem.

JASONRR said:
It seems that something in the settings is breaking the wifi. You can wipe the data of settings and wifi individually and check if it fixes the issue.
If you are doing factory reset, I always recommend to redo the settings again rather than restoring through TB.
Can you take a logcat and send the entire one to check if there is anything there.
Click to expand...
Click to collapse
How can I just reset WIFI settings?

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

Flashed Chainfire's modified boot.img, still no root? (solved: can't edit build.prop)

I searched, but didn't want to hijack a thread...
I just flashed marshmallow from the factory images (full wipe) with TWRP and chainfire's boot.img (http://forum.xda-developers.com/apps/supersu/wip-android-6-0-marshmellow-t3219344). Then I downloaded Chainfire's SuperSU 2.52 beta, and flashed it via TWRP. SuperSU is now installed but it doesn't look like root is working, even though SuperSU "grants" apps root access.
What did I do wrong?
Thanks
Edit: Check posts 6/7 for setting SElinux to permissive to be able to edit build.prop

EvanVanVan said:
I searched, but didn't want to hijack a thread...
I just flashed marshmallow from the factory images (full wipe) with TWRP and chainfire's boot.img (http://forum.xda-developers.com/apps/supersu/wip-android-6-0-marshmellow-t3219344). Then I downloaded Chainfire's SuperSU 2.52 beta, and flashed it via TWRP. SuperSU is now installed but it doesn't look like root is working, even though SuperSU "grants" apps root access.
What did I do wrong?
Thanks
Click to expand...
Click to collapse
Can you define "not working?" I had to free up some space in /system before I could properly install Busybox in order for root apps to function properly.

Yeah, that's probably my exact problem. How can I free up space in system without having root? I tried to uninstall a half dozen Google apps from the play store (at least uninstall them back to their "base version"), but it only freed up like .17mb (Root Explorer said I had 16.17MB free in System instead of the 16MB it said originally).
Edit: Ok, I bought I was able to delete a couple Google Systems apps (Sheets/Slides/PingmeKeyboardwhatever) and have 200MB free in the System partition. I installed BusyBox successfully. I still can't get Root Explorer to open up the build.prop in a text editor.

EvanVanVan said:
Yeah, that's probably my exact problem. How can I free up space in system without having root? I tried to uninstall a half dozen Google apps from the play store (at least uninstall them back to their "base version"), but it only freed up like .17mb (Root Explorer said I had 16.17MB free in System instead of the 16MB it said originally).
Click to expand...
Click to collapse
to get root on marshmallow, you need to flash a custom kernel(or modified stock) and supersu 2.5 or 2.51. the custom kernel part is very important.

simms22 said:
to get root on marshmallow, you need to flash a custom kernel(or modified stock) and supersu 2.5 or 2.51. the custom kernel part is very important.
Click to expand...
Click to collapse
I was thinking that's what chainfire's boot.img (http://forum.xda-developers.com/apps/supersu/wip-android-6-0-marshmellow-t3219344) was?
BetterBatteryStats seems to be installed as a System app properly now, and I could delete file in System/apps with Root Explorer. But I still can't edit my build.prop...
Edit: yeah, root checker says I have full root access. Now just to figure out how to edit the stupid build.prop.
When trying to open the build.prop in the text editor via Root Explorer:
"Root Explorer was unable to read this file. Please check that your device is rooted correctly and that access has been granted at the Superuser prompt."

EvanVanVan said:
I was thinking that's what chainfire's boot.img (http://forum.xda-developers.com/apps/supersu/wip-android-6-0-marshmellow-t3219344) was?
BetterBatteryStats seems to be installed as a System app properly now, and I could delete file in System/apps with Root Explorer. But I still can't edit my build.prop...
Edit: yeah, root checker says I have full root access. Now just to figure out how to edit the stupid build.prop.
Click to expand...
Click to collapse
lol, i had the same issue. pissed me off, couldnt change my build.prop. so i kept on setting up, and rebooted a few times. then, it just starting working properly. and edited my build.prop
it could because i used an app to change SElinux to be permissive.

simms22 said:
lol, i had the same issue. pissed me off, couldnt change my build.prop. so i kept on setting up, and rebooted a few times. then, it just starting working properly. and edited my build.prop
it could because i used an app to change SElinux to be permissive.
Click to expand...
Click to collapse
Aha, thank you. Setting SElinux to permissive allowed me to edit the build.prop.
For future reference, I was able to temporarily set SElinux to permissive from the instructions in this thread (http://forum.xda-developers.com/xposed/how-to-set-selinux-to-permissive-boot-t3034245).
Basically:
Code:
adb shell
su
setenforce 0
Then I was able to edit my build.prop (for my lcd density), and after restarting SElinux reverts back to enforced.

EvanVanVan said:
Aha, thank you. Setting SElinux to permissive allowed me to edit the build.prop.
For future reference, I was able to temporarily set SElinux to permissive from the instructions in this thread (http://forum.xda-developers.com/xposed/how-to-set-selinux-to-permissive-boot-t3034245).
Basically:
Code:
adb shell
su
setenforce 0
Then I was able to edit my build.prop (for my lcd density), and after restarting SElinux reverts back to enforced.
Click to expand...
Click to collapse
ive been using an app for viper4android, it also needs SElinux to be permissive. all i do is press a button to make it permissive or enforcing. it can be done in a terminal emulator app as well.