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...
I"m not sure if my phone is messed up or not. It seems to be working right, but when I run Android Tuner and optimize the apps, they all force close and will not operate any longer. The same thing happened when I went into recovery to make a nandroid. After it was done, I wiped dalvik cache and when it rebooted many of my apps won't operate. Looking at them with ROM Toolboox I can see all the app icons diappeared and are left with just the technical name of the app ( Ex... com.liberty.toolbox-1.apk) instead of the market icon and the more common name used. Part of it is getting chopped off. This has never been a problem before this week. Does anyone have an idea of what is wrong with my phone? I'm a noob, but I've got the basics down. Help me if you read this... Please.
TheEvoNoob said:
I"m not sure if my phone is messed up or not. It seems to be working right, but when I run Android Tuner and optimize the apps, they all force close and will not operate any longer. The same thing happened when I went into recovery to make a nandroid. After it was done, I wiped dalvik cache and when it rebooted many of my apps won't operate. Looking at them with ROM Toolboox I can see all the app icons diappeared and are left with just the technical name of the app ( Ex... com.liberty.toolbox-1.apk) instead of the market icon and the more common name used. Part of it is getting chopped off. This has never been a problem before this week. Does anyone have an idea of what is wrong with my phone? I'm a noob, but I've got the basics down. Help me if you read this... Please.
Click to expand...
Click to collapse
What ROM are you running? Are you running a2sd?
With certain ROMs, I had the same issue (though more often when running a class 10 sd card then a class 2 card).. Basically the "fix" was to reboot into recovery, wipe cache/dalvik again, and then reboot. Every time I rebooted the phone, I would have to reboot twice. What is happening is that the phone is missing the step where it has to mount /sd-ext so your apps are no longer there, but the data is. So you can see the names in things like ROM toolbox, because it sees them in /data, but the apps don't exist because /sd-ext isn't mounted.
I'm having some internal memory issues. I know my internal folders are jacked up. I'm not sure how the file system works. Is it basically a blank canvas that the recovery builds folder by folder, OR does the phone retain the file system and the recovery just fills in the empty folders? Can somebody tell me how this works please? If anyone knows a link to the Evo 4G file system, please post it. Every place I look, the file no longer existed, or has been removed.
TheEvoNoob said:
I'm having some internal memory issues. I know my internal folders are jacked up. I'm not sure how the file system works. Is it basically a blank canvas that the recovery builds folder by folder, OR does the phone retain the file system and the recovery just fills in the empty folders? Can somebody tell me how this works please? If anyone knows a link to the Evo 4G file system, please post it. Every place I look, the file no longer existed, or has been removed.
Click to expand...
Click to collapse
How big is your sdcard? That is showing a 28 GB SD card with no ext partition. Did you ever partition it?
souleman said:
How big is your sdcard? That is showing a 28 GB SD card with no ext partition. Did you ever partition it?
Click to expand...
Click to collapse
Yeah, it was partitioned. I fixed it just a few minutes ago. Man...it was the vold.fstat files that were all jacked up. I fixed it by unrooting it and flashing a completely stock image. Now I'm about to unroot it again and I'll be good to go. Thanks for even taking the time to read my post. In a relative ghost town of Evo4Gville that means a lot to me. Thanks brother. If you were curious, I have another thread called Storage issue problems, or something like that. The last post there outlines my problems. Thanks again for your input.
I have bricked my fire tv that has rbox's custom mod installed ( I wiped my sd partition and restarted the device before replacing the restore.img) so totally my own stupid fault... but I have a guy on this forum that's kindly trying to assist me in restoring it as he has the ability to get access to the emmc chip. He has a complete back up of his flash but what he is needing to know though is : where/how the FireTV is storing unique stuff like serial number/Device ID and whatnot. MAC addresses of Wifi and LAN would come to mind too. But he's pretty sure this contains IDs that are unique.
Would the following be possible : If we would know in what part this information is stored. He could try to make a backup of this from my device once it shows up as eMMC, and then later restore it
Any advice really appreciated as just want to return my fire tv to a working state.
Paul
Paul1672 said:
I have bricked my fire tv that has rbox's custom mod installed ( I wiped my sd partition and restarted the device before replacing the restore.img) so totally my own stupid fault... but I have a guy on this forum that's kindly trying to assist me in restoring it as he has the ability to get access to the emmc chip. He has a complete back up of his flash but what he is needing to know though is : where/how the FireTV is storing unique stuff like serial number/Device ID and whatnot. MAC addresses of Wifi and LAN would come to mind too. But he's pretty sure this contains IDs that are unique.
Would the following be possible : If we would know in what part this information is stored. He could try to make a backup of this from my device once it shows up as eMMC, and then later restore it
Any advice really appreciated as just want to return my fire tv to a working state.
Paul
Click to expand...
Click to collapse
The only thing you need to restore to make it functional is boot and system. What exactly do you mean by "wiped my sd partition"?
Paul1672 said:
I have bricked my fire tv that has rbox's custom mod installed ( I wiped my sd partition and restarted the device before replacing the restore.img) so totally my own stupid fault... but I have a guy on this forum that's kindly trying to assist me in restoring it as he has the ability to get access to the emmc chip. He has a complete back up of his flash but what he is needing to know though is : where/how the FireTV is storing unique stuff like serial number/Device ID and whatnot. MAC addresses of Wifi and LAN would come to mind too. But he's pretty sure this contains IDs that are unique.
Would the following be possible : If we would know in what part this information is stored. He could try to make a backup of this from my device once it shows up as eMMC, and then later restore it
Any advice really appreciated as just want to return my fire tv to a working state.
Paul
Click to expand...
Click to collapse
best bet is to have him DD each partition individually back onto your device from the prerooted roms, but you should confirm with Rbox about what partitions would need to be flashed.
edit whoops didnt see your reply
I stupidly went into advanced settings and wiped sd partition (been over a month now and can't exactly remember) feel so stupid
Think there was something else I wiped also bout can't be sure on exactly what, but it was in the advanced menu
rbox said:
The only thing you need to restore to make it functional is boot and system. What exactly do you mean by "wiped my sd partition"?
Click to expand...
Click to collapse
If he uses the boot and system from his complete flash will either of them contain any unique data (IDs, MAC, SerialNumber)?
Paul1672 said:
If he uses the boot and system from his complete flash will either of them contain any unique data (IDs, MAC, SerialNumber)?
Click to expand...
Click to collapse
No. Which is why those were the ones I said...
once its bootable again, is the pre-rooted image enough to fully restore it?
Where is the FireTV taking all those unique IDs from, do we need to backup/restore this from my device, or is it hardcoded somewhere on a chip?
I want to encrypt my OnePlus 3 but every time I hit "encrypt" my phone just reboots.
So I took a look at the logs and it says "Orig filesystem overlaps crypto footer region. Cannot encrypt in place."
So even after spending about 2 hours looking into this issue all I could find is that apparently android needs about 16KB of space at the end of some partition.
I found some how to's but unfortunately the steps are very complicated and I don't know how to follow them on the OnePlus 3.
So does anybody know how to solve this issue? There is an resize option in TWRP but it doesn't give you any options and doesn't solve the problem.
My OP3 already says it is encrypted. That's the way it came out of the box. Yours didn't? That's odd.
Sent from my D5803 using Tapatalk
Yes, it was encrypted out of the box but I installed TWRP and CM13. It seems like the partitioning got messed up somehow while wiping/formatting /data.
anyone23 said:
Yes, it was encrypted out of the box but I installed TWRP and CM13. It seems like the partitioning got messed up somehow while wiping/formatting /data.
Click to expand...
Click to collapse
After flash back OOS and doing a factory reset it will encrypt automatically again.
Planet X said:
After flash back OOS and doing a factory reset it will encrypt automatically again.
Click to expand...
Click to collapse
Yes, of course but I want to keep on using CM13.
Encryption is usually no problem with CM. I've been using CM with encryption on my Nexus 5 for 2 years.
I just don't know how to fix the partitioning.
Okay, after unsuccessfully playing around with the resize2fs command, I found the solution.
As resizing while Android is running doesn't work, I booted into TWRP, unmounted all partitions and then opened a terminal in the advanced menu.
I already knew that the /data partition is the one I needed to shrink and it's called /dev/block/sda15. So I used the command "resize2fs /dev/block/sda15 1xxx..."
On first try I accidentally used a number far too high but in the error message I got, it stated the current size and so I simply subtracted 40 from this value and ran the command again (4 should be enough for 16kb, but I wanted to make sure).
Well, now the encryption was successful.
I still think that this problem occurred after a format using TWRP and it needs be fixed as this is a problem very difficult to diagnose for the average person like me. TWRP seems to format the whole memory for /data but Android needs 16kb of free space for encryption.
I already had the same problem with encryption on a Moto G falcon after a TWRP format a few months ago.
anyone23 said:
Okay, after unsuccessfully playing around with the resize2fs command, I found the solution.
As resizing while Android is running doesn't work, I booted into TWRP, unmounted all partitions and then opened a terminal in the advanced menu.
I already knew that the /data partition is the one I needed to shrink and it's called /dev/block/sda15. So I used the command "resize2fs /dev/block/sda15 1xxx..."
On first try I accidentally used a number far too high but in the error message I got, it stated the current size and so I simply subtracted 40 from this value and ran the command again (4 should be enough for 16kb, but I wanted to make sure).
Well, now the encryption was successful.
I still think that this problem occurred after a format using TWRP and it needs be fixed as this is a problem very difficult to diagnose for the average person like me. TWRP seems to format the whole memory for /data but Android needs 16kb of free space for encryption.
I already had the same problem with encryption on a Moto G falcon after a TWRP format a few months ago.
Click to expand...
Click to collapse
I'm running cm13 with encryption on my OnePlus 3 too. I didn't had to resize my partitions.
hi guys, I am having trouble with my MI Max having 32GB internal memory.
From it's behaviour for last few days I have inferred it's system partition is the culprit.
On stock miui rom, it gives msg that encryption unsuccessful and I need to factory reset it. But even after doing factory reset it shows the same msg.
Its with locked boot loader but referring one thread I could install twrp latest version on it by replacing recovery image in stock rom and flashing with mi flash tool in edl mode.
So with two I tried installing few vision rooms like miui eu ROM, RR and crdroid based on Oreo. All the rooms while flashing fine error E1001, saying system image not updated and flashing failed.
I even tried repairing file system, fixing file system, Channing file system to fat, exfat, ext2, ext3, ext4 and f2fs several times (from advanced wipe menu) but things are not improving. Even tried formatting data partition as it's suggested at few places.
I am out of ideas after spending few days trying to fix it by flashing several times.
So please if some one can assist in resolving the issue, I would really appreciate.
Thank you in advance.
You need to format data not wipe . Go to twrp choose wipe , format data and type yes . Note, by doing this you will lose all of your data if you want to keep it make sure to save it to your PC or USB drive.
Zasnizas said:
You need to format data not wipe . Go to twrp choose wipe , format data and type yes . Note, by doing this you will lose all of your data if you want to keep it make sure to save it to your PC or USB drive.
Click to expand...
Click to collapse
Have already done it several times by now. Didn't make any difference.
harpy.eagle said:
Have already done it several times by now. Didn't make any difference.
Click to expand...
Click to collapse
As discussed yesterday on unofficial LineageOS (nijel8) thread the nand is damaged. You need to delate partition, compact unallocated space & then recreate the exactly the same partition. That way it won't be on the same spot & it will work.
Use a PC with an partition manager.
https://gparted.org/
Zola III said:
As discussed yesterday on unofficial LineageOS (nijel8) thread the nand is damaged. You need to delate partition, compact unallocated space & then recreate the exactly the same partition. That way it won't be on the same spot & it will work.
Use a PC with an partition manager.
https://gparted.org/
Click to expand...
Click to collapse
Tks a lot for the reply. It gave a ray of hope to me. Though I am hearing modifying partition on android device for the first time to fix it. That too for bricked device and to do it on PC. Is there any thread guiding about it? Would read a bit about how to do it in order to not mess things up even more.
harpy.eagle said:
Tks a lot for the reply. It gave a ray of hope to me. Though I am hearing modifying partition on android device for the first time to fix it. That too for bricked device and to do it on PC. Is there any thread guiding about it? Would read a bit about how to do it in order to not mess things up even more.
Click to expand...
Click to collapse
It's still ain't bricked so you can do this relatively easy. When it's bricked EDL programmer for used NAND chip used is needed.
So take a deep breath, see the exact size & type of the partition, delate it, create a new one exactly the same (type, size & name).
https://s10629.pcdn.co/wp-content/pictures/2010/01/captured_Image1.png51.png
https://helpdeskgeek.com/wp-content/pictures/2010/01/captured_Image1.png111.png
The tool I gave you URL is very good documented and with plenty examples & user guides available all which can be found on the site, it uses graphics GUI so it's as easy as it can be. So if you are inexperienced read/watch first how it's done. After you are done flash what you want in TWRP.
Best regards.
What I meant to ask is, how to access partitions of mobile on PC? I have used partitioning app on windows but never for android device. Anyway, as u have clued, I shall try accessing partitions with mobile connected in edl mode.