Related
Since I installed JPK on a test phone after claims that the RFS related lag has been fixed.. well.. I'd like to share my impressions:
- I have installed approx 100 apps after the flash (flashed / wiped / factory reset btw)
A this point, the phone while slightly slower than one with Voodoo is pretty fast
A few days later, it's still good enough.
- 5 days later, lag starts to be felt, and it's stronger every next day until it becomes annoying to use
That's exactly the same experience as I had on various Eclair roms without any lag-fix. I also had this on JP3 (early Froyo).
So yeah. I looked into the /init binary from samsung and it's supposed to make some file system checks from time to time when you restart the phone, but it does not appear to really carry on with that.
So I ran the checks myself:
- you need a rooted phone, and adb or a terminal
- find all RFS partitions:
$ su
# mount|grep -i rfs
- kill all processes, go flight mode and remount them read-only
$ su (if you're not root.. not going to repeat it again for subsequent commands)
# kill -9 <pid> of anything that use the patrition
# mount -oremount,ro /dev/block/....
- check the RFS filesystem and correct errors
# /system/bin/fsck_msdos -p -f /dev/block/....
Surprise, a million of RFS errors fixed such as:
/path/to/file starts with free cluster FIXED
Cluster XXX continues with cluster XXX in FAT 0 but is marked free in FAT 1 FIXED
Detected cluster chain loop head XXXX for p XXXX FIXED
FSNext block XXX is correct NumClusters XXX FIXED (weird one)
No LOST.DIR FIXED
Lost cluster chain at cluster XXX YY clusters lost FIXED (prolly lost files/data here!)
Repeat for each partition
reboot the phone at the end
SURPRISE! It doesn't lag much anymore.
Use the phone an hour, do the check again and you will see it's already full of errors.
Conclusion:
RFS is bugged (we knew that didn't we) but it looks like it's fixable, if ever Samsung figures out what is corrupting the file system exactly (it's closed source so we can't really find out easily)
It might be possible to figure it out by looking at VFAT sources too.
I would be very interested to see if that fixes the lag for everyone or if i'm an isolated case and all my RFS partitions are on bad hardware or if it's really software corruption as I am guessing
Small disclaimer:
im not responsible for any data loss etc. no warranties etc. fixing file system even readonly might cause data loss due to the bugs in RFS. you've been warned lol.
My God,
I think a lot of eyes will be on the BOUNTY
Could someone just create an app that does this?
bilboa1 said:
Since I installed JPK on a test phone after claims that the RFS related lag has been fixed.. well.. I'd like to share my impressions:
- I have installed approx 100 apps after the flash (flashed / wiped / factory reset btw)
A this point, the phone while slightly slower than one with Voodoo is pretty fast
A few days later, it's still good enough.
- 5 days later, lag starts to be felt, and it's stronger every next day until it becomes annoying to use
That's exactly the same experience as I had on various Eclair roms without any lag-fix. I also had this on JP3 (early Froyo).
So yeah. I looked into the /init binary from samsung and it's supposed to make some file system checks from time to time when you restart the phone, but it does not appear to really carry on with that.
So I ran the checks myself:
- you need a rooted phone, and adb or a terminal
- find all RFS partitions:
$ su
# mount|grep -i rfs
- kill all processes, go flight mode and remount them read-only
$ su (if you're not root.. not going to repeat it again for subsequent commands)
# kill -9 <pid> of anything that use the patrition
# mount -oremount,ro /dev/block/....
- check the RFS filesystem and correct errors
# /system/bin/fsck_msdos -p -f /dev/block/....
Surprise, a million of RFS errors fixed such as:
/path/to/file starts with free cluster FIXED
Cluster XXX continues with cluster XXX in FAT 0 but is marked free in FAT 1 FIXED
Detected cluster chain loop head XXXX for p XXXX FIXED
FSNext block XXX is correct NumClusters XXX FIXED (weird one)
No LOST.DIR FIXED
Lost cluster chain at cluster XXX YY clusters lost FIXED (prolly lost files/data here!)
Repeat for each partition
reboot the phone at the end
SURPRISE! It doesn't lag much anymore.
Use the phone an hour, do the check again and you will see it's already full of errors.
Conclusion:
RFS is bugged (we knew that didn't we) but it looks like it's fixable, if ever Samsung figures out what is corrupting the file system exactly (it's closed source so we can't really find out easily)
It might be possible to figure it out by looking at VFAT sources too.
I would be very interested to see if that fixes the lag for everyone or if i'm an isolated case and all my RFS partitions are on bad hardware or if it's really software corruption as I am guessing
Small disclaimer:
im not responsible for any data loss etc. no warranties etc. fixing file system even readonly might cause data loss due to the bugs in RFS. you've been warned lol.
Click to expand...
Click to collapse
VOLD is what does the RFS check at boot. It seems to run, although maybe it fails? It definitely does run though, you can check it running using 'ps' on phone boot. Maybe it's only cleaning up /sdcard though.
At any rate, running the disk check does help with speed, but it doesn't help that much. It's still slow. I think if you want to stick with RFS, you need to do a defrag as well as the filesystem check. After some use, RFS must be very very fragemented on most people's phones.
Even in perfect condition though, RFS still has some very nasty properties such as locking the entire disk when a write occurs, not doing buffering, etc etc.
INeedYourHelp said:
Could someone just create an app that does this?
Click to expand...
Click to collapse
An app can't do this, since the app would have to be running off RFS and would crash/have to be killed to perform the FS checks. It could be done on boot using some trickery and the playlogos / replace binary trick. Or it can be done by replacing the init script with some kernel hackery. But at that point, you might as well just use a real filesystem.
I guess a PC .bat file could be made that uses adb to do this for you and then reboot the phone... Doesn't seem worth the trouble though!
RFS is journelled. You sure the filesystem doesn't do the journaling properly?
Nice job figuring this out. Is someone forwarding all these findings to that Samsung dev?
It's not about RFS vs the other filesystems. I'm well aware of the performance of RFS. But it's decent enough when it's working properly. It's not nearly as fast as ext but fast enough that you don't get annoyed.
Thus fixing RFS would make the life of many people who aren't technically inclined better. If the RFS do get all corrupted everywhere, and Samsung figure that out and fixes it, it means a good thing for most people.
The rest of us will end up on ext anyways
And yeah I think the fscheck at boot fails, it must fail actually, i don't see how else it would happen.
bilboa1 said:
It's not about RFS vs the other filesystems. I'm well aware of the performance of RFS. But it's decent enough when it's working properly. It's not nearly as fast as ext but fast enough that you don't get annoyed.
Thus fixing RFS would make the life of many people who aren't technically inclined better. If the RFS do get all corrupted everywhere, and Samsung figure that out and fixes it, it means a good thing for most people.
The rest of us will end up on ext anyways
And yeah I think the fscheck at boot fails, it must fail actually, i don't see how else it would happen.
Click to expand...
Click to collapse
What firmware did you test on, btw? I've noticed that JPK does seem to take longer on the FS checks, so maybe they have it fixed already (doubt it though)?
RyanZA said:
What firmware did you test on, btw? I've noticed that JPK does seem to take longer on the FS checks, so maybe they have it fixed already (doubt it though)?
Click to expand...
Click to collapse
on JPK actually
im going to flash JM8 to see if its the same in fact, but i expect so
RyanZA said:
VOLD is what does the RFS check at boot. It seems to run, although maybe it fails? It definitely does run though, you can check it running using 'ps' on phone boot. Maybe it's only cleaning up /sdcard though.
Click to expand...
Click to collapse
I think VOLD only does the checks for the Internal SD and External SD, not the RFS partitions.
Interesting find though, about the FS errors.
I’ve been wondering why the lag appears after a couple of days. I suspected corruption in one way or another myself, as it stays after a reboot it could not have been RAM and there are no signs of running out of space. Thanks for your research and I hope it will lead to new fixes. Sad but true my fix is to reflash my phone almost weekly.
I run Doc's JPK super slim ROM which is really nice but still it lags, even with OCLF installed.
Yesterday I take my phone out of my pocket to take a quick photo. My phone wakes up and I sweep the glass. Halfway through the sweeping the animation stops. I wait patiently for a second or three and there my home screen is. (No widgets, no animations, just a single home screen with 12 icons on it of the applications I actually use). I click on the camera icon and I wait another 5 seconds for the camera to realize it is not supposed to sleep on duty. I make a photo, the actual moment is already gone by now but hey I have the thing in my hand. It just takes another 5 seconds to store the photo.
It is like being in a hurry with a toddler with you. You want to go quicker but you can’t get angry cause the little thing just can’t go faster. It has to stop and wonder about life every once in a while.
I like my phone and I am sure it will grow up.
Very interesting findings! Sure hope Samsung sees this or this is forwarded to some Samsung techs.
Maybe move this to the development forum then it might get more traffic from people that can actually help.
borchgrevink said:
Very interesting findings! Sure hope Samsung sees this or this is forwarded to some Samsung techs.
Click to expand...
Click to collapse
do you really think Samsung is reading every thread here on XDA?
Sent from my GT-I9000 using XDA App
matty___ said:
do you really think Samsung is reading every thread here on XDA?
Sent from my GT-I9000 using XDA App
Click to expand...
Click to collapse
No need to be uppity my friend ;-)
Some further info on possible RFS fixes here:
http://forum.xda-developers.com/showpost.php?p=8445244&postcount=143
With the sync issue fixed, and corruption fixed with checks, RFS might just work 'okay'! It won't be as fast as EXT, but it should still work fine if we can sort out all the bugs! And we have a much better chance of getting Samsung to include these fixes in a new firmware too.
If we could get hold of Samsung somehow, and manage to convince them that they should
1) disable the always sync behaviour
2) do full filesystem checks at boot up (or provide a utility to do the checks)
then RFS should be A LOT more usable!
Could someone perhaps turn this into a .bat-file?
RyanZA said:
Some further info on possible RFS fixes here:
http://forum.xda-developers.com/showpost.php?p=8445244&postcount=143
With the sync issue fixed, and corruption fixed with checks, RFS might just work 'okay'! It won't be as fast as EXT, but it should still work fine if we can sort out all the bugs! And we have a much better chance of getting Samsung to include these fixes in a new firmware too.
If we could get hold of Samsung somehow, and manage to convince them that they should
1) disable the always sync behaviour
2) do full filesystem checks at boot up (or provide a utility to do the checks)
then RFS should be A LOT more usable!
Click to expand...
Click to collapse
That quite right, I noticed the sync issue also.
As for the corruption, 2 things should be fixed:
- fsck from init should actually fsck the partitions properly on boot (we can sort of fix that by calling it in a script again)
- corruption should in theory not even happen so Samsung would have to work on RFS for that one
I ran JM8 for 2 days now and my rfs partitions are full of errors, like in JPK, just for confirmation if there needed to be one.
In fact it's still running fsck on /system as I'm writting and issues are filling the terminal .. its been running for 30s already lol
woeds said:
Could someone perhaps turn this into a .bat-file?
Click to expand...
Click to collapse
I haven't tried that but it might be easier to enable adb over usb (in development settings) then .. make sure you are rooted, type that:
> adb shell
$ su
#
<prompt on the phone for root, click allow>
reboot into recovery
> adb shell
$ su
# mount -oremount,ro /dev/block/stl9
# mount -oremount,ro /dev/block/stl10
# mount -oremount,ro /dev/block/stl11
<for safety i'm not including stl3 it's the EFS)
if there's any error due to "filesystem busy" them stop there, it means it doesn't work
otherwise:
#/system/bin/fsck_msdos -p -f /dev/block/stl9
#/system/bin/fsck_msdos -p -f /dev/block/stl10
#/system/bin/fsck_msdos -p -f /dev/block/stl11
# reboot
UPDATE 6-13-2011 !! HUGE UPDATE.... OTG DRIVES NOW SUPPORTED !! https://market.android.com/details?id=com.skidmrk.umswatcherotg
So it's been a long time since i've checked in. This is mostly due to where i was in the development of the new version. I couldn't really work on fixes when i'd rewritten the entire codebase. Well your waiting should be worth the wait. If you have the old version installed from the market you'll have an update waiting. After the update it will tell you there is a new version for Android 3.1 devices. It will take you to the market to download a new app "UMS Watcher OTG" I know this is kinda dumb not currently the android marketplace will not allow for device or os specific version. So i had to make a 2nd app specifically for 3.1 devices. (Since 3.1 is the first build to offically support OTG mode.)(i retained the old version for pre 3.1 devices)
All of the features of the old version should still exist. But now the mounting dialogs are all handled within app. You'll notice this time we actually have a full interface. More than just the simple settings page. UMS mounting should work just fine. Hopefully this will resolve all of the issues people have been having. At least i think it will. If there are still issues i will now be able to work on it since i'm done with the current code.
With the new version installed you'll be greeted with a dialog anytime you plug in a drive via an otg cable. This will then set UMS watcher otg as the default handler for that device. Then any time you plug that device in again it will automatically open the app. This is where you'll really see changes in the app. You will see each of your attached devices enumerated in an expandable list. If you expand any of the drives you'll see the partitions. You can mount and unmount any partition. When mounting you'll be asked the partition type and target mount point. I attempt to auto-detect the partition fs type but i'm not able to differentiate between versions of ext, and between versions of hfs/hfs+. Each partition's settings will be saved. and is keyed to the uuid of the partition. if you format/partition the drive those uuid's change. When finding the mountpoint you can browse the entire file system and even create new directories within app (i can't tell you how much time i spent working out an in app directory browser.) You will also notice partition sizes and disk usage. Note: you won't see disk usage until the partition is mounted (not really an easy way around it). You should be able to have as many simultaneous drives attached, (with as many partitions as you want).
You should know that the fs types are only supported if you're kernel has the modules for them. Tiamat currently has fat/ntfs/ext/hfs/hfs+ modules so all of these should work. The kernel modules will be loaded on demand, so no need to worry about loading them manually.
BIG NOTE:::: HFS+ DOES NOT CURRENTLY WORK.
This appears to be an issue with the kernel module, I'll start working with BRD to get it sorted out.
Checkout the about page to see all of the features.
With this big of a code change there are bound to be bugs. I'll work on them as quickly as posisble, email me or post here when you find any.
This has been a huge amount of work. (lots of learning) The code has gone up in size by almost 2 orders of magnitude. and has been hours and hours of work, so enjoy and if you do a review on the market would be nice. I really didn't anticipate the amount of downloads that i got on V1. >4000 . I also couldn't believe the different types of device, or locales. On that note if anyone wants to help me localize to other languages I'd really appreciate the help. (Google Translate might have to do).
As before any bugs or feature requests can go here or can be emailed to me at apps <at> skidmrk <dot> com . I really hope people like this and use it. (i'd hate to have all the work go out for nothing.)
Thanks to everyone who have helped out so far.
-D
==============================================
UPDATE 5-20-2011 !! TIAMAT UMS KERNEL FOR 3.1 HAS ARRIVED !!
Ok BRD sent me his 3.1 kernel with ums compiled in. I've attached it below.(install via CMR, following the instructions in the tiamat kernel post)
I haven't finished the updates to the app to add ntfs/fat/etc mounting. Things ended up getting a little busy. I should have an update for the app come sunday/monday (going camping for the weekend)
BRD tells me he can't really support the ums stuff any more so i guess i'll take over ums builds (assuming i can figure it all out).
Getting very close to 1000 market downloads. Wow i didn't ever expect that many. I noticed that we have quite a few people with non english locales. Does anyone want to offer translations. I can and will localize (i feel it's important).
Also any requests for the new app version. So far i have a request for unified otg mounting interface. Localization, Kernel Detection and Download. Anything else you'd like to see?
Enjoy the new kernel (and you can thank BRD for it... i didn't really do anything to build it).
Also you don't need to reinstall my app. Once you install the new kernel it will start working again.
=================================================
UPDATE 5-10-2011 !! We're on the market !!
Nothing new yet (waiting on the otg cable) but now you can get the app via the market:
https://market.android.com/details?id=com.skidmrk.umswatcher
Please use this market link for downloads. It will be easier to keep your app updated ... i will however continue post the apks here and use this post to work with users (bug and features).
I haven't had a chance to test this on 3.1 because i've not yet updated... not to mention there isn't a kernel yet for 3.1.
As always feedback is much appreciated.
UPDATE 5-9-2011 NEW VERSION (new features)
Yeah for updates.
I finally figured out how to detect when something mounts the usb mass storage, so now the notification changes depending on the state of the usb mass storage. Finally it has the exact same behavior as android normally has.
I implemented the requested feature of automounting the usb mass storage. I'm not sure how many people would want it but it's there now (and kinda cool)
I've actually hooked in to the private api calls that android uses to mount usb storage (same call used in the native mount app). I figure that is a very safe way to do automounting. (and was a pain in the but to figure out)
Also out of necessity there is now an app you can run. This is just a page for managing settings. It doesn't have to be run for this app to work. Currently there is the "automount" setting and the "show notifications" setting. I figure with the automount feature this might serve useful on other devices for just that function, so those people can disable the notifications. I'll post this on the market as soon as i figure out how. (free of course).
As far as other devices go i tested it on my droid 1 and it works fine (for both notifications and automount). Feel free to test it on whatever you like.
Let me know if there are any other feature you want. I thought able customizing the notification (with sound, led, or vibrate) but that didn't make it in this build.
As before let me know what you think. Feedback can only make this better.
----------
For people still on tiamat 1.4.0 that want to use usb mass storage, have i got an app for you. I found it tedious to use the recommended scripter. So I saw this as an opportunity to write my first albeit basic application.
So attached you'll find it "Usb Mass Storage Watcher". The app listens for usb connections and when it detects one it will add the "mount usb" notification just like the standard android interface. Click on it and it will bring up the mount usb app.
The app does not need to be run at startup or ever really. When it is installed it registers itself as a listener for the usb connection events. It gets called by android os when those event happen. So basically it operates exactly like android is supposed to.
Special thanks to:
Kevin(at)TeslaCoil
LouZiffer(at)SDX
for their ShellCommand (su/sh) class.
Let me know what you think. I'd really like feedback.
-D
Just tested it, works great, thanks a lot.
Is it possible to have an option to turn on mass storage automatically when it finds a connection? I assume it could be ejected from Windows like a regular flash drive, so I wouldn't have to interact with the Xoom.
Thank you for this. It works perfecftly. I stuck with kernel 1.3.2 because I didn't want to deal with the whole script thing. I'm now running 1.40
Sent from my Xoom using Tapatalk
wow that is a nice app....thank you so much
can't open apk -.-
Hi! This is the app I was waiting for (I didn't realy understand the script thing)
Thanks...
Unfortunatly i can't open the apk file... If I try to, I get an Error (just now it in german): "Beim analysieren des Pakets ist ein Problem aufgetreten"
Google Translate : When analyzing the package a problem accured
Have I done anything wrong?
Im rooted, on tiamat 1.4.1 and in options I have checkt hat I can install apks from unknown origine
Did you download directly from your Xoom? If so, try downloading to your computer and copying it over. Either way should work, but it may help.
Thanks! Downloading to Pc and pushing over to xoom worked!
I love this app...
I am having a hard time with this. I installed the file just fine, but when I plug in a usb cable it doesn't do anything on my xoom I the auto play comes up on the computer but it just shows my xoom not the card. I have tiamat 1.4.1 installed. I've tried with USB debugging on as well as off. I have a buddy who's is working perfectly so I know what it should be doing but it's just not. Suggestions?
nevermind I read back through the change log and behold...
Version 1.4.1
Mass Storage has been removed do to stability issues. Your SD Card still works just fine without it!
More updates from Google AOSP.
Please visit Tiamat Xoom Kernel Github Repo for commit history.
so yeah... that's my issue
UPDATES
New Version - New Features - Better implementation
See Post #1
could you add hooks for NTFS mounting VIA OTG Cable........ that would rock!!
pyrator said:
could you add hooks for NTFS mounting VIA OTG Cable........ that would rock!!
Click to expand...
Click to collapse
I've never looked into it but you're talking about mounting an external drive on the xoom (backwards to what my app currently does).
Are you just looking to automount? or do you want an interface like that used for mounting usb mass storage (ie notifications, page to enable/disable).
Technially that would an entirely different app but if i got my hands on an OTG and tested out how it all works i wouldn't mind looking into integrating it. But i just wanted to clarify specifically what you wanted it to do.
-D
For example when you hook up an externel HD via OTG Cable you have to run this command to have it mounted... If your app could automount it that would be a nice addition.
"
Mounting USB disks
use gscript lite to mount disk(s), or you can test this script via adbwireless,...
Code:
mount -o remount,rw /
mkdir /mnt/ntfsdisk
ln -s /mnt/ntfsdisk /ntfsdisk
ntfs-3g /dev/block/sda1 /mnt/ntfsdisk
"
pyrator said:
For example when you hook up an externel HD via OTG Cable you have to run this command to have it mounted... If your app could automount it that would be a nice addition.
"
Mounting USB disks
use gscript lite to mount disk(s), or you can test this script via adbwireless,...
Code:
mount -o remount,rw /
mkdir /mnt/ntfsdisk
ln -s /mnt/ntfsdisk /ntfsdisk
ntfs-3g /dev/block/sda1 /mnt/ntfsdisk
"
Click to expand...
Click to collapse
+1 here
I'd love to see this kind of integration to your app. Don't mind throwing in some kudoes too on the market.
Sent from my Xoom using XDA Premium App
Agreed, the same UI of the mount SD but with the option of mount and unmout USB storage would be cool.
I mentioned this thread yesterday to BRD. I really liked what the 1.4.0 did, but I'm stuck (by choice) to 1.4.1. If he can re-implement the mass storage in the next release with this and what Pyrator mentioned, we will have a very solid update indeed.
1.1 rocks! I love it!
OTG Cable
I'll implement the otg feature if someone can point me in the direction of a cheap otg cable that i can get fast.
Got mine in 2 days
http://www.amazon.com/gp/product/B00474OYLG
siscim23 said:
Got mine in 2 days
http://www.amazon.com/gp/product/B00474OYLG
Click to expand...
Click to collapse
Thanks I'll start adding the feature as soon as mine gets here.
!ALWAYS make a databackup.img on your device BEFORE making any changes!
Hi all!
For the past 3 weeks I have been making small changes to the build prop file inside the Android /system folder.
These changes incorporate not only a increase in speed but also stability.
What I would like to see happen is one of 2 things, or both if possible.
1. Incorporate this build.prop file into the various "System_Froyo" builds available, forcing these changes on initial install, or
2. Vogue/Polaris developers browse the file for contradicting information (things that won't work on a Vogue/Polaris) and make appropriate changes.
Improvements include:
ro.ril.disable.power.collapse (prevents sleep of death),
various dalvik vm improvements,
force hardware acceleration and performance tuning,
various telephony enhancements including ring delay time and data speeds.
After making these changes, the phone rings immediately, the UI is much smoother (GUI uses video processor primarily), and data jumped from 1.3Mb/sec to over 3.2Mb/sec, making web pages load faster. (EDIT: The 3.2Mb/sec is the top of the scale, I actually averaged 2.2Mb/sec with average pings between 300-500 across 3 different radio roms).
VOGUE/POLARIS OWNERS!
Please test this file and report findings here.
IF you find you need to remove any lines, please do so before copying the file into /system. This file works well on the AT&T networks (Cingular), but may not have much effect on other networks.
If you have trouble after installing this file, please post your bootlog file.
PoX
So may I know what rom support this?
This has only been tested on a "clean" Froyo build, so I cannot make any assumptions as to if it will work in Gingerbread/Eclair/Donut/etc.
If everyone follows the install guide on the front page, I would assume that it would work worldwide, as long as it's Froyo.
In the future I could try it out on Gingerbread and other builds, but I make no promises as development has all but ended for Android on MSM72**.
I can test this. Perhaps, kaiser on Android could be good for daily use?...
Thanks for sharing
PoXFreak said:
Hi all!
For the past 2 weeks I have been making small changes to the build prop file inside the Android /system folder.
These changes incorporate not only a increase in speed but also stability.
What I would like to see happen is one of 2 things, or both if possible.
1. Incorporate this build.prop file into the various "System_Froyo" builds available, forcing these changes on initial install, or
2. Vogue/Polaris developers browse the file for contradicting information (things that won't work on a Vogue/Polaris) and make appropriate changes.
Improvements include:
ro.ril.disable.power.collapse (prevents sleep of death),
various dalvik vm improvements,
force hardware acceleration and performance tuning,
various telephony enhancements including ring delay time and data speeds.
After making these changes, the phone rings immediately, the UI is much smoother (GUI uses video processor primarily), and data jumped from 1.3Mb/sec to over 3.2Mb/sec, making web pages load faster.
If there is interest in this, please respond to this post. If there is enough interest I will attach it to this post as a .tar file.
Click to expand...
Click to collapse
PoXFreak said:
This has only been tested on a "clean" Froyo build, so I cannot make any assumptions as to if it will work in Gingerbread/Eclair/Donut/etc.
If everyone follows the install guide on the front page, I would assume that it would work worldwide, as long as it's Froyo.
In the future I could try it out on Gingerbread and other builds, but I make no promises as development has all but ended for Android on MSM72k.
Click to expand...
Click to collapse
I'm interested in your new build.prop tar, but I do not understand the thing about the install guide, you mentioned in you second post.
My Kaiser is running CM7 RC3 on haret, so maybe I can do some testing on gingerbread, with you.
Your trials, about tweaking the app download possibility, sound very interesting too, as I read about a tweaked build.prop for a tab that simulates to be a samsung tab in combination with an older version of the app market.
Feel free to PM, although I'm quite a newby to android.
I can build with Fresh Froyo and try it, but not until April sorry.
I am currently traveling and away from a development system.
I have been slowly trying to get a reliable app2sd capability working.
I'd suggest searching old posts for power collapse to see if dzo or others long ago tried this.
It sounds promising.
muckelmaus said:
I'm interested in your new build.prop tar, but I do not understand the thing about the install guide, you mentioned in you second post.
My Kaiser is running CM7 RC3 on haret, so maybe I can do some testing on gingerbread, with you.
Your trials, about tweaking the app download possibility, sound very interesting too, as I read about a tweaked build.prop for a tab that simulates to be a samsung tab in combination with an older version of the app market.
Feel free to PM, although I'm quite a newby to android.
Click to expand...
Click to collapse
The "install guide" I'm referring to is here...
How to replace Windows Mobile with Android (Guide)
There would be a change to the original build.prop file which exists inside the /system folder and would be installed when Android is installed on the Kaiser.
Mind you, I live in a busy city with LOTS of cell towers and, since 3g works on the principle of multi-tower usage, YMMV. If you live way out in the country with maybe 2-3 towers nearby, this may not help you.
Also, this has been tested on a NAND-installed OS, not a HaRet install. I cannot verify or guarantee this will work with a HaReT install as I have no way to test it and I think of HaReT as the "slow cousin" to a NAND install.
On a side note: My Kaiser has not had one sleep of death, hard-lock, white screen or even an FC for 9 days now. Apps running out of memory can be a slight problem but they will just close on their own as opposed to FC-ing. at worst I've had one hot reboot called by the system, and the FCs' are few, even with heavy Facebook and Maps use.
n2, if this works on all Kaisers, is there a way to push it to SF and either add it as a mod or rebuild the "system_froyo" install files and incorporate it within?
I will try in early April. Until then please solicit Vogue and Polaris users to try it.
Sent from my Nexus One using XDA
I am interested and willing to try this out!
Where is your " "Fixed" build.prop file for Kaiser "?
Tarball added to OP, please test and report back. Any problems should be reported here along with the bootlog from your phone.
Hi guys!
Problem occured when moving file to root folder. To solve I tried root explorer and z4root both. CM7 + Krazy-Killa's Kernel on tilt 8925.
Please talk what to do with it!
thanks!
Rename original build.prop file to "build.prop.old" or something you will remember, without the quotes, then paste the new build.prop file into the /system folder... it should go right in with no errors, unless you try it without read/write abilities.
CM7 may already have some of these fixes installed in the existing build.prop file. To check, open this build.prop with a text editor and check the entries under "additional build properties".
n2rjt said:
I will try in early April. Until then please solicit Vogue and Polaris users to try it.
Sent from my Nexus One using XDA
Click to expand...
Click to collapse
Vogue/Polaris users solicited, although I'm not sure if this can be used on a CDMA network. Last count shows about 15-20% of the "other" phones were Vogues, the rest were Polaris users.
It would be nice to start getting good feedback since this would be my first actual "hard" mod (one that is installed with the system, not modded through some other installer/program).
PoXFreak said:
Rename original build.prop file to "build.prop.old" or something you will remember, without the quotes, then paste the new build.prop file into the /system folder... it should go right in with no errors, unless you try it without read/write abilities.
CM7 may already have some of these fixes installed in the existing build.prop file. To check, open this build.prop with a text editor and check the entries under "additional build properties".
Click to expand...
Click to collapse
Can't rename. And can't change file attributions read only to read/write.
ZLodei said:
Can't rename. And can't change file attributions read only to read/write.
Click to expand...
Click to collapse
You probably need to remount /system read/write. I just wish I could remember how. Been a long time since I put my vogue down.
If you can get terminal emulator up on that phone, I believe all you would have to do is type in "su" then "mount /system".
All Kaiser/Polaris/Vogue Android builds are rooted and usually have superuser installed. I will take a look into Scoot's CM7 and confirm this. I know there is an update to superuser that leaves the old binary unable to be updated.
PoXFreak said:
If you can get terminal emulator up on that phone, I believe all you would have to do is type in "su" then "mount /system".
All Kaiser/Polaris/Vogue Android builds are rooted and usually have superuser installed. I will take a look into Scoot's CM7 and confirm this. I know there is an update to superuser that leaves the old binary unable to be updated.
Click to expand...
Click to collapse
Hi! Thank you!
What does exactly I have to do in terminal emulator?
I would hope you have superuser capability, if you don't then use another build that does have them...
Anyway, this is all I could figure out to remount the /system as RW. Type the following below into terminal emulator...
mount -o rw,remount -t yaffs2 /dev/block/mtdblock2 /system
(Where "mtdblock2" has /system, "mtdblock3" has /data, and "mtdblock4" has /cache.)
Hope this helps...
Please correct me if i'm wrong.
I installed this new build.prop from the bootloader using androidupdate.tar.
Because i made a tar archive this way: system/build.prop
Isn't it the easiest method? No mounting and hacking in terminal emulator.
Anyway, do anybody know which ROM contains hungarian language? I gave my Kaiser to my father and it would be great if he could use it in hungarian.
I thought VaniljEclair 11 has it, and it is almost true. It has hungarian language but when i set it nothing happens. Everything is in english as before.
Thanks!
Edit:
You can download it from here:
http://mattempus.sohasenem.hu/pub/androidupdate.tar
I bought my phone about a week ago, and I noticed it was pretty slow after installing some apps, even slower than my previous Nexus S.
I changed my phone from yakjuxw to yakju yesterday, and updated to 4.2. I even did a factory reset after everything was done.
It was the same, it started pretty fast but as I ran the apps from the backup I had made the phone started to slow down.
I still haven't managed to find which app is causing me problems, so I was hoping someone here could help...
Did you use Titantium Backup for apps?
As far as I know, it is recommended not to restore all apps via Titantium Backup but only the ones that have some data associated to them like games with their saves. So try installing a fresh 4.2 ROM, only restore the apps that needs their data, and download the others via Play Store
I hope you can either avoid the lag this way or at least spot the app causing it
ahmadallica said:
Did you use Titantium Backup for apps?
As far as I know, it is recommended not to restore all apps via Titantium Backup but only the ones that have some data associated to them like games with their saves. So try installing a fresh 4.2 ROM, only restore the apps that needs their data, and download the others via Play Store
I hope you can either avoid the lag this way or at least spot the app causing it
Click to expand...
Click to collapse
No, I restored it through the Nexus Toolkit (the GUI version).
I only restored normal apps and none of the system apps or data. And this has been on absolutely stock Google ROMs ever since I bought the phone.
KaiZ51 said:
I bought my phone about a week ago, and I noticed it was pretty slow after installing some apps, even slower than my previous Nexus S.
I changed my phone from yakjuxw to yakju yesterday, and updated to 4.2. I even did a factory reset after everything was done.
It was the same, it started pretty fast but as I ran the apps from the backup I had made the phone started to slow down.
I still haven't managed to find which app is causing me problems, so I was hoping someone here could help...
Click to expand...
Click to collapse
That happens when you restore rom essential apps...you only need to restore the apps you downloaded.
Sent from my Galaxy Nexus using xda premium
Maybe you have the eMMC bug/issue which may occur if your phone was produced 08/2012.
To check this install the "eMMC Brickbug Check" tool and verify if your if chip type is V3U00M and date 08/2012.
https://play.google.com/store/apps/details?id=net.vinagre.android.emmc_check
If yes check this link for a workaround for this annoying bug:
http://forum.xda-developers.com/showpost.php?p=35020486&postcount=10
KaiZ51 said:
No, I restored it through the Nexus Toolkit (the GUI version).
I only restored normal apps and none of the system apps or data. And this has been on absolutely stock Google ROMs ever since I bought the phone.
Click to expand...
Click to collapse
try to flash the image again and dont restore this time... see if that fixes your issue
navien said:
Maybe you have the eMMC bug/issue which may occur if your phone was produced 08/2012.
To check this install the "eMMC Brickbug Check" tool and verify if your if chip type is V3U00M and date 08/2012.
https://play.google.com/store/apps/details?id=net.vinagre.android.emmc_check
If yes check this link for a workaround for this annoying bug:
http://forum.xda-developers.com/showpost.php?p=35020486&postcount=10
Click to expand...
Click to collapse
Well, I've just checked it, and it seems like my phone falls within the parameters for this bug... The only difference is the date is 09/2012. But is there a way to know for sure that I'm affected by this bug? Besides, I'm going to have to root the phone, which is going to be a bit annoying since I really didn't want to do it because I may have problems with the warranty in case I need to return it...
Also, if I flash a custom ROM in the future, will I have to do that again, or do custom ROMs usually come with that fix?
k786 said:
try to flash the image again and dont restore this time... see if that fixes your issue
Click to expand...
Click to collapse
I was thinking of trying that as well, though it may be annoying because I'll lose my data... But if I have to I guess I really don't have a choice...
KaiZ51 said:
I was thinking of trying that as well, though it may be annoying because I'll lose my data... But if I have to I guess I really don't have a choice...
Click to expand...
Click to collapse
delete the userdata from the image and it wont wipe your internal storage
KaiZ51 said:
Well, I've just checked it, and it seems like my phone falls within the parameters for this bug... The only difference is the date is 09/2012. But is there a way to know for sure that I'm affected by this bug? Besides, I'm going to have to root the phone, which is going to be a bit annoying since I really didn't want to do it because I may have problems with the warranty in case I need to return it...
Also, if I flash a custom ROM in the future, will I have to do that again, or do custom ROMs usually come with that fix?
Click to expand...
Click to collapse
All people reported this bug (at least what i´ve found) have production date of 08/2012 - maybe this bug also affects newer models.
I think if your chip type is V3U00M then your'e phone is affected. But your can test this easily. Just copy a huge file (i've copied 1 hd movie ~11GB) to the internal storage. The phone should slow down extremely, even if you delete the file again. For example: my phone needed 4-6 seconds to open the contacts app - sometimes even more.
Rooting is no big issue - you can easily revert to stock image.
If you flash a ROM you will to have implement the workaround again. Custom ROMs will not include this fix in general because if you remount the data partition with the discard option on an eMMC other than V3U00M your phone will be hard bricked.
navien said:
All people reported this bug (at least what i´ve found) have production date of 08/2012 - maybe this bug also affects newer models.
I think if your chip type is V3U00M then your'e phone is affected. But your can test this easily. Just copy a huge file (i've copied 1 hd movie ~11GB) to the internal storage. The phone should slow down extremely, even if you delete the file again. For example: my phone needed 4-6 seconds to open the contacts app - sometimes even more.
Rooting is no big issue - you can easily revert to stock image.
If you flash a ROM you will to have implement the workaround again. Custom ROMs will not include this fix in general because if you remount the data partition with the discard option on an eMMC other than V3U00M your phone will be hard bricked.
Click to expand...
Click to collapse
So, I went ahead and followed the instructions on the link you gave me... And it seems to be much better so far I still haven't tested enough, but I think the problem is pretty much fixed. I just have a few more questions if you don't mind...
1- When I ran the dd command, it took a while like the instructions said, but when it finished it said something about not enough space. Could something have gone wrong, or is this normal?
2- Since it isn't likely custom ROMs implement this fix, is there any way I can "stick" this fix on the phone's system so that I don't have to worry about setting it every time I flash a new ROM?
3- Is there any way to make sure that the script I set up in Script Manager is fully working and running on boot?
KaiZ51 said:
So, I went ahead and followed the instructions on the link you gave me... And it seems to be much better so far I still haven't tested enough, but I think the problem is pretty much fixed. I just have a few more questions if you don't mind...
1- When I ran the dd command, it took a while like the instructions said, but when it finished it said something about not enough space. Could something have gone wrong, or is this normal?
2- Since it isn't likely custom ROMs implement this fix, is there any way I can "stick" this fix on the phone's system so that I don't have to worry about setting it every time I flash a new ROM?
3- Is there any way to make sure that the script I set up in Script Manager is fully working and running on boot?
Click to expand...
Click to collapse
Bumping...
KaiZ51 said:
So, I went ahead and followed the instructions on the link you gave me... And it seems to be much better so far I still haven't tested enough, but I think the problem is pretty much fixed. I just have a few more questions if you don't mind...
1- When I ran the dd command, it took a while like the instructions said, but when it finished it said something about not enough space. Could something have gone wrong, or is this normal?
2- Since it isn't likely custom ROMs implement this fix, is there any way I can "stick" this fix on the phone's system so that I don't have to worry about setting it every time I flash a new ROM?
3- Is there any way to make sure that the script I set up in Script Manager is fully working and running on boot?
Click to expand...
Click to collapse
The dd command fills the entire partition till full, therefore the not enough space message is normal.
I´ve not tested how to implemt this fix in a ROM before flashing.
In theory you only need to add the file with the script into the init.d folder of the zip before flashing.
I´ve made IO Benchmarks with AndroBench to check if the script works:
with enabled script i get for example RND WR ~135 IOPS without script 54 IOPS.
navien said:
The dd command fills the entire partition till full, therefore the not enough space message is normal.
I´ve not tested how to implemt this fix in a ROM before flashing.
In theory you only need to add the file with the script into the init.d folder of the zip before flashing.
I´ve made IO Benchmarks with AndroBench to check if the script works:
with enabled script i get for example RND WR ~135 IOPS without script 54 IOPS.
Click to expand...
Click to collapse
Apparently it isn't running, since I get my Random Write score in the 30's IOPS. Besides that, I made Script Manager output logs, and it seems like it says it could not mount.
So what can I do? I'm not sure if I've already said this, but I'm on the stock 4.2.1 yakju ROM, if it matters. I could do this the init.d way, but I'm not sure if it works fine on stock ROM...
Also, something I haven't yet understood, is the dd command for checking if the fix works temporarily, or do you really need to do it in order to prepare the phone for the script?
And do you need to have as much empty space as possible before running the command, or you don't need to care about that?
Sorry about all the trouble with this problem, it's just as you probably know the phone is barely usable with this bug so I have no choice but to ask for help... Google should really fix this in an update, it's something pretty urgent in my opinion.
KaiZ51 said:
Apparently it isn't running, since I get my Random Write score in the 30's IOPS. Besides that, I made Script Manager output logs, and it seems like it says it could not mount.
So what can I do? I'm not sure if I've already said this, but I'm on the stock 4.2.1 yakju ROM, if it matters. I could do this the init.d way, but I'm not sure if it works fine on stock ROM...
Also, something I haven't yet understood, is the dd command for checking if the fix works temporarily, or do you really need to do it in order to prepare the phone for the script?
And do you need to have as much empty space as possible before running the command, or you don't need to care about that?
Sorry about all the trouble with this problem, it's just as you probably know the phone is barely usable with this bug so I have no choice but to ask for help... Google should really fix this in an update, it's something pretty urgent in my opinion.
Click to expand...
Click to collapse
Oh, and do you think I should go to the store to replace my phone? I still haven't understood if this is a software or hardware issue, but I'm believing it's the first...
KaiZ51 said:
Apparently it isn't running, since I get my Random Write score in the 30's IOPS. Besides that, I made Script Manager output logs, and it seems like it says it could not mount.
So what can I do? I'm not sure if I've already said this, but I'm on the stock 4.2.1 yakju ROM, if it matters. I could do this the init.d way, but I'm not sure if it works fine on stock ROM...
Also, something I haven't yet understood, is the dd command for checking if the fix works temporarily, or do you really need to do it in order to prepare the phone for the script?
And do you need to have as much empty space as possible before running the command, or you don't need to care about that?
Sorry about all the trouble with this problem, it's just as you probably know the phone is barely usable with this bug so I have no choice but to ask for help... Google should really fix this in an update, it's something pretty urgent in my opinion.
Click to expand...
Click to collapse
OK. The workaround with the script needs a ROM with init.d support. I thought this was mentioned in the linked thread.
I´m using THIS one.
The real fix is the re-mounting of the /data & /cache partitions using the discard option. If you type the command in a terminal window it fixes the problem temporary.
After reboot the problem is back. So you need to make a init.d script which will be executed every boot.
I think the dd command 'cleans' the free memory but i'm not sure.
To my opinion it doesn't make any sense to replace the phone because there's a big chance to get a new one with same problem.
So it is a software bug which should be solved by google.
navien said:
OK. The workaround with the script needs a ROM with init.d support. I thought this was mentioned in the linked thread.
I´m using THIS one.
The real fix is the re-mounting of the /data & /cache partitions using the discard option. If you type the command in a terminal window it fixes the problem temporary.
After reboot the problem is back. So you need to make a init.d script which will be executed every boot.
I think the dd command 'cleans' the free memory but i'm not sure.
To my opinion it doesn't make any sense to replace the phone because there's a big chance to get a new one with same problem.
So it is a software bug which should be solved by google.
Click to expand...
Click to collapse
Hmm I see... But from what I understood, you can make the script run at boot with apps like ROM Toolbox and Script Manager, correct? Although I'm not sure if it's running on my system, I've tried both apps and the benchmarks are always in the 30's...
Or do you really need a ROM with init.d support? Also I have BusyBox installed on Google's stock ROM, not sure if that is enough to able to run init.d scripts.
But how would you run scripts with init.d? Sorry, I'm a noob to this kind of stuff, I never did stuff like this...
KaiZ51 said:
Well, I've just checked it, and it seems like my phone falls within the parameters for this bug... The only difference is the date is 09/2012.
Click to expand...
Click to collapse
Thank you for confirming chips produced 09/2012 as bad. Added this to the post linked above.
KaiZ51 said:
When I ran the dd command, it took a while like the instructions said, but when it finished it said something about not enough space. Could something have gone wrong, or is this normal?
Click to expand...
Click to collapse
This is normal as we don't give the dd command a particular file size to create. So it simply writes data until no space is left.
KaiZ51 said:
Since it isn't likely custom ROMs implement this fix, is there any way I can "stick" this fix on the phone's system so that I don't have to worry about setting it every time I flash a new ROM?
Click to expand...
Click to collapse
If you are only using ROMs that support something like init.d inside data (like CM), next time to worry about this will be when you do a full wipe.
Probably then the problem will already be fixed by Google or others as it gains more attention over time.
KaiZ51 said:
Is there any way to make sure that the script I set up in Script Manager is fully working and running on boot?
Click to expand...
Click to collapse
Jup. Type 'mount' in Terminal or adb after you rebooted your phone:
# mount
[...]
/dev/block/platform/omap/omap_hsmmc.0/by-name/userdata /data ext4 rw,noatime,errors=panic,barrier=1,nomblk_io_submit,data=ordered,noauto_da_alloc,discard 0 0
[...]
Click to expand...
Click to collapse
=> discard option added, script ran successfully
KaiZ51 said:
Apparently it isn't running, since I get my Random Write score in the 30's IOPS. Besides that, I made Script Manager output logs, and it seems like it says it could not mount.
Click to expand...
Click to collapse
Maybe you have to check something like 'run as root' or similar in Script Manager.
KaiZ51 said:
So what can I do? I'm not sure if I've already said this, but I'm on the stock 4.2.1 yakju ROM, if it matters. I could do this the init.d way, but I'm not sure if it works fine on stock ROM...
Click to expand...
Click to collapse
Nope. Stock does not support init.d.
KaiZ51 said:
Also, something I haven't yet understood, is the dd command for checking if the fix works temporarily, or do you really need to do it in order to prepare the phone for the script?
Click to expand...
Click to collapse
You can use the script without. The phone will speed up over time as more and more data is written/deleted and therefore the eMMC chip gets some discard commands.
The dd + rm just speeds up the process as all free blocks will be told to the eMMC chip due to the discard option added beforehand.
Another possibility (after installing the script and confirming that it works) would be to copy a large file that fills almost all space on the phone and remove it afterwards. The dd command is just considerably faster.
KaiZ51 said:
And do you need to have as much empty space as possible before running the command, or you don't need to care about that?
Click to expand...
Click to collapse
You don't need to care. Just keep around 1,0-1,5 GiB of free space everytime: Benchmark
KaiZ51 said:
Oh, and do you think I should go to the store to replace my phone? I still haven't understood if this is a software or hardware issue, but I'm believing it's the first...
Click to expand...
Click to collapse
Well, you might get a replacement phone and through bringing it back the chance that Google gets aware of the problem may be higher.
But possibly they will only wipe all data which makes the phone fast again for some time and tell you there is nothing wrong with it...
You may even think about it from this point of view: If the fix works for you, you have a phone with a blazingly fast eMMC chip, faster than any GNex produced before 08/2012 (until you have less than 1 GiB of free space on /data)
KaiZ51 said:
Google should really fix this in an update, it's something pretty urgent in my opinion.
Click to expand...
Click to collapse
+1
ph4zrd said:
Thank you for confirming chips produced 09/2012 as bad. Added this to the post linked above.
This is normal as we don't give the dd command a particular file size to create. So it simply writes data until no space is left.
If you are only using ROMs that support something like init.d inside data (like CM), next time to worry about this will be when you do a full wipe.
Probably then the problem will already be fixed by Google or others as it gains more attention over time.
Jup. Type 'mount' in Terminal or adb after you rebooted your phone:
=> discard option added, script ran successfully
Maybe you have to check something like 'run as root' or similar in Script Manager.
Nope. Stock does not support init.d.
You can use the script without. The phone will speed up over time as more and more data is written/deleted and therefore the eMMC chip gets some discard commands.
The dd + rm just speeds up the process as all free blocks will be told to the eMMC chip due to the discard option added beforehand.
Another possibility (after installing the script and confirming that it works) would be to copy a large file that fills almost all space on the phone and remove it afterwards. The dd command is just considerably faster.
You don't need to care. Just keep around 1,0-1,5 GiB of free space everytime: Benchmark
Well, you might get a replacement phone and through bringing it back the chance that Google gets aware of the problem may be higher.
But possibly they will only wipe all data which makes the phone fast again for some time and tell you there is nothing wrong with it...
You may even think about it from this point of view: If the fix works for you, you have a phone with a blazingly fast eMMC chip, faster than any GNex produced before 08/2012 (until you have less than 1 GiB of free space on /data)
+1
Click to expand...
Click to collapse
Thanks, that cleared a lot of questions.
So, after having tested the phone some more time (and I do have discard enabled at boot after all), the phone still seems pretty slow to me.
Yesterday I did the discard command with the adb shell, and then rebooted with the discard script enabled, but it's still pretty slow...
I've also benchmarked the phone in AndroBench a few times after this and Random Write scores ranged from as low as 6 (yes, six) IOPS, to 60's IOPS.
Still, this isn't that good since it seems like normal scores are in the 100's.
I really don't know what I should do now... Maybe the eMMC chip isn't actually the problem? But I find that rather strange since I don't think I have any apps that I already didn't have on my old Nexus S, and the phone does seem slower than my old one.
KaiZ51 said:
I really don't know what I should do now... Maybe the eMMC chip isn't actually the problem? But I find that rather strange since I don't think I have any apps that I already didn't have on my old Nexus S, and the phone does seem slower than my old one.
Click to expand...
Click to collapse
How much free space do you have left on /data or /sdcard?
And you used the dd-rm-combination after remounting with discard, right?
ph4zrd said:
How much free space do you have left on /data or /sdcard?
And you used the dd-rm-combination after remounting with discard, right?
Click to expand...
Click to collapse
I have 1.71GB free now.
And what do you mean about your second question? If you're asking if I used those commands when I connected the phone to my PC via USB Debugging, then yes.
If you're talking about the script that runs at boot, all I have in that script is
Code:
#!/system/bin/sh
mount -o remount,discard /data
mount -o remount,discard /cache
Should I put the script like this?
Code:
#!/system/bin/sh
mount -o remount,discard /data
mount -o remount,discard /cache
dd if=/dev/zero of=/data/tmp.bin
rm /data/tmp.bin
I didn't put them there since I thought the dd and rm commands were only meant to be run when connected via USB and not at boot as well...
Alright, I'm running CyanogenMod 11 with TWRP as my recovery. When I try to change my build.prop it tells me that the action is not allowed because the system folder is mounted as Read only and not as R/W. I have tried using the chmod syntax 755 while in recovery but, after rebooting nothing has changed. Using my file manager (Solid Explorer) I have tried changing the permissions to be R/W by using the same chmod syntax. What have I done or am I doing wrong? I have never crossed this issue before with any other ROM or phone and I would like to add some additional speed and smoothness tweaks to the ROM build.prop. Have I tried another ROM to see if the same thing continues to happen? Nope, I sure haven't. If I did though and something magically changes to where it would begin working using another ROM, I still would not know how to fix the issue that I'm faced with now. Will ya please help? Thank you for your time in advance as well!
The drive isn't being mounted by solid Explorer as read/write. I'm not familiar with the app so can't explain how to do it but it may be in the options somewhere or a button on the screen.
You could try es file Explorer. It's free and works for me.
-> Sent from my mind to your screen.
Give a man a fish and you feed him for a day. Teach a man to fish and you feed him for a lifetime.
Well, I just tried ES File Explorer and it said that I'm mounted as R/W on my system folder, same as it did on Solid Explorer, yet once I try to alter anything I still receive the same "Operation Failed......System Mounted as Read Only" message. I have even switched ROM's to see if maybe, just maybe, it was some sort of CM 11 bug. Everywhere I look online says to correct it through my recovery and since that doesn't work..........? I'm at a bit of a loss now! I have granted both file managers Superuser rights. Hell my Superuser auto-response is always set to grant all apps that permission. And as far as the form of Superuser I'm using goes, I'm just sticking with the CM stock Superuser because whenever I attempt to use SuperSU all sorts of stuff begins to fail.
Is your SD card formatted as FAT32....or EXFAT...???
Needs a possible format again it sounds like....IMHO..g
Sent from my NOTE 2.750...
Courtesy of our amazing developers...
Haven't thought about it possibly being my SD's format being that I am trying to access my systems files (i.e.- build.prop, system apps, etc.) and not the external SD Card, but what the hell?! I reckon I can always give it a shot. Could very well be that simple since I just dropped $100.00 on a stupid Lexar 64 Gig. Micro SD about the same time this issue arose. Hope so even if i do end up feeling like a dumb ass later on. It's getting annoying! I've tried several different ROM's, file managers, running syntax in the emulator, and anything else I could dig up now and this isn't quite my first Android experience, still relatively new though, so I know I'm not flashing anything wrong or outta the ordinary. Give me bit to take care of some every day life crap and I'll report my findings back to ya.
Dead serious, I did not do anything different whatsoever and it began to allow me to change permissions on my system files or whatever else I wished to do to it......?! No Earthly idea what was/did go on for it not to allow me to for the time it didn't, but outta nowhere, as I said, it is working again. I did wipe and flash numerous ROM's without any luck and even had flashed the one that it is working on now, but it didn't work the first or second time I flashed it. Never even got the chance to reformat my SD Card. Hell, I don't know.....!
countryboy092782 said:
Dead serious, I did not do anything different whatsoever and it began to allow me to change permissions on my system files or whatever else I wished to do to it......?! No Earthly idea what was/did go on for it not to allow me to for the time it didn't, but outta nowhere, as I said, it is working again. I did wipe and flash numerous ROM's without any luck and even had flashed the one that it is working on now, but it didn't work the first or second time I flashed it. Never even got the chance to reformat my SD Card. Hell, I don't know.....!
Click to expand...
Click to collapse
Running Jellywiz Extreme Rom 4.3 for my Note 2 on Verizon, and ever since i updated it to 4.3 on an unstable original ROM (Davidson3680's OG 4.3 ROM pre-2014), i havent been able to mount system as R/W.
I keep coming back to the possibility that in both of these recent cases that the file structure is somehow corrupted...
A possible 4.3 return to stock using Zen Arcades 4.3 stock rom may correct the file issues and restore the external functionality...
I'm still perplexed about the differences in flashing success based on whether or not a user has taken an official 4.3 update versus a user who has not...and the variables in function using the exact same software's...
The Zen thread method seems to be the stable and reliable way back to full function...or at least the best way to build the file structures back within their respective partitions...
We are playing very near the partition level...but I don't think it's a partition/pit issue....rather the broken file structure inside...
I'd be interested in the results of that test using Zen's files in the attempt to repair the files...and path to the SD...
If you are willing to try that...and meet success...it would solve a good half dozen device issues across different users in one pass....g
Sent from my NOTE 2.750...
Courtesy of our amazing developers...