Develop Bugs

[Q] Why even after a full wipe does it say I have low memory....

So I had rooted my Htc Evo 4g and I would try new ROM's maybe once a week or so... And than I flash a ROM and go to install some apps and I get a low memory warning. I used to have that problem with my Hero. I did the full wipe (everything 3x) and I was wondering why I would be low on memory after clearing everything? Is there something I'm missing, lol?!!

Are you using A2SD with an ext partition? And if so, are you wiping EXT as well? I know you said everything, just checking.

I have never had that problem, and I regularly have around 100 or so apps on my phone.
What roms are you trying? I have tried most roms on here, and almost all of them actually use LESS space then the stock rom, as they get rid of things you dont need.

Bad clusters?? Look at the recovery.log after a wipe

bkrodgers said:
Are you using A2SD with an ext partition? And if so, are you wiping EXT as well? I know you said everything, just checking.
Click to expand...
Click to collapse
Lol... Actually I've never wiped that but I don't use the A2SD or anything so it never crossed my mind...

gpz1100 said:
Bad clusters?? Look at the recovery.log after a wipe
Click to expand...
Click to collapse
What is and how do I check the recovery log? Sorry for the newb question, you'd think I'd know by now, lol!!!

By bad clusters I assume he means bad blocks. It sounds like parts of your memory have become damaged simply through normal use, its inevitable in all solid state memories. Supposedly some evos have been shipped with defects that cause lots of bad blocks. If your hardware version is 0003 or lower there's a chance yours was one.

Davidsr1127 said:
What is and how do I check the recovery log? Sorry for the newb question, you'd think I'd know by now, lol!!!
Click to expand...
Click to collapse
Recovery.log is generated at /tmp/recovery.log whenever you do something in recovery. In recovery, if you go to advanced and then select report error it will copy that file to /sdcard/clockworkmod/recovery.log.
I doubt you'll find anything about bad blocks in that file. I just generated one and looked through it and the only thing about blocks that it says is "successfully wrote to block 0", which is just one block out of thousands. Its mostly technical things like what version of recovery you have, what radio your using things like that. It wouldn't hurt to look through it though. Some of it wont make sense, some will. Just look through line by line, it'll take like 5 minutes.

Davidsr1127 said:
What is and how do I check the recovery log? Sorry for the newb question, you'd think I'd know by now, lol!!!
Click to expand...
Click to collapse
Yes, I did mean bad blocks, but had sectors and clusters on the mind
Type the following from a dos prompt in the folder containing adb
adb shell
df
Paste the results into a reply. This will show us just how much free space you have and where.

[IDEA] Android rescue.zip project..

So i am here with a new idea. A rescue.zip which can be used to rescue any android device which have a recovery like the famous cwm.
So here is it..
Some times we people screw up our android os like hell, and to reboot the device we usualy do a recovery flash of a new os, flash back our nandroid backup ( both on worst conditions) or even do permission fix, clean cache or dalvic cache( those in 'not that worse' conditions) . So thats are all the options we got. Rit?
Although flashing recovery backups, new roms can fix all, it will also eatup our apps, current setups, contacts, msgs, etc( in case we dont have backups) and will probably screw us. All we can do is say " WTF..WTF..WTF.."
SO here is my idea,
Find out the causes of what causes a reboot, non-boot, hang,fc etc.
And keep a zip that can be flashed through recovery, that has a solution for our problem. They may be including..
1) fix permission of system, data, and user data.
2) zipalign the apps
3) fix the default clock speed of processor
4) defragment memory
5) flash a new copy of su and busy box
6)wipe data or system or ext or cache or dalvic cache
7) flash a new copy of framework.res, system-ui.apk, settings.apk with default permissions( those files are kept in separate "custom" folder on the zip, so that end user can put their own files to that "custom" folder for flashing., the reason behind it is known to all, yap. Not all devices have them in common, every device have its own files)
These are all i got for now, pls post ur ideas and knowledge for any possible cure about any problem u faced/ cured. So that we can make it an ultimate rescue.zip that have a cure for 99% problems android os have. The rest 1% will go with a clean flash.( well we cant avoid that if we did something that bad).
So my plan is to use aroma installer( now on hard learning to find how it works). Throw in some scripts, files etc. Into the zip.
And since its not a device specific .zip file, i want to know how and why any problems are caused in any device( there are many common problems, but that is not what i ask for. I ask for device/os specific problems, and not for a problem that we can cure after booting, but for a problem that can make the device un-bootable) . So u people may help me to find those problems and cures for it. For my knowledge i have experience with wildfire and hd2.
Well i will keep this thread for a week or two, so that u can post ur knowledge, and info. after that i will release the file for u.
To the admin. Of the forum, pls keep this thread as announcement so that all can take a look.
HYPERDROID EXTREEM EDITION-THE NEW BENCHMARK ROM FOR HD2.

If you plan to do this available to any android device, the file size will be so big that it will become useless. Every phone has different apk, and not only that, but those apk are different in different version of os. For example, CM9 framework should not work on google release. Worst, older CM9 framework might not work on newer CM9 and newer framework might not work on older. Also, one of the cause of bootloop that i have been experiencing since i have my GNexus is data corruption of apps. The only way i had was to wipe data. I dont think there is a way to know if your app are corrupted with script. I also seen a lot of strange problem on SGS II like the kernel being erased. Well, in this case this package would be useless. So i guess that having this package would be awesome, but wont happen. My best advice is that you could create a universal guide on how to recover from bootloop/fc/hang with the minimum of impact on the phone. This is just my opinion tho.
Sent from my Galaxy Nexus using xda premium

You could add using flags in the updates filename, see some roms or themes for the lg optimus 2x for more information. It uses sed. For example, "update-wc-wd.zip" would wipe /data and /cache.
You could also merge these features in a customized clockwork mod recovery, the up side would be that you could automatically make a backup of the last flashed full ROM's systemui etc. this would also allow usage of the touch screen/volume keys to choose an repair option. You could even allow users to backup specific applications along with their data, and let users restore it later on after a fresh flash. I have some basic knowledge in modifying the recovery so I might help you out a little if you're interested.

chadouming said:
If you plan to do this available to any android device, the file size will be so big that it will become useless. Every phone has different apk, and not only that, but those apk are different in different version of os. For example, CM9 framework should not work on google release. Worst, older CM9 framework might not work on newer CM9 and newer framework might not work on older. Also, one of the cause of bootloop that i have been experiencing since i have my GNexus is data corruption of apps. The only way i had was to wipe data. I dont think there is a way to know if your app are corrupted with script. I also seen a lot of strange problem on SGS II like the kernel being erased. Well, in this case this package would be useless. So i guess that having this package would be awesome, but wont happen. My best advice is that you could create a universal guide on how to recover from bootloop/fc/hang with the minimum of impact on the phone. This is just my opinion tho.
Sent from my Galaxy Nexus using xda premium
Click to expand...
Click to collapse
I told it already, the "custom" folder is not filled. It will be kept empty. The user can put a file, which ofcourse is the file of the device he/she have or want to get repaired. All he has to do is copy and paste the file from the working zip( zip file of his currently installed rom, that encounter the problem) of his rom to the custom folder inside the rescue.zip.
And the things that are common will be scripts, but those too will contains device specific mound points, paths, etc. I think that will be common( ie, the working of script, once the mound is done). Am i right?
So all i have to figure out is mount points, paths etc.. i got a couple of them, about 15 or so. And pls help me to find the rest.
HYPERDROID EXTREEM EDITION-THE NEW BENCHMARK ROM FOR HD2.

a good idea to add is a file system chech like windows systems has. By installing a rom the installer should first check for bad sectors and mem blocks before installing the rom. After all blocks and sectors are scanned and the bad ones marked as "bad or corrupt" it should run something like defrag and place the bad blocks at the end of the file table. When all is done .. then the true rom install should start.
This will prevent heaps of problems since the curent installs just write over a bad block or sector creating the most weird problems. A fault checker/repair will take away a lot of strange forced closes and othere software/hardware failures.
Most phones wont last that long so that bad blocks or sectors can occure. But for the flashing junkies among us its a serious problem what can occure. I guess after 1000 or more installs bad sectors or blocks will occure and not all are being able to be repaired
Sent from my Galaxy Nexus using XDA App

Mikevhl said:
You could add using flags in the updates filename, see some roms or themes for the lg optimus 2x for more information. It uses sed. For example, "update-wc-wd.zip" would wipe /data and /cache.
You could also merge these features in a customized clockwork mod recovery, the up side would be that you could automatically make a backup of the last flashed full ROM's systemui etc. this would also allow usage of the touch screen/volume keys to choose an repair option. You could even allow users to backup specific applications along with their data, and let users restore it later on after a fresh flash. I have some basic knowledge in modifying the recovery so I might help you out a little if you're interested.
Click to expand...
Click to collapse
I am totaly newbee to lg. I have experience with htc, few samsung, etc. So can u pm me the details? Also is it usable to create recovery? I think a zip file with selectable options is more friendly. The thing is building a recovery wont make it universal( or atleast common for a couple of devices) and we will have to port them for each and every device. Thats the problem.
But any way i want ur help in building it. Can u pm me an example for mounding script in lg devices? And any thing that may become useful. Thank you.
HYPERDROID EXTREEM EDITION-THE NEW BENCHMARK ROM FOR HD2.

wilwilwel said:
a good idea to add is a file system chech like windows systems has. By installing a rom the installer should first check for bad sectors and mem blocks before installing the rom. After all blocks and sectors are scanned and the bad ones marked as "bad or corrupt" it should run something like defrag and place the bad blocks at the end of the file table. When all is done .. then the true rom install should start.
This will prevent heaps of problems since the curent installs just write over a bad block or sector creating the most weird problems. A fault checker/repair will take away a lot of strange forced closes and othere software/hardware failures.
Most phones wont last that long so that bad blocks or sectors can occure. But for the flashing junkies among us its a serious problem what can occure. I guess after 1000 or more installs bad sectors or blocks will occure and not all are being able to be repaired
Sent from my Galaxy Nexus using XDA App
Click to expand...
Click to collapse
Pls pm me the idea how to make the checking script. Or links that have info in this. Thank u in figuring out such a prob. I am unaware of that.
HYPERDROID EXTREEM EDITION-THE NEW BENCHMARK ROM FOR HD2.

showlyshah said:
I am totaly newbee to lg. I have experience with htc, few samsung, etc. So can u pm me the details? Also is it usable to create recovery? I think a zip file with selectable options is more friendly. The thing is building a recovery wont make it universal( or atleast common for a couple of devices) and we will have to port them for each and every device. Thats the problem.
But any way i want ur help in building it. Can u pm me an example for mounding script in lg devices? And any thing that may become useful. Thank you.
HYPERDROID EXTREEM EDITION-THE NEW BENCHMARK ROM FOR HD2.
Click to expand...
Click to collapse
I'll send this as a PM as well, but people might learn from this. I am not talking about any specific mount points for LG phones, I just pointed out that there are some roms which use sed to check the filename of its update.zip and do tasks according to that, you need to have one line in your updater script to run the script which detects what to do. That way a user of a Galaxy Nexus would rename it to update-maguro.zip and it would know to use mount points for the maguro, while if the exact same update.zip was to be named update-p990.zip, it would know to use the mount points for the LG optimus 2x. This way you could easily keep the zip up to date for any device, because they all use the same update.zip
About the recovery, you would need to build it for every phone once, but you could make one change to the recovery source and easily compile the recovery for all phones which are capable of running CWM. I believe this method to be more user friendly, as a recovery image has support for actually choosing what you want to do, instead of having to rename the file. A recovery image also has a better way of communicating with the user. Where a update.zip can only say "Hey, I had an error and I'm quitting now, I won't give you any details what the problem was because that's just how update.zips roll", a recovery image would be able to give more advanced outputs, like "An error occurred when trying to mount /data." And then give you the option to either try again, manually fix it by using a computer with adb, or quitting.
But that's just my personal opinion. The recovery would be way harder to make, but I was the original porter of CM6, CM7 and HTC Sense to the xperia mini pro and mini back in the days. I also made a custom recovery and roms for the HTC desire Z, maintain a CWM port for the HTC Chacha which I don't even own and have used the LG optimus 2x before. (currently a maguro owner) but I'm trying to say that I've been experimenting a lot with different phones and know what the possibilities of Android are. you could even make a live Android build, tailored for recovering your phone, which is ran by an update.zip! How cool is that? That would be VERY device specific though..
let me know what you think is the best way to do this. I was thinking of making a mobile time machine app for some time so it's good I saw this thread.

My Galaxy Nexus is being very laggy...

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

[Q] Data recovery on Xperia S (rooted)

Hi all,
Just wanted to start by saying, big thanks to DooMLoRD and the rest of the xda-developers forum for providing me the tools to get root access to a friends phone, who has recently accidentally deleted all their photos and videos. If we are successful, I'll definitely be suggesting that they make a donation to Doom for his epic contributions
I'm trying to help them recover the lost media. I know that typically performing data recovery on a phone requires root access, so I have gone ahead and done this. On with...
My question:
I've got an Xperia S running Jellybean (4.1.2) which is rooted. However attempting to use my data recovery tools on the phone, the device is not shown as a storage device. As you may well be aware, the S does not come with external storage. The S also has the 'mass storage mode' removed. Nice one Sony, give professionals another reason to avoid your products in the future...
I don't want to Flash the phone since any added files will start destroying the potentially recoverable data (plus I'd simply rather not format the phone if possible).
Is it possible to mount the internal storage of the Sony Xperia S as a drive so that I can run my PC based data recovery tools on it?
I imagine App Store apps are too lightweight to handle a file-based undeletion. If I could just see the device in my recovery apps I'm sure I'd be in business! I've attempted Recuva and R-Studio.

Doing some more research (like a good little n00b) I imagine I'm going to need SD Mounter.
I'm a little thrown off because 'SD' usually describes SD cards (of which the Xperia S has none). Also, the screenshots (for SD mounter) seem to indicate it's for ICS so I'm not sure if there's going to be a compatibility issue there.
Am I barking up the wrong tree by making this assumption? Should JellyBean have access to the mass storage and the option is simply not showing for some reason? Anyway, I'll continue working under my assumptions until someone suggests otherwise...
To get SD Mounter running, I'm going to need BusyBox. The problem is, I'm trying to read the BusyBox installation FAQ, and I'm finding it very vague. Like...
and save it under the name "busybox"
Click to expand...
Click to collapse
but it does not specify WHERE. Make a folder called 'busybox' on the root folder of the phone? Somewhere on my PC (the page suggests its for the PC rather than the phone)? Also I'm seeing Linux-looking command lines, but I'm on a PC... can I run this via the command prompt in Windows? I downloaded the 'binaries' like it said, but there aren't any executables in here...
Can anyone shed some light?

There's an app called BusyBox Installer, that installs it correctly on my Xperia S. That SD Mounter app works perfectly on 4.1.2, though. I use time to time. It just messes up a bit with Media Scanner, requiring me to do a reboot on the phone to make it work again.
I wish you lot of luck trying to recover your files. I once tried something like that, but came unsuccessful. There were some media I wish I had saved, but it wasn't THAT important, so I just gave up.
Suggest to your friend, though, to get an account on Mega, Box.net or Dropbox. All of them has auto backup of camera media to the server. All of them has options to backup only on WiFi, and even when charging only. The first two has 50 Gb of free storage for life (Box, you just need to sign with your Xperia device), and the later only 2 Gb, but you can get more and more with promotions.
Alternatively, he can enable the Google+ Auto Backup. There is 15 Gb (shared with Gmail and Google Drive) for pictures on original resolution or unlimited on 2048px, compressed. On Google+, though, you have the Auto Awesome, which make some awesome images.
Hope it helped. If I can help any further, just tag me
Sent from my LT26i using Tapatalk

Hey Felimenta97, thanks for your swift response!
Felimenta97 said:
There's an app called BusyBox Installer...
Click to expand...
Click to collapse
I see 'BusyBox Installer' in the Play Store, is that the one? Seems strange that the Play Store would add an app that requires rooting. Just wanna make sure I shouldn't be looking for it somewhere else (plus I'm away from that phone at the moment)
Felimenta97 said:
It just messes up a bit with Media Scanner, requiring me to do a reboot on the phone to make it work again.
Click to expand...
Click to collapse
That's okay. I've warned them this process might even brick their entire phone. They are prepared (I hope) for complete loss/compromised apps
Felimenta97 said:
...I wish you lot of luck trying to recover your files. I once tried something like that, but came unsuccessful...
Click to expand...
Click to collapse
*touches wood*. Gah I'm suddenly 10 times less confident this file recovery is gonna work. Wish me luck! They'll be crushed if I can't get their media back...
Felimenta97 said:
...get an account on Mega, Box.net or Dropbox...
Click to expand...
Click to collapse
Oh trust me, I've already given them the lecture
Thanks for your help!

TheWaste said:
Hey Felimenta97, thanks for your swift response!
I see 'BusyBox Installer' in the Play Store, is that the one? Seems strange that the Play Store would add an app that requires rooting. Just wanna make sure I shouldn't be looking for it somewhere else (plus I'm away from that phone at the moment)
That's okay. I've warned them this process might even brick their entire phone. They are prepared (I hope) for complete loss/compromised apps
*touches wood*. Gah I'm suddenly 10 times less confident this file recovery is gonna work. Wish me luck! They'll be crushed if I can't get their media back...
Oh trust me, I've already given them the lecture
Thanks for your help!
Click to expand...
Click to collapse
As I'm a lazy person, who can't find a way to break quotes into multiple parts (serious, how do you Do that, without having to write the quote code every time? It is not much, but I'm really lazy, so yeah.
Yep, that's the app. There's no reason for Google to block root apps. It's a function of the OS itself, just hidden from users. It's one of the easiest things to do on a Nexus device, after all. It's hidden because, if used without caution, can soft brick your device. But, don't worry, that shouldn't do any harm. At it least it hasn't with my device until now haha
As I said, I had already lost lots of stuff, and I didn't bothered much to go any further to recover it. It was a simply Install Recuva, run on the SD card and see if I could restore anything. Nothing? OK, no worries. As you already mentioned in your first post, avoid at all costs writing new files to the SD Card partition.
About the lecture, yeah, I imagined you had already told them, but it doesn't hurt to tell anyway.
About the SD Card on the Xperia S, another technical info you might or might not know, and also doesn't hurt to tell. Until Android 2.3, devices with a big internal storage required a partition for cache, one for data (apps and their own data), one for system, and one SD Card. The last one in Fat32 (plus others, but those are just too small and insignificant, for most, anyway) Think of a normal hard drive with plenty of partitions. Since Xperia S was developed (and launched) with 2.3 (one of Sony's biggest mistakes with this phone), it had to follow those "guidelines".
With Android 4.0 and beyond, the above mentioned data and SD Card turned into one partition, in Ext4 format. That data partition stores both apps and their data, and also other types of media, like media, documents, and etc. That storage goes into a mounted folder.
Anyway, again, wish you good luck. If they aren't very close friends/relatives, you should charge some money for all the hassle if you recover haha
Sent from my SGP311 using Tapatalk

Felimenta97 said:
how do you Do that, without having to write the quote code every time?
Click to expand...
Click to collapse
Haha, actually I still kinda do. #hen I hit 'reply' I empty the quote block, copy the empty quote block a few times, then copy-paste the parts of the text I'm replying to as I go
Felimenta97 said:
avoid at all costs writing new files to the SD Card partition.
Click to expand...
Click to collapse
Yeah absolutely.
Felimenta97 said:
Until Android 2.3, devices with a big internal storage required a partition for cache, one for data (apps and their own data), one for system, and one SD Card
Click to expand...
Click to collapse
Jeaz. Thank god I don't have to eff around with that!
Felimenta97 said:
With Android 4.0 and beyond, the above mentioned data and SD Card turned into one partition, in Ext4 format. That data partition stores both apps and their data, and also other types of media, like media, documents, and etc. That storage goes into a mounted folder.
Click to expand...
Click to collapse
I don't need to re-format the internal storage of the phone to attempt recovery do I?
Thanks again Felimenta!

TheWaste said:
Haha, actually I still kinda do. #hen I hit 'reply' I empty the quote block, copy the empty quote block a few times, then copy-paste the parts of the text I'm replying to as I go
Yeah absolutely.
Jeaz. Thank god I don't have to eff around with that!
I don't need to re-format the internal storage of the phone to attempt recovery do I?
Thanks again Felimenta!
Click to expand...
Click to collapse
Not in Xperia S case. As I said, it is on Fat32, so it is easily mount-able on Windows.
On any phone with Android 4.0 or more, you'd need a Linux to do the recovery. You can't format it, or else you will turn the device into a really expensive paperweight.
Sent from my SGP311 using Tapatalk

No Baseband - No EFS - with solution/explanation

I figured this out after a struggle, so I figured I would pass along the info in case it helps anyone else.
I'm running CyanogenMod 11 (Android 4.4.4 Kit Kat AOSP based) on my T-Mobile Galaxy S III. I'm on vacation in Mexico, and I had planned to use my Verizon HTC Rezound (aka HTC Vigor) as a phone with a local Mexican SIM card from Telcel. Once I was in Mexico I discovered that the Rezound does not support the GSM/HSPA bands commonly used in North America. It should work fine in Europe, but I could only get Edge service. I decided to try to unlock my T-Mobile Galaxy S III to see if it worked any better.
The free unlock methods I found seemed to require the stock Service Mode applications - so I needed to install a stock rom. I tried to flash a rooted stock 4.3 ROM but the instructions didn't seem to work. The baseband I was running seemed to be too new for the unlock method, which was noted as working with 4.1.1. I tried to downgrade the baseband. It still did not work. I tried flashing a stock rooted 4.1.1 image, and it still did not work. At some point while trying things I realized that no baseband was getting reported in the about screen and no IMEI number was being reported. The phone wasn't even trying to connect to the network. Googling around made me think I hosed my EFS partition. I didn't have a backup.
I hoped that if the EFS partition was corrupted, it might get rebuilt. I used 'dd if=/dev/block/platform/msm_sdcc.1/by-name/efs of=/storage/extSdCard/efs.img' to make a copy of the current state of the efs, then I deleted all the files. I restarted the phone. So data got written to efs, but still I couldn't connect to the network. I didn't have a windows computer with Odin on my trip, by I tried used heimdall with my Mac to write a stock 4.1.1 rom. Still no luck. Not only was the network not working, but the touch screen and buttons were erratic and it would spontaneously reboot. Also, it would generate no sound at all. I figured I practically had a brick. I tossed it in my suitcase and left it until I got home.
When I got home I used ODIN to write the most recent (Android 4.3) root66 stock rooted image. On reboot I got sound back. That was promising. I used dd again to restore the contents of my EFS partition. I was able to connect to the network again. I installed the latest snapshot build of CyanogenMod 11 and everything seems to be working.
I finally put the pieces together. The EFS partition in older roms is formatted with a FAT filesystem, and in new roms it is formatted with an ext4 filesystem. At some point as the phone is upgraded, the EFS partition gets updated to the newer filesystem. Older basebands can not read the data from the ext4 filesystem. If you do not have a backup of the FAT version of your EFS partition, you can't downgrade to the older baseband.
I don't know the precise transition point, but the baseband that comes with 4.3 can read the ext4 partition fine, but the basebands with 4.1 need the FAT partition.
If you open a terminal shell on your phone or with adb shell, then type 'mount', you'll see a list of mounted volumes. The entry for the EFS partition will look like this...
Code:
/dev/block/platform/msm_sdcc.1/by-name/efs /efs ext4 rw,seclabel,nosuid,nodev,noatime,user_xattr,barrier=1,journal_async_commit,data=ordered,noauto_da_alloc,discard 0 0
The first field is the location of the partition. The second field - in this case '/efs' is the mount point. The third field is the filesystem type. Here you see 'ext4'. On your phone, look for the line where the second entry is '/efs'. If the third entry is 'vfat' you can downgrade to older basebands. If it is 'ext4' you can't go to very old basebands unless you have a backup of the old version of your EFS partition and you know how change the filesystem format. Anyone with decent Unix/Linux experience should be able to do that - it isn't hard - but I don't have the old EFS backup to try it out, so I won't try to give any instructions here.
I hope this saves you some trouble.

I think I understand the theory behind what you are trying to explain here, but I dont think this will make a difference.
First though, how did you come to the conclusion that older builds format that partition differently, or more specifically, as vFAT? And that older modems can only read this format?
The reason I dont believe this will make any difference is because much of the data everyone seems to think is located on the EFS partition is not there on the Qualcomm model S3's. For example, the IMEI. On older devices, and maybe some newer ones (dont know for sure), it was moved. If I remember correctly, some of the NV Data is stored on modemst1, some on modemst2, some on param, and some one hidden boot partitions, (and possibly elsewhere). (Dont quote me on those, its been a while since ive looked at all of this so im going by memory and may be slightly off.) But the EFS partition, as best as I can remember, mostly contains data related to DRM, factory mode, carrier info, s/n, and a few other things. I believe there is some important data there related to the modem and network, but not all of it.
The other reason I dont think this would make a difference is I dont see how the system could read and write to other partitions that are vFAT or ext4, but not EFS. It should be able to do so (and is able to do so for the data that is there) regardless of which format it is using. Both formats have been used on this device since day 1.
I am also not certain about the EFS having been re-formatted to a different filesystem at some point. To my knowledge, Odin does not touch that partition, and I've never seen any indication that it has ever formatted anything unexpected in the past. Besides, wouldnt this change its size on disk and thus require the re-formatting of other partitions to compensate? (Im not saying i am right or you are wrong about this, just there are things that aren't making sense to me here.)
I also dont know how comfortable I would be re-formatting ANY partition to a different filesystem. Let alone one that probably cannot be repaired with Odin. For the $5-6 that you might save, it just doesnt seem to be worth the risk to me. (Risk vs reward)
I do apologize if any of this has come off as too argumentative. If your theory does prove to be correct, thats awesome, but I just want to make sure all points are covered before telling anyone something like this is safe to attempt.
Thanks for the post either way though. I do find it interesting!

DocHoliday77 said:
how did you come to the conclusion that older builds format that partition differently, or more specifically, as vFAT? And that older modems can only read this format?
Click to expand...
Click to collapse
I'm trying to retrace my google searches to find the exact reference. It was not a post focused on the SGH-T999, but another similar device. When I find it I'll update to point there.
DocHoliday77 said:
The other reason I dont think this would make a difference is I dont see how the system could read and write to other partitions that are vFAT or ext4, but not EFS. It should be able to do so (and is able to do so for the data that is there) regardless of which format it is using. Both formats have been used on this device since day 1.
Click to expand...
Click to collapse
It is my impression, and please correct me if I am wrong, that the baseband software does not run inside the linux kernel that primarily operates the phone. The low level radio functions have their own system with their own CPU functions and such. There are several reasons this makes sense.
First, interaction with the mobile radio infrastructure is very timing dependent. The software that operates the radios needs to be "real time" - meaning that every task that the system performs must complete in a predictable, determinable amount of time. General purpose, multitasking operating systems like Linux, virtually all Unix systems, and Windows don't do this well. If a general purpose system has specific subsystems that require real time operation, the common solution is put those operations onto a small purpose built hardware with its own processor and software. Even in your standard PC, the ethernet adapters and disk drives have their own processors and firmware.
Second, if the interaction with the radio network was happening in-kernel, then the GPL would require that the software to run this would be open source. The source code for the baseband is not freely available. That suggests that the baseband is separate. It is possible that the code to run the radios could be in a userland process, not in-kernel, and so sidestep the GPL issue. That is unlikely, however, since it would make the timing issues even more difficult.
So if the baseband is software running on a separate CPU, it doesn't matter that the kernel has the modules to read both vfat and ext4. The baseband would need the modules to read that. If certain baseband revisions did not include the modules to read ext4, then the baseband process could not read that data.
DocHoliday77 said:
I am also not certain about the EFS having been re-formatted to a different filesystem at some point. To my knowledge, Odin does not touch that partition, and I've never seen any indication that it has ever formatted anything unexpected in the past. Besides, wouldnt this change its size on disk and thus require the re-formatting of other partitions to compensate? (Im not saying i am right or you are wrong about this, just there are things that aren't making sense to me here.)
Click to expand...
Click to collapse
Other partitions would need to be changed if the size of the EFS partition was increased, but if the size of the EFS partition was not increases, the format could be changed. That process doesn't have to happen in Odin. It could be done at first boot with a particular software revision. The system would need to backup the data on the EFS partition that needs to be saved, reformat the partition using the equivalent of the mkfs command, adjust the partition table and/or the fstab so that the system could mount it properly, remount it, and write back the EFS data - possibly in a new format. All this could be done by any process that had root privs on the system. The baseband could do this itself, even, before the Linux kernel was loaded.
DocHoliday77 said:
I also dont know how comfortable I would be re-formatting ANY partition to a different filesystem. Let alone one that probably cannot be repaired with Odin. For the $5-6 that you might save, it just doesnt seem to be worth the risk to me. (Risk vs reward) ...t I just want to make sure all points are covered before telling anyone something like this is safe to attempt.
Click to expand...
Click to collapse
I definitely don't suggest that anyone tries this unless they are really really really comfortable with this kind of hacking.
BTW - some additional reading in a different T999 thread mentioned that once you go to the NC2 baseband-firmware it is not possible to go back. Makes me think that NC2 is the dividing line if I'm correct about this.

Afaik, you are correct on how the modem operates independently from the rest of the system. That was a good point I didn't take into account, so I will agree that what you stated about the filesystem format being changed is possible. In helping people around here I do periodically run into folks who have never updated beyond 4.1.1 or 4.1.2, so ill try to remember to ask them to check what format the efs partition uses next time. That would probably be the best way to confirm whether or not it was changed somewhere along the way.
As for the sizing of the partition, I do see what you are saying. I was thinking in terms of keeping the usable space the same, which if I am not mistaken would require more space on disk for vFAT.
One other reason I dont think it was changed btw, is I have compared the partition tables of older vs newer builds in the past. It has been a while though, and I wasn't focusing on the efs at the time so I may have overlooked something, but I didnt notice anything different. I was doing this while helping with our debricking process, so it is possible I just didnt see the change, but I kind of feel like I would have had it been there. But, as I just said, it is possible I overlooked it since I wasnt specifically looking for that kind of change.
The inability to downgrade firmware began with our first 4.3 update (MJC). This was done to help prevent tampering and attempts to break into the Knox secure containers.
Something else that just came to mind, is that while you cannot use an older baseband for that reason (Knox), you can use the 4.3 baseband on pre-knox builds (4.1.2 and earlier). So if you were running 4.1.1, for example, you could use the 4.3 baseband. So if your theory is correct wouldnt it mean the 4.3 baseband is capable of reading both formats? And if that is the case, it would mean its something different blocking the SIM unlock in the menu, right?
We do not have 4.4.2 yet, but I have been very active in AT&T's forums lately and can say it is almost the same. You still cannot use older modems as they just wont function, but you can use the 4.4.2 modem on a 4.1.2 or earlier build. The difference, is that while trying the 4.3 baseband on 4.4.2 firmware just doesnt work, if you put a 4.4.2 modem on 4.3 firmware you get an irrecoverable hard brick. Not even jtag will fix it. (right now the only fix is to replace the motherboard). I know that last bit doesn't have much bearing on the topic at hand, but thought I'd throw it in there since on the subject.
So anyway, if the newer basebands will function on older firmware, and the formatting of the efs had been changed, that means the new modems are capable of reading both formats. If all of that is true, the changing from vFAT to ext4 really wouldn't make a difference.
I hope I explained all of that well enough!