Related
I seem to be having an odd problem with my new G1.
In any Cupcake build (JF 1.51, TheDude's 1.2, Official ADP) I flash, neither the compass nor the accelerometer sensors work at all. I have flashed between them several times, with an Alt+W each time, so I know it's not a bad flash.
The strange thing is, when I jump back to an official RC29 build, both sensors work fine. I haven't tried RC30 or anything else, but I know the sensors are physically functional.
I have re-flashed the latest radio as well, as it is currently using 2.22.19.26I.
If anyone can help me with this problem, I would greatly appreciate it.
gigawatts said:
I seem to be having an odd problem with my new G1.
In any Cupcake build (JF 1.51, TheDude's 1.2, Official ADP) I flash, neither the compass nor the accelerometer sensors work at all. I have flashed between them several times, with an Alt+W each time, so I know it's not a bad flash.
The strange thing is, when I jump back to an official RC29 build, both sensors work fine. I haven't tried RC30 or anything else, but I know the sensors are physically functional.
I have re-flashed the latest radio as well, as it is currently using 2.22.19.26I.
If anyone can help me with this problem, I would greatly appreciate it.
Click to expand...
Click to collapse
I think your using the pre-cupcake apps. Did u download the apps after you updated or did you install them from a back up?
Best way to check, You should got to settings and then sounds&display and check off orientation. You phone should switch from portrait to landscape when you rotate any program (except homescreen). If that works then nothing is wrong with your phone. If it doesn't then something happened somewhere weird
any apps i have installed have been after i flashed a rom (after a wipe) and not from a backup. Plus, something as simple as Google Maps or the Browser App should just rotate without opening the keyboard.
Best way to check, You should got to settings and then sounds&display and check off orientation.
Click to expand...
Click to collapse
By that I assume you place the check mark (lit green) next to the option, not "check it off" (not lit green). I have tried both checked and unchecked in pre-installed apps like maps and browser, and still nothing.
Small update. I just flashed JF's v1.43_RC33 with root, keeping the same more recent radio, and both sensors work there, as they do in RC29. It seems to be ONLY cupcake based roms where they don't work.
Any other suggestions anyone has for me? I might try a hero build next, to see if they work there, but I'm not sure how stable they are yet.
Any help/suggestions would be greatly appreciated!
Accelerometer fix
http://forum.xda-developers.com/showpost.php?p=4081673&postcount=4885
I tried your suggestion, and it did not work. Unlike the other user reporting that the sensors would work for a short time after reflashing, mine has never worked after a cupcake flash. Only after a pre-cupcake flash.
Although ideas like that are what I am looking for, possible corrupt config files that need to be cleared or maybe a mod probe command of some sort to activate or wake up the sensors.
Upon some more inspection, I get the feeling something is wrong with my akmd process, or whatever executable generates the akmd_set.txt compass and accelerometer calibration data. I tried to follow some instuctions to purge the akmd_set.txt file to clear any bad config, but the file is no where to be found. My phone doesnt seem to generate one at all when it's booting.
The akmd process does remain running in the background, as here is its ps output:
Code:
# ps | grep akmd
compass 77 1 1320 328 c020d268 afe0c45c S /system/bin/akmd
This is the output I get from logcat when I try to manually run the /system/bin/akmd process or when it restarts automatically after being killed:
Code:
D/AKMD ( 362): akmd 1.6.4 START
D/AKMD ( 362): library version: 1.2.1.1129
D/AKMD ( 362): Compass OPEN
D/AKMD ( 362): No calibration data
D/AKMD ( 362): Can not initial compass parameters error: -5
and this is the output I get when I run a program like Orienteer:
Code:
I/ActivityManager( 90): Starting activity: Intent { action=android.intent.action.MAIN categories={android.intent.category.LAUNCHER} flags=0x10200000 comp={com.deafcode.android.Orienteer/com.deafcode.android.Orienteer.Orienteer} }
I/ActivityManager( 90): Start proc com.deafcode.android.Orienteer for activity com.deafcode.android.Orienteer/.Orienteer: pid=363 uid=10041 gids={}
D/SensorManager( 363): found sensor: AK8976A 3-axis Accelerometer, handle=0
D/SensorManager( 363): found sensor: AK8976A 3-axis Magnetic field sensor, handle=1
D/SensorManager( 363): found sensor: AK8976A Orientation sensor, handle=2
D/SensorManager( 363): found sensor: AK8976A Temperature sensor, handle=3
D/dalvikvm( 363): GC freed 920 objects / 64320 bytes in 92ms
D/LocationManager( 363): Constructor: service = [email protected]
D/Sensors ( 90): sensors=00000005, real=00000005
D/GpsLocationProvider( 90): setMinTime 2000
W/IInputConnectionWrapper( 145): showStatusIcon on inactive InputConnection
I/ActivityManager( 90): Displayed activity com.deafcode.android.Orienteer/.Orienteer: 1313 ms
D/dalvikvm( 145): GC freed 795 objects / 45896 bytes in 165ms
D/GpsLocationProvider( 90): TTFF: 7203
Maybe this will give someone some more insight as to the problem I am having.
hello,
i me french and i have the same problem.
No akmd_set.txt on my phone.
If you are a solution could you partage it ?
I think it's a driver problem but i'm not sure.
JEEP
Unfortuantly I have still not found a solution, but continue to look for one. I will let you know here if I do manage to solve it.
I am also having the same problem. Wiping does not fix it and the method stated by Cyanogen didn't work either. I don't know if this will be any help, but I do know the accelerometer issue started about 3 or 4 days ago for me. Maybe if I list things I've done to my phone in the last few days, it might help narrow down the cause if others with the same issue compare their experiences to each other.
I have a US T-Mobile G1 and I have been rooted since February. Since that time I have upgraded to (and currently use) the latest radio from HTC, Haykuro's SPL, and a class 6 4gb card. I've also been through more roms than I can count in that time, all without an accelerometer issue till now.
Now that I've got all that out of the way here's the more relevant stuff:
Within the last week I have upgraded to Cyanogen's 1.3.1 recovery boot and installed the latest JAC Hero build. I repartitioned my card into 3 partitions with the directions given in JustAnotherCrowd's thread using parted in the recovery's console.
Code:
#parted /dev/block/mmcblk0
rm 1
rm 2
mkpartfs primary fat32 0 3420
mkpartfs primary ext2 3420 3932
mkpartfs primary linux-swap 3932-3964
This is the first time I've ever used apps to sd. After using that rom for about a day, I switched to Cyanogen's build and wiped my user data without wiping the ext partition of my sd card and I continued to use the swap partition on my Cyanogen build. I'm fairly sure but not 100% certain that the accelerometer was still working at this point. Soon after installing this rom, Cyanogen released an update including the compcache modules to replace the linux-swap setup. I installed the custom userinit.sh script to system/sd to activate compcache. Then Cyanogen released another update (immediate bug fixes) almost as soon as I got this rom working. I flashed the update.zip, but then it started to boot loop. I wiped the phone (not the ext partition), still boot looped. I took out the sd, still boot looped. I put the sd card back in wiped again, reflashed, and then clicked "repair ext file system". STILL BOOT LOOPED! (Don't say I just wasn't giving it enough time to boot because I acctually watched the boot animation flicker in and out for a second and start over.) Next, I used fastboot to restore only the user data from a nandroid backup of an older Cyanogen rom. This time it worked. Next, I installed the audio resources to system/sd/media and linked them using the userinit.sh file. The next day, I realized that the accelerometer was no longer functioning.
I hope this description helps to figure this out.
I'm having the exact same issue.
testing567, can you post the userinit.sh file you are currently using, and possibly you or someone else post their userinit.sh of a phone with a working accelerometer and compass here?
I am thinking that one of my init scripts may not be calling the akmd service properly, as in not with the correct permissions or something, and thus not calibrating itself on boot. I was planning on upgrading to the latest cyanogen update today, as i am running 3.6.5 right now. I was also considering upgrading my SPL to a dev SPL so i can use nandroid to backup (getting a little tired of loosing everything when attempting different roms to fix this issue).
I got my userinit.sh from this post.
http://forum.xda-developers.com/showpost.php?p=4140826&postcount=74
I also decided to take advantage of the media symlinking already in this script and pushed the audio resources to system/sd/media/.
I've always had the same issue when upgrading to a cupcake based rom. Nobody else until recently seemed to share my misfortune (sorry for everyone else). There is an exception though, JF 1.5 (T-Mobile) build the sensors work (although miscalibrated). I haven't found any other solutions or any other way to generate the settings file. My process output appears to be the exact same as you've posted.
I'll keep trying some things but I just want to keep this alive incase anyone else needs a fix and one of us comes up with a solution.
RemoteDJ, I may actually have a solution to your miscalibrated problem. In the process of going through and trying to get my sensors working, I created an empty akmd_set.txt file with chmod 777 permissions (just so it wouldnt ***** about some user permissions when trying to edit it), and then rebooted the phone. Upon looking at the file after reboot, it was filled with calibration data.
Although this has not fixed my problem, it may help you. Also, the application "Bubble" has a calibrate sensors menu option, which may help you too. I may have to try reverting back to JF 1.5 to see if I have better luck there. Was that JF 1.51 you were using? If not, please advise.
Yes it was JF 1.51, it's funny because I just got done making a blank chmod 777 akmd_set.txt lol. Of course i'm on the latest stable cm-3.6.8.1 currently and the sensor doesn't work at all.
Just so we stay up to date with each others findings, I also pulled the akmd app from Haykuro's ION, JF 1.43, JF 1.51, Official RC33 and the current CM build. I have only tried replacing the current one with the ION app (in recovery), so far no change, but I think the only file difference I noticed out of the files I pulled was that the JF 1.43 and Official RC33 seemd to be the same (haven't hashed them to verify) and different then the others which seem to be the same but since I haven't hashed any of them to verify yet I can't say for sure.
I am calling it a night right now but will let you know if I find anything tomorrow.
Just a followup with the hash info.. looks like I was correct:
517a87a4e6caa5e66f0520c68dcb7c0e - Official RC33
517a87a4e6caa5e66f0520c68dcb7c0e - JF 1.43
c3a80124ab072f9bf12cc9e4155a0f9f - JF 1.51
c3a80124ab072f9bf12cc9e4155a0f9f - ION
c3a80124ab072f9bf12cc9e4155a0f9f - CM 3.6.8.1
Another Edit: I am apparently not good at going to sleep.. Good News! (semi).
I left the akmd_set.txt in place (it got filled with data just like yours)
replaced ion/cm akmd with jf 1.43 and now the sensor appears to be working (although still miscalibrated for me, this might be a hardware issue.. lots of drops).
step by step.
copy jf1.43 akmd to sdcard (i just pulled it out of the update zip).
reboot recovery
mount /system
rm /system/bin/akmd
mount /sdcard
cp /sdcard/jf1.43_akmd /system/bin/akmd
then umount (probably not required)
reboot.
It still didn't work, but I deleted the akmd_set.txt via adb and then rebooted and voila!
Let me know if any of that works for you
Edit: I was able to fix my calibration by reverting to the rc30 akmd, I have absolutely no idea why my device is so picky, but it only has ever had correct calibration with accelerometer on the rc29/30 builds (this includes all official t-mobile ota releases). Anyway just wanted to through that out there incase anyone else uses the jf1.43 and is miscalibrated.
RemoteDJ,
Thank you so much for that suggestion! That totally worked for me! I flashed cm-3.6.8.1 tonight and replaced its /system/bin/akmd binary with the one from jf 1.42. After messing around with some permissions (I failed to realize the akmd binary was not set as executable when i moved it over ) i was able to create a blank akmd_set.txt, chmod 777 it, and then restart the akmd service (stop akmd, followed by start akmd).
I can not thank you enough for this suggestion! Guess it just took another similar brain bashing away at the same problem to solve it. I just wonder why this is not a problem for a lot of other people out there. It's the same hardware, so you would think everyone upgrading to cupcake would have an incompatible akmd binary. Strange...
Sweet, I'm really glad it worked for you!
I can't imagine for the life of me why other people don't have similar problems, but then again I've had a few problems that seemed indivualized to my device lol. Its only recently that I discovered a few other people were having problems with the accelerometor.
Oh well, all in all just glad this worked.
Maybe we can get Cyanogen to include this in his FAQ as an alternative for sensor repair for the people like us. I might reply on the latest build thread later, anyway have a good one.
So far I haven't had any luck with this. I'm actually tempted to send my unit back to HTC with the ota 1.5 cupcake on it and see what happens. I'm not sure if it was working when they sent it to me or not. It doeswork with the rc29 though.
I'm having the same issue, no compass apps seem to work, google sky maps doesn't work , the level app doesn't work, all are froze.
How can I fix it?
// New builds at http://download.cyanogenmod.com/?device=legend[/COLOR]
Always make a nandroid, and flash on your own risk!
Because teamdouche's nightly is more than a month old, I decided to build a nightly myself.
Changelog:
http://cm-nightlies.appspot.com/?device=legend
---
10. feb build:
Everything to "Fix music widget transparency in landscape layout." is included.
http://www.mediafire.com/?udu1gnbnh4dul8d
---
23. jan build:
Everything to "Backport ICS rotation animations to gingerbread (android_frameworks_base)" is included.
http://www.mediafire.com/?ebprbr233gv1b50
---
13. jan build: - the friday 13. edition with Holo theme for ring lockscreen
Everything to "CM: Add p500 (LGE Optimus One) device (android_vendor_cyanogen)" is included.
http://www.mediafire.com/?pu4xfomdzxmvu5e
---
10. jan build:
Everything to "Exchange: calendar sync window linked to email sync window (android_packages_apps_Email)" is included.
http://www.mediafire.com/?9cckq1q24rqb9km
---
4. jan build:
Everything to "init: Let radio user manipulate service properties (android_system_core)" is included.
http://www.mediafire.com/?wb073sdj3b80k5y
---
2. jan build:
Everything to "CM: Add p925 (LGE ATT Thrill 4G) device (android_vendor_cyanogen)" is included.
http://www.mediafire.com/?8qo1rkjc5st21bs
---
23. dec build:
Everything to "Camera: Autofocus camcorder only if needed (android_packages_apps_Camera)" is included.
http://www.mediafire.com/?sze4uat4rl9weob
---
19. dec build: + T9 Dialer
Everything to "Preference to disable bootanimation for faster boot. (1/2 CMParts) (android_packages_apps_CMParts)" is included.
http://www.mediafire.com/?8ka5ouhorodnrzj
---
18. dec build:
Everything to "Fix emergency dialing on Samsung CDMA phones. Tested on Epic 4G, may also help others. DOES NOT FIX VIBRANT. (android_frameworks_base)" is included.
http://www.mediafire.com/?yon4treurcv557h
Nice to see that the Belgian keyboard layout is finally corrected
Just installed it and no problems so far, runs the same as 7.1
An update for HTC Legend, wow ! Thank you dude
Market does not work for me afte update!
stewie01 said:
Market does not work for me afte update!
Click to expand...
Click to collapse
After what update? Market is working fine here
Dialpad : T9 Dialer (android_packages_apps_Contacts) version building right now!
Edit: Up!
Tried to flash the one from 18th december, but CWM failed to verify the package, trying to download new one from the 19th...
ranger4740 said:
Tried to flash the one from 18th december, but CWM failed to verify the package, trying to download new one from the 19th...
Click to expand...
Click to collapse
I haven't encountered any problem while flashing.
can I update without wipe from regular 7.1? tnx
guap said:
can I update without wipe from regular 7.1? tnx
Click to expand...
Click to collapse
I guess so, but make a nandroid!
done
the stock t9 dialer doesn't show dial pad for default... really unuseful to have a t9 dialer (finally!!!) but still having to hold down a button to have the keyboard... that was the main reason to me for upgrade, and because of this I reverted back to my original 7.1 in ~10 minutes... also seemed a bit choppy, unable to use wavesecure, lost all my google apps settings... sounds like a NO for the upgrade with no wipe to me and no time to set all again at this time
thanks anyway
Well I tried this rom also just for this T9 Dialer...
I wiped before flashing so to be sure having a clean system.
Nothing special to mention about the rom itself... It works as the 7.1 does. (well, tested one hour only... Can't say for battery drain or else)
Regarding the dialer... Well, I think I don't get it well.
First, in the parameters, ensure you choose what the dialer will look for: Numbers or name. In my case, names.
Then, typing the numbers shows.... The numbers. the only way I found to get proposal according to the first digits is to go to another tab (contact for instance), and coming back to the dialer tab it will show me the possible contacts I wish to call.
Not very useful, neither practical.
I hope someone will find another way to use it ... More efficiently?
Thank you anyway for the work, mate! Really appreciated!
slovenec88 said:
I haven't encountered any problem while flashing.
Click to expand...
Click to collapse
Hi, thanks, I flashed the one from 18th dec. hung on the HTC boot screen for 10 mins reflashed and turned on signature verification in CWM and failed, downloaded again still no good, downloaded the one from the 19th, working ok, no problems.....
The nightly update seams to work really good, seams to be even more stable than 7.10, seams to fix the issue with ADW having to reload itself after a while.
GPS is still an issue, takes forever to get lock if at all...
Thanks, keep up the good work!
cyanogenmod fix for gps
$ su
# stop rmt_storage
# dd if=/dev/zero of=/dev/block/mmcblk0p13
# dd if=/dev/zero of=/dev/block/mmcblk0p14
# reboot
better do a nandroid backup if it doesn`t boot up anymore
this fixes the gps lock in about 5-10 sec and its been available since 6.0 cyanogen
caretaker01 said:
$ su
# stop rmt_storage
# dd if=/dev/zero of=/dev/block/mmcblk0p13
# dd if=/dev/zero of=/dev/block/mmcblk0p14
# reboot
better do a nandroid backup if it doesn`t boot up anymore
this fixes the gps lock in about 5-10 sec and its been available since 6.0 cyanogen
Click to expand...
Click to collapse
Thanks, trying as i type, in my case the above didn't seam to make any change, it was seeing the sats and using them eg. 6 in view 6 in use even after 10 mins no lock.
Right now it is seeing 12 sats, 10 in use been waiting over 5mins, still no lock.
Why are you guys copy-pasting commands you don't know what they actually do?
Sent from my HTC Legend
this fix was for vision and ace
I do not know if the partitionmapping is the same on the Legend
I do not recommend doing a dd zero until someone confirms the partitions
EDIT: the commands won't brick your device, in fact they DO NOTHING since the devs do not exist
Code:
block # ls -lha
brw------- 1 root root 179, 0 Dec 19 00:43 mmcblk0
brw------- 1 root root 179, 1 Dec 19 00:43 mmcblk0p1
brw------- 1 root root 31, 0 Dec 19 00:43 mtdblock0
brw------- 1 root root 31, 1 Dec 19 00:43 mtdblock1
brw------- 1 root root 31, 2 Dec 19 00:43 mtdblock2
brw------- 1 root root 31, 3 Dec 19 00:43 mtdblock3
brw------- 1 root root 31, 4 Dec 19 00:43 mtdblock4
brw------- 1 root root 31, 5 Dec 19 00:43 mtdblock5
I found it nice to see that someone picked the from source builds up and want to take some load off
http://datatomb.de/mirror/ROMs/CM7.2/update-cm-7.2.0-RC0-111222-Legend-KANG-signed.zip
this is my build from now, all changes until 21.12.2011 21:00 CET are included
DooMMeeR said:
EDIT: the commands won't brick your device, in fact they DO NOTHING since the devs do not exist
Click to expand...
Click to collapse
People stupid enough to copy/paste these commands would rather deserve /boot, /recovery, /system and /data wiped if you ask me.
@Blayo and Ali Ba, I did do a search before blindly typing the commands given, once I was satisfied they seamed to be legit, and not malicious i did the deed, obviously not every thing is equal in android land and something for one flavour of android O/S is transposable to another one.
---------- Post added at 02:53 AM ---------- Previous post was at 02:47 AM ----------
ranger4740 said:
Thanks, trying as i type, in my case the above didn't seam to make any change, it was seeing the sats and using them eg. 6 in view 6 in use even after 10 mins no lock.
Right now it is seeing 12 sats, 10 in use been waiting over 5mins, still no lock.
Click to expand...
Click to collapse
Ok, so after over 30 mins still no location lock, gps seeing and using upwards of 12 sats.
Oh Well, [email protected] Happens
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?
XDA AND I WE DO NOT MAKE RESPONSABLE OF ANY DAMAGE SUFFER
Hi i need help form others for making a good cm12.1 rom and future cm13 rom here i put the TODO and the progress, will be post all source code as things progress...
TODO:
Add recovery usb sticks support
Add support to f2fs
Kernel optimizate make compatible with GGC 5.1( lets see if we can)
Fix all bugs
Compile without any error
Make ZIP pakage I never fixed it need help
Test build and look for errors
Progress:
LZMA compression in kernel
LANG=C brunch ouya best command for building it
Add f2fs to rom not to kernel
Fix bluetooth erros building rom
Used arm-eabi 4.7 for compiling kernel if not you will get errors
Fix kernel error with this commit https://github.com/Dazzozo/huawei-kernel-3.4/commit/158c9bf883a203530b2f558be1b3cd168fc3d202
Fit New Recovery in /recovery partition
DOWNLOAD:
ALPHA: http://www.mediafire.com/download/o9yqmdvuygoip3g/cm-12-20151024-UNOFFICIAL-ouya.zip (untested)
Source code:
Kernel: https://github.com/werty100/android_kernel_boxer8_ouya
Tree: https://github.com/werty100/android_device_boxer8_ouya
Vendor: https://github.com/werty100/android_vendor_boxer8_ouya
I for one am thankful for your hardwork if you get this working. I still use my Ouya daily strictly for xbmc and cm12/13 would bring much needed new life to it.
I have fixed recovery, it works but it doesnt have the option usbdisk for mounting USBs so need more work on it
Here i give to you recovery for people to test it i need tester i am busy...
So do I just follow the old CM tutorials and install this instead at the recovery step?
bb_chazz said:
So do I just follow the old CM tutorials and install this instead at the recovery step?
Click to expand...
Click to collapse
It is a experimental recovery and need to be config for mounting usbs so now not use it unless you want to test it and report back experience and bugs,
Also the build posted it doesnt boot at all , i am keep working when i have time for it. I think a new build will come this weekend
I was going to just test but if you want to work on it a little more first just let me know and I will test when ready.
Starting new build with a few changes i want this build to boot up in a few hours i will post resoults and upload source code
Looking forward for this!
Wow, I just fired up my Ouya for the first time in a while today and figured I would see if anyone has done anything recently. Glad to see this little box isn't completely dead!
Any chance of some compile instructions?
Bussy
werty100 said:
Starting new build with a few changes i want this build to boot up in a few hours i will post resoults and upload source code
Click to expand...
Click to collapse
I am with exams and busy and i have to soft-briked my ouya now that i sof-briked my ouya I have obtein what i was looking for the mount points for looking if it si the ral error of builds not finishing compiling:
[email protected]:/ $ ls -al /dev/block/platform/sdhci-tegra.3/by-name
lrwxrwxrwx root root 2000-01-01 01:00 APP -> /dev/block/mmcblk0p3
lrwxrwxrwx root root 2000-01-01 01:00 CAC -> /dev/block/mmcblk0p4
lrwxrwxrwx root root 2000-01-01 01:00 LNX -> /dev/block/mmcblk0p2
lrwxrwxrwx root root 2000-01-01 01:00 MDA -> /dev/block/mmcblk0p8
lrwxrwxrwx root root 2000-01-01 01:00 MSC -> /dev/block/mmcblk0p6
lrwxrwxrwx root root 2000-01-01 01:00 SOS -> /dev/block/mmcblk0p1
lrwxrwxrwx root root 2000-01-01 01:00 UDA -> /dev/block/mmcblk0p9
lrwxrwxrwx root root 2000-01-01 01:00 UPP -> /dev/block/mmcblk0p5
lrwxrwxrwx root root 2000-01-01 01:00 USP -> /dev/block/mmcblk0p7
LNX is boot that was the one i was searching for but we cant use this boot partition beocuse if we bricked it will be very difficult to recover it
In cm11 updater-script boot.img is extract to system: package_extract_file("boot.img", "/system/boot.img");
So i need more of research to make a new build i will try this friday or weekend if someones nows how to fix this issue tell us
gumbi2400 said:
Wow, I just fired up my Ouya for the first time in a while today and figured I would see if anyone has done anything recently. Glad to see this little box isn't completely dead!
Any chance of some compile instructions?
Click to expand...
Click to collapse
With cm12.1 is simple downlad cm12.1 source and download ouya parts and when building use this specific command LANG=C brunch ouya and just it , with the old source may have some problems but i am testing new soruce to see if it works if it compile 100% i will upload the new source changes
Good stuff. I always struggle setting up my repo manifests properly. Next goal is to compile Android TV properly with the new sources.
gumbi2400 said:
Good stuff. I always struggle setting up my repo manifests properly. Next goal is to compile Android TV properly with the new sources.
Click to expand...
Click to collapse
Thanks for working for the ouya, i am compiling cm12.1 right now with las cm12.1 soruce and fixes for ouya wait like 3 hours or less i will post new source code
Erros making zip
I am having a lot of erros making zip with no releasetools Magic Error with cm11 releasetools a lot of errors i cant finnished build :crying::crying:
Someone know how to fix it
werty100 said:
I am having a lot of erros making zip with no releasetools Magic Error with cm11 releasetools a lot of errors i cant finnished build :crying::crying:
Someone know how to fix it
Click to expand...
Click to collapse
https://github.com/TeamRegular/android_device_ouya_ouya1_1/tree/cm-12.0/releasetools
werty100 said:
I have fixed recovery, it works but it doesnt have the option usbdisk for mounting USBs so need more work on it
Here i give to you recovery for people to test it i need tester i am busy...
Click to expand...
Click to collapse
thanks for your time and work on this device,& ill be glad, to be a tester!!
THIS THREAD IS FOR DEVELOPERS ONLY. IF YOU ARE NOT A DEVELOPER (or very tech-savvy and well-versed), MOST LIKELY YOU SHOULD NOT POST HERE.
By request, I am creating this thread for developer discussion. This is the place for developers to ask questions about how to handle/implement/embed SuperSU, discuss the operation of SuperSU, suggest improvements to compatibility, etc.
This thread hopefully reduces important developer related matters from being buried in the more user-oriented threads.
Please always include the version number of SuperSU you are referring to, even if it's the latest version right now. If applicable, also include information about phone and firmware you are testing with.
Chainfire said:
The stop-gap solution is to disable this caching completely, which is what the 000000deepsleep script does, which you can find mentioned or quoted in many posts around the forum. From SuperSU 2.66 onwards, that script is automatically installed on Samsung devices when systemless root is used.
Click to expand...
Click to collapse
Please forgive me for posting (in a cf-auto-root thread) and digging afterwards. I had thought I'd just dump the info and forget about it, but I couldn't stop digging...
...which led me to the quoted material.
Digging in the supersu 2.66 update-scriptbinary, I see that you're detecting "samsung" in the build fingerprint, and if true, doing a systemless install AND applying a deepsleep fix. This works for Galaxy S6 devices, but not for some other similar platform devices. In particular, the Note5 has THREE devices that need caching disabled in order for deep sleep to function. (0:0:0:3 as well as :2 and :1.)
My first question is: does the SGS6 even have a file named "/sys/class/scsi_disk/0:0:0:3/cache_type"? If not, just write to all three files and don't worry about it. The third write would fail on the SGS6 and all would be good. It'd be no worse of a work-around than already exists (and I think it's a bad work-around.)
If that file DOES exist in the SGS6, then something would have caching turned off that really shouldn't. Of course, existing or not, automatically tossing in this deepsleep patch for every single device that has "samsung" in the build fingerprint would seem likely break proper caching in some yet unknown samsung device. Perhaps the SGS7 will change things up so that :1 should be left cache flushable, and :2 would be the only one that should block cache flushing.
As well, it's also possible that Samsung will pull in the kernel fix to resolve this issue before they release Android M. (Okay, perhaps it'd be more likely for Samsung to open source touchwiz... but we can always have fantasies.)
My problem with the work-around is expressed above: it can break something in the future (and cause a support headache when some ONE exynos7420 device is fixed, but the rest aren't.) As well, it sets precedent of having platform specific hacks in the generic update.zip (but only allowing for a single platform and not in an easily expandable way.)
Obviously, it would be a maintenance nightmare to have different "00000deepsleep" files for every different device model. (if 'zerolte.*', SGS6. If 'nobellte.*', Note5, etc.)...
In keeping with what I tell other people, I feel I now have an obligation to suggest A Better Way. (a person shouldn't complain about something unless they can make a reasonable suggestion on how it'd be better.)
So, here's my slightly convoluted (but expandable) suggestion:
You currently use /data/.supersu to read certain variables that modify the supersu.zip installer script. Perhaps those "platform specific lines" could be added to that file, and the installer script would put them in place. So, I could do the following in a recovery root shell before installing supersu.zip:
Code:
echo PLATFORMSTARTUP='echo "temporary none" > /sys/class/scsi_disk/0:0:0:1/cache_type' >> /data/.supersu
(I'd have included both (or all three) needed lines for samsung deep sleep, but I forget how to include CR in a shell cmdline.. )
Then, the supersu installer script would just read PLATFORMSTARTUP and write it's contents to /su/su.d/00000platformstartup (and set perms.)
Given this type of thing, the existing 000000deepsleep hack would be removed. Then, individual devs could easily create simplistic "pre-installers" for supersu for specific platforms that need changes. Those "pre" installers would just write the needed PLATFORMSTARTUP lines to /data/.supersu...
... and then supersu.zip no longer needs platform specific hacks.
Some random XDA developer could then generate a simple "SGS6-supersu.zip" would only contain an edify script to mount /data and add/edit the .supersu file's PLATFORMSTARTUP variable to contain the two lines needed for deep sleep (and another dev could write a Note5 for the 3 lines needed on that platform... and so on..)
Take care
Gary
garyd9 said:
You currently use /data/.supersu to read certain variables that modify the supersu.zip installer script. Perhaps those "platform specific lines" could be added to that file, and the installer script would put them in place. So, I could do the following in a recovery root shell before installing supersu.zip:
...
Click to expand...
Click to collapse
The only problem with that is that it requires users to have two brain cells to rub together. We've seen time and time again on these forums that you can't assume this is always the case.
I think that Chainfire is doing pretty much the right thing here. At worst, disabling write-back caching will make I/O a bit slower, but that's better than not having deep sleep. The only suggestion I'd have is to add more devices (maybe up to 5), and to check for their existence before writing to them.
NZgeek said:
The only problem with that is that it requires users to have two brain cells to rub together. We've seen time and time again on these forums that you can't assume this is always the case.
I think that Chainfire is doing pretty much the right thing here. At worst, disabling write-back caching will make I/O a bit slower, but that's better than not having deep sleep.
Click to expand...
Click to collapse
The problems with the existing solution are:
1. It blindly alters the system kernel behavior for every single device samsung manufactures.
2. It only actually does any good for a single one of the dozens of devices from that sam manufacturer.
3. It completely ignores every OTHER device that might need a bit of help (and potentially does more harm than good for those devices.)
4. It encourages device developers (users on XDA) to download SuperSU.zip and re-package it to have device specific hacks in the .zip archive (creating a mess.)
Actually, I don't think I need to explain all the problems with the existing hack. I'd imagine (hope) that it was done as something quick to test out an idea, and was never intended to be left in place in it's current form.
NZgeek said:
The only suggestion I'd have is to add more devices (maybe up to 5), and to check for their existence before writing to them.
Click to expand...
Click to collapse
Which 5 devices? Who maintains that list? Who updates it for each firmware change that might require an update? Will there be a new "SuperSU.zip" package each time a firmware change on a device requires that one of those 5 be changed? Who deals with the support nightmare of saying "use SuperSU v a.bc for device X firmwawre Y" and "superSU v d.ef for device X firmware Z", etc?
My proposed solution takes all the device-specific stuff completely out of the SuperSU package. It changes it from a device-specific solution to be a more generic and expandable solution that requires LESS support from SuperSU and places the device specific burden outside.
Instead of encouraging device developers to repackage supersu to device specific packages, it encourages device developers to package something else alongside supersu that would work with the existing (and unaltered) supersu.zip (and would be future compatible.)
Take care
Gary
spiral777 said:
would there be a way to get kexec/ multirom working with systemless root?
and would flashing a modified boot image to a rom also effect the kexec hardboot partch of the kernel?
Click to expand...
Click to collapse
1- the current versions of systemless root make changes/additions to the kernel, but you're not "flashing a modified boot img", so kexec is not broken, since the kernel is in essence the same as before
2- yes it is possible for systemless root (tested with 2.65) to get it working on multirom, however some changes were needed; we're still debugging the problem to try to narrow down the issue, to get it to work with as little changes as possible
EDIT: I'll just mention the problems encountered in case @Chainfire wants to be aware of them
a) line 1170: dd if=/dev/zero of=$BOOTIMAGE bs=4096
since MultiROM creates a symlink, the above command actually starts nulling out a "dummy boot.img" file, which basically continues on, untill all free space in internal storage (or external sdcard where applicable) is filled out
b) when MultiROM-TWRP finishes installing SuperSU, the fake /data is still "busy" (some open file or something else keeping it busy), since it's busy, it can't be unmounted properly, and the real mount points don't get restored
at that point mrom injection will fail
using a lazy unmount helped alleviate that (as a workaround), but obviously not the best solution
c) the setprop sukernel.mount 1 (in launch_daemonsu.sh) doesn't trigger the mount properly, workaround was to mount it in the launch_daemonsu.sh using "mount -t ext4 -o loop /data/su.img /su" instead of the setprop
EDIT2: thanks @Captain_Throwback for the reminder
d) the attempted remount read-only, will cause a bootloop; workaround: had to comment that out
just FYI, but I'll check more thoroughly when I get a chance
@garyd9 @NZgeek
Some good points are raised. I am not going to go into them all individually.
There is one core point of disagreement though. While I do not think device-specific patches generally have a place in the SuperSU ZIP installer, the deep sleep issue affects so many million users it is too big to ignore. (By the way, as far as I know this issue affects all recent high-end Samsungs).
While I don't disagree with your ideal of custom pre/post installers, in reality most users will never discover the issue, and just blame SuperSU for suddenly bad battery life. This leads to many support emails, thread posts, bad rep, etc.
Contrast this to for example the LG G3 compatibility patch, which requires the user to indeed write a file to /data or use a pre-installer that does that, the device will simply not boot, which forces the user to either go back to stock, or search for and discover the fix.
Either way, you are right, the patch doesn't even work right for Note users. Thank you for pointing that out - nobody else ever did. I have come up with the following improved script. If for the moment, we put aside our differences regarding the inclusion of any device-specific fixes, what do you think of the following?
It will perform the cache_type change for any scsi_disk, but will skip the ones not set to write protected. This should catch the problem with devices that have a different disk layout, and prevent accidental reduced I/O speed for devices that are not affected.
Note that it is my understanding that the write protection mode cannot be reset without a flash chip power cycle, and as the protection is set by the bootloader long before our check, checking once at boot should suffice.
I would be grateful if you gave that a shot on an affected Note/Edge+ and report back. It successfully sets the cache_type for :1 and :2 on my S6.
Code:
for i in `ls /sys/class/scsi_disk/`; do
cat /sys/class/scsi_disk/$i/write_protect 2>/dev/null | grep 1 >/dev/null
if [ $? -eq 0 ]; then
echo 'temporary none' > /sys/class/scsi_disk/$i/cache_type
fi
done
Chainfire said:
I would be grateful if you gave that a shot on an affected Note/Edge+ and report back. It successfully sets the cache_type for :1 and :2 on my S6.
Click to expand...
Click to collapse
I won't be able to properly test this until at least tomorrow (Wed) evening... However, in the meantime, the following screenshots suggest that it'd also work on the Note5:
https://goo.gl/photos/61JWzoA5ir3PcDNr9
(This is with a custom kernel, however. I'll post a query in the Note 5 section asking people who are running a stock kernel to run similar commands to post the output here: http://forum.xda-developers.com/showpost.php?p=64773152&postcount=138 - I'll relay the results.)
Let me know when you'd like to debate on if SuperSU should fix (non-root related) bugs in only specific devices, all devices, no devices, or if it should just support a hook to allow third parties to fix both current and future/past devices. (Please don't get the wrong impression from that statement. SuperSU is your product, not mine... However you implement things is up to you.)
Please do let me know if I can be of further assistance to fix compatibility.
nkk71 said:
a) line 1170: dd if=/dev/zero of=$BOOTIMAGE bs=4096
since MultiROM creates a symlink, the above command actually starts nulling out a "dummy boot.img" file, which basically continues on, untill all free space in internal storage (or external sdcard where applicable) is filled out
Click to expand...
Click to collapse
I guess the script can be modified to detect a link and then check if said link is still pointing to /dev/...
Do double symlinks need to be taking into account? i.e. what is a symlink, /dev/block/platform/.../boot, /dev/block/mmcblk0pX, both?
b) when MultiROM-TWRP finishes installing SuperSU, the fake /data is still "busy" (some open file or something else keeping it busy), since it's busy, it can't be unmounted properly, and the real mount points don't get restored
at that point mrom injection will fail
using a lazy unmount helped alleviate that (as a workaround), but obviously not the best solution
Click to expand...
Click to collapse
Complete guesswork, but the backing file may need to be released for the loop device.
c) the setprop sukernel.mount 1 (in launch_daemonsu.sh) doesn't trigger the mount properly, workaround was to mount it in the launch_daemonsu.sh using "mount -t ext4 -o loop /data/su.img /su" instead of the setprop
Click to expand...
Click to collapse
Any idea why?
I'm specifically using the setprop / init.rc way because mount -o loop doesn't work on many firmwares.
d) the attempted remount read-only, will cause a bootloop; workaround: had to comment that out
Click to expand...
Click to collapse
Where is this?
Chainfire said:
Please do let me know if I can be of further assistance to fix compatibility.
Click to expand...
Click to collapse
Thank you, I will let you know once I've had a chance to properly debug further
I initially only wanted to get systemless root to work, which using the workarounds (even though not ideal), was proof it can be done
(at the time it was SuperSU v2.65)
Chainfire said:
I guess the script can be modified to detect a link and then check if said link is still pointing to /dev/...
Do double symlinks need to be taking into account? i.e. what is a symlink, /dev/block/platform/.../boot, /dev/block/mmcblk0pX, both?
Click to expand...
Click to collapse
No need to take double symlinks into account, only the real one is changed as follows:
the real one is renamed with a "-orig" extension, and a symlink is created to an imaginary normal file:
Code:
cd [B][COLOR="Blue"]/dev/block[/COLOR][/B]
ls -l
...
brw------- 1 root root 259, 24 Jan 12 18:18 mmcblk0p40
brw------- 1 root root 259, 25 Jan 12 18:18 mmcblk0p41
[B]lrwxrwxrwx 1 root root 67 Jan 12 18:19 mmcblk0p42 -> /realdata/media/0/multirom/roms/HTC_One_M8_GPe_Marshmallo1/boot.img[/B]
[B]brw------- 1 root root 259, 26 Jan 12 18:18 mmcblk0p42-orig[/B]
brw------- 1 root root 259, 27 Jan 12 18:18 mmcblk0p43
...
all other symlinks to the block device remain as is:
Code:
cd[B][COLOR="Blue"] /dev/block/platform/msm_sdcc.1/by-name[/COLOR][/B]
ls -l
...
lrwxrwxrwx 1 root root 21 Jan 12 18:18 adsp -> /dev/block/mmcblk0p16
lrwxrwxrwx 1 root root 20 Jan 12 18:18 board_info -> /dev/block/mmcblk0p3
[B]lrwxrwxrwx 1 root root 21 Jan 12 18:18 boot -> /dev/block/mmcblk0p42[/B]
lrwxrwxrwx 1 root root 21 Jan 12 18:18 cache -> /dev/block/mmcblk0p46
...
Chainfire said:
Complete guesswork, but the backing file may need to be released for the loop device.
Click to expand...
Click to collapse
Will check, thanks.
Chainfire said:
Any idea why?
I'm specifically using the setprop / init.rc way because mount -o loop doesn't work on many firmwares.
Click to expand...
Click to collapse
Not really, everything else in init.rc get's executed properly; (and obviously the in launch_daemonsu.sh as well)
Chainfire said:
Where is this?
Click to expand...
Click to collapse
at the beginning of launch_daemonsu.sh:
Code:
if [ ! -d "/su/bin" ]; then
# if we fstab'd system/vendor/oem to rw, remount them ro here
remount_ro /system
remount_ro /vendor
remount_ro /oem
^^ I commented all three of them out, which worked out fine.
MultiROM's secondary ROMs always have system mounted rw, and the above remount_ro will force an immediate reboot
I need to do further testing on these issues, as soon as I come up with something more concrete, I will report back.
EDIT: forgot to mention, can confirm this for the HTC One M7, M8 and M9
garyd9 said:
I'll post a query in the Note 5 section asking people who are running a stock kernel to run similar commands to post the output here: http://forum.xda-developers.com/showpost.php?p=64773152&postcount=138 - I'll relay the results.)
Click to expand...
Click to collapse
So, two replies. I've edited the results to just show the device and value of write_protect. The first one is a KNOX tripped device with completely stock firmware/kernel (no root):
Code:
scsi_disk/0:0:0:0 0
scsi_disk/0:0:0:1 1
scsi_disk/0:0:0:2 1
scsi_disk/0:0:0:3 1
The second is from a stock device where KNOX has never been tripped (the results are expected, but nice for confirmation):
Code:
scsi_disk/0:0:0:0 0
scsi_disk/0:0:0:1 0
scsi_disk/0:0:0:2 0
scsi_disk/0:0:0:3 0
So far, all indications are that the change suggested would work.
Can I have your permission to modify the superSU 2.66 archive to change the deepsleep script to use the script above and forward it to a couple people to validate? (Or, I can just wait until tomorrow night and do it on my own device.)
garyd9 said:
So far, all indications are that the change suggested would work.
Can I have your permission to modify the superSU 2.66 archive to change the deepsleep script to use the script above and forward it to a couple people to validate? (Or, I can just wait until tomorrow night and do it on my own device.)
Click to expand...
Click to collapse
Knock yourself out. I'm not in a rush though. I don't expect to release another update for another few days at least.
Chainfire said:
Code:
for i in `ls /sys/class/scsi_disk/`; do
cat /sys/class/scsi_disk/$i/write_protect 2>/dev/null | grep 1 >/dev/null
if [ $? -eq 0 ]; then
echo 'temporary none' > /sys/class/scsi_disk/$i/cache_type
fi
done
Click to expand...
Click to collapse
Confirmed working for all cache_types 1,2 and 3 but sorry I have patched kernel myself to fix so I have tested reverse just to prevent kernel swap.
Code:
echo 'write back' > /sys/class/scsi_disk/$i/cache_type
and it was write back for all 3. Indeed four including cache_type 0.0.0.0 as well)
So if i had test with
Code:
echo 'temporary none' > /sys/class/scsi_disk/$i/cache_type
then 0000 also get cached right?
It shouldn't be problem right? Just references to this post last line.
Regards
dr.ketan said:
Confirmed working for all cache_types 1,2 and 3 but sorry I have patched kernel myself to fix so I have tested reverse just to prevent kernel swap.
Code:
echo 'write back' > /sys/class/scsi_disk/$i/cache_type
and it was write back for all 3. Indeed four including cache_type 0.0.0.0 as well)
So if i had test with
Code:
echo 'temporary none' > /sys/class/scsi_disk/$i/cache_type
then 0000 also get cached right?
It shouldn't be problem right? Just references to this post last line.
Regards
Click to expand...
Click to collapse
I don't know, since you changed it up, and your statement is a bit confusing.
Try this:
Code:
for i in `ls /sys/class/scsi_disk/`; do
cat /sys/class/scsi_disk/$i/write_protect 2>/dev/null | grep 1 >/dev/null
if [ $? -eq 0 ]; then
echo Write protected: $i
else
echo Write enabled: $i
fi
done
Copy/paste the output.
No problem. I will go to office in couple of hrs. Remove deep sleep fix from kernel and then test script as per said.
dr.ketan said:
No problem. I will go to office in couple of hrs. Remove deep sleep fix from kernel and then test script as per said.
Click to expand...
Click to collapse
That's not needed, just run the other script I pasted above. It'll show what we need to know regardless of your kernel being patched or not.
[email protected]lelte:/ $ su
[email protected]:/ # ls -l /sys/class/scsi_disk/
lrwxrwxrwx root root 2016-01-13 15:35 0:0:0:0 -> ../../devices/15570000.ufs/host0/target0:0:0/0:0:0:0/scsi_disk/0:0:0:0lrwxrwxrwx root root 2016-01-13 15:35 0:0:0:1 -> ../../devices/15570000.ufs/host0/target0:0:0/0:0:0:1/scsi_disk/0:0:0:1lrwxrwxrwx root root 2016-01-13 15:35 0:0:0:2 -> ../../devices/15570000.ufs/host0/target0:0:0/0:0:0:2/scsi_disk/0:0:0:2lrwxrwxrwx root root 2016-01-13 15:35 0:0:0:3 -> ../../devices/15570000.ufs/host0/target0:0:0/0:0:0:3/scsi_disk/0:0:0:[email protected]:/ # cat /sys/class/scsi_disk/*/write_protect
0
1
1
1
[email protected]:/ #
dr.ketan said:
...
Click to expand...
Click to collapse
Seems fine!
I had some time to check a few things, so please find below my findings / possibly solutions
Chainfire said:
a) line 1170: dd if=/dev/zero of=$BOOTIMAGE bs=4096
since MultiROM creates a symlink, the above command actually starts nulling out a "dummy boot.img" file, which basically continues on, untill all free space in internal storage (or external sdcard where applicable) is filled out
Click to expand...
Click to collapse
I guess the script can be modified to detect a link and then check if said link is still pointing to /dev/...
Do double symlinks need to be taking into account? i.e. what is a symlink, /dev/block/platform/.../boot, /dev/block/mmcblk0pX, both?
Click to expand...
Click to collapse
Fixed it by using the following code (perhaps the readlink -f is redundant, but it worked fine)
(at line 1199 of SuperSU 2.66 updater-binary):
Code:
if [ -b `readlink -f $BOOTIMAGE` ]; then
dd if=/dev/zero of=$BOOTIMAGE bs=4096
fi
Chainfire said:
b) when MultiROM-TWRP finishes installing SuperSU, the fake /data is still "busy" (some open file or something else keeping it busy), since it's busy, it can't be unmounted properly, and the real mount points don't get restored
at that point mrom injection will fail
using a lazy unmount helped alleviate that (as a workaround), but obviously not the best solution
Click to expand...
Click to collapse
Complete guesswork, but the backing file may need to be released for the loop device.
Click to expand...
Click to collapse
Turns out the loop device was in fact the problem; after umount /su, it still showed:
Code:
~ # [6n[B]losetup -a[/B]
losetup -a
/dev/block/loop0: 0 /data/su.img
so I just used/added (at line 1218 of SuperSU 2.66 updater-binary)
Code:
umount /su
[B]losetup -d /dev/block/loop0[/B]
I know it was on loop0 so I didnt need to account for anything else, but maybe using
Code:
LOOPDEVICE=`losetup -f`
or something similar, and continuing from there could be an option
Haven't tried checking on the other issues, but will report back when I have something on those
@Chainfire, early results on the deep sleep script change are 100% positive for both the Note5 and the edge+ devices.
nkk71 said:
I had some time to check a few things, so please find below my findings / possibly solutions
Click to expand...
Click to collapse
Thanks for the update. I'll have a look at those commands. losetup -f is specifically not used because I have already encountered devices/recoveries where the built-in losetup does not support this flag. So just loop0 and loop1 are tried, on failure, too bad (guess that could use improvement, hehe). The same goes for the -b test for if, and the -f flag for readlink. While I have not specifically tested the block device test, I know the symlink test fails on some devices. So I need to do some testing.
This is why some things in the ZIP are done is such weird ways instead of just using standard command, they're all work-arounds for encounted recovery versions that didn't support command X or flag Y ...
garyd9 said:
@Chainfire, early results on the deep sleep script change are 100% positive for both the Note5 and the edge+ devices.
Click to expand...
Click to collapse
Good news, as expected.