[Guide] Encryption Unsuccessful - Reset Android [ICS Issue]
- Thread starter cgugino
- Start date
-
- Tags
- captivate encryption galaxy s ics
Are you saying you were on AOKP configured to use USB Mass Storage instead of MTP and still got hit with this problem? Also, was it the real issue as in internal storage completely not mountable and not able to be fixed?
Corected, was sleepy when typed.
Correct internal storage completely not mountable and not able to be fixed.
Glad to see it was actually MTP and not UMS; I almost changed my mind about trying it again.
OK not glad that it happened to you; thanks for the updated info though.
Last edited:
Nice catch Jeff and thanks for the clarification D.
OK so it could be said that the general consensus is the mounting to PC and MTP causes the error to be thrown. Correct? Are we all in agreement here?
If so then we have two directions we need to follow.
First, we need to find out WHY it happens. It there something in the build or default.prop that triggers it when unmounting? Or is it something else.
Second, we need to find a "real" fix for this. Not that repartitioning the external is a bad idea but getting the internal back is better. If we can wipe the internal, will it also wipe the encrypted data? How can we mount the internal so that we can get to the point of wiping? Does this rely on what we find in the first issue of why it happens? How far are we going to have to drill down to find the root (no pun intended) cause?
I suggest anyone who wants to help to start reading up on how MTP was created and implemented into ICS. I will read as much as I can but I am going to need some help. Really need someone with a bunch of ADB experience. I can hold my own, but I fear this might be a Pandora's box.
Keep in touch
Wood
OK so it could be said that the general consensus is the mounting to PC and MTP causes the error to be thrown. Correct? Are we all in agreement here?
If so then we have two directions we need to follow.
First, we need to find out WHY it happens. It there something in the build or default.prop that triggers it when unmounting? Or is it something else.
Second, we need to find a "real" fix for this. Not that repartitioning the external is a bad idea but getting the internal back is better. If we can wipe the internal, will it also wipe the encrypted data? How can we mount the internal so that we can get to the point of wiping? Does this rely on what we find in the first issue of why it happens? How far are we going to have to drill down to find the root (no pun intended) cause?
I suggest anyone who wants to help to start reading up on how MTP was created and implemented into ICS. I will read as much as I can but I am going to need some help. Really need someone with a bunch of ADB experience. I can hold my own, but I fear this might be a Pandora's box.
Keep in touch
Wood
Vibrant users: MTP may be the culprit in your cases. I suggest you create a thread under your forum.
Captivate users: My Captivate, as well as others', threw the error at random. No PC, no MTP, no fanciness. In my case, I pulled my captivate out of my pocket and the error was there.
AFAIK, the internal SD (mmc0/movinand) won't be resuscitated by any Android/OS fixes, as it was confirmed "defective" by the SBL, a set of factory tools, built-in the phone, that is independent of the OS.
Good luck
Captivate users: My Captivate, as well as others', threw the error at random. No PC, no MTP, no fanciness. In my case, I pulled my captivate out of my pocket and the error was there.
AFAIK, the internal SD (mmc0/movinand) won't be resuscitated by any Android/OS fixes, as it was confirmed "defective" by the SBL, a set of factory tools, built-in the phone, that is independent of the OS.
Good luck
I felt the same as you originally and thought it was random. I pulled my Captivate out of my pocket and found it locked up; I restarted and got the error. However, I had connected to my laptop using MTP the night before and not rebooted until the lock up occurred. If you look into our theory you will notice the error won't show up until the next reboot. Therefore I would ask you to think back and see if you had connected to a PC between your last reboot and pulling your phone out of your pocket to find this problem.
I am really interested in your answer because I am installing Dark Knight 4 in a few minutes with a plan to not connect to my PC after. This is my last working Captivate and I would like to keep it that way; however I just can't resist ICS!
Please let me know, after thinking about it, if you still feel it was random or had you connected to a PC between your last reboot and the lock/crash/reboot with the error?
I certainly agree there is no easy fix and would likely require removing the memory chip from the board to fix it; if that would even work.
We have one created already but since the Cappy and Vibrant are extremely similar, the Encryption Error is identical and the post-error work around comes from this thread, we have been collaborating for the past week, seemed to make sense to centralize our efforts.
Good Luck in your efforts and see you around. If you need us, you know where to find us. Any and all information that I find will now be on our fora.
Later.
Woodrube, I agree that the problem is identical on Vibrant & Captivate. I think it is great to have a central forum and would like it if you stayed around here, please!
I'll see what I can come up with. What I really want is for some creativity in how we are to get at this. See my few posts back about the 2 directions we could go.
I am trying to get my hands on an Encrypted Vibrant to do some tests but when people get the error they tend to thrash their phones in a fit of rage or they try to "fix" it and make it worse. Since I don't own a Cappy I don't have any files or hardware but Android O/S is O/S so code is code. So if you or I can find a solution it should work for both.
ps - Thanks for the PM Jeff.
My feelings weren't hurt bc of an anonymous random post in an international multi-segregated developers forum about something that effects us all, but he kind of had a point too. Ill stick around but I need some more imagination on everyone's part and need someone else with ADB experience to test some ideas.
I am trying to get my hands on an Encrypted Vibrant to do some tests but when people get the error they tend to thrash their phones in a fit of rage or they try to "fix" it and make it worse. Since I don't own a Cappy I don't have any files or hardware but Android O/S is O/S so code is code. So if you or I can find a solution it should work for both.
ps - Thanks for the PM Jeff.
My feelings weren't hurt bc of an anonymous random post in an international multi-segregated developers forum about something that effects us all, but he kind of had a point too. Ill stick around but I need some more imagination on everyone's part and need someone else with ADB experience to test some ideas.
Maybe cross posting this in the general Android Development forum would get more exposure.
(I have not encountered the issue myself yet on my Captivate. It's got CM9, but I'm not using MTP. I've been following this from pretty early on though.)
(I have not encountered the issue myself yet on my Captivate. It's got CM9, but I'm not using MTP. I've been following this from pretty early on though.)
I didn't "thrash" my "encrypted" Captivate but I did attempt to remove the internal battery (small one on the board) and now it doesn't seem boot. It looks like I may have just broken a solder joint; I should have time Monday to re-solder it and try again. Imagine if the phone is fixed after simply removing the internal battery and putting it back; that is what I was hoping when I originally tried to remove it.
Also, thanks for sticking with us here.
---------- Post added at 07:05 PM ---------- Previous post was at 07:03 PM ----------
When you say you are not using MTP do you mean not connecting to a PC or you are forcing it to use USB Mass Storage mode instead of MTP?
Last edited:
I have been searching other device forums most of the day and the General/Q&A XDA pages too. Not too much out there except how to encrypt your emails or sms. I'm going to go off the grid and look into some other sites and see if they have anything.
I'll get back in a few days to share what I have found (if anything).
Agree, it shouldn't have anything to do with MTP or mass storage. First of all, when my movinand failed it was totally at random, and secondly, USB mounting (whether MTP or mass storage) accesses mmc0 on the filesystem level. It doesn't even access at the block level (since /data is also on the same block device), much less the SD/MMC hardware interface level.
While it may not make sense; there is a pattern of failure following connecting with MTP on the next reboot. I can think of 5 users that have described this exact scenario plus myself; this is the best theory I've heard.
I believe it enough that I am back running ICS on another Captivate, just not using MTP; working great so far (that knocking sound you hear is me knocking on wood
).
It's using USB Mass Storage when I connect to my PC.
Similar threads
Top Liked Posts
-
There are no posts matching your filters.
-
40Note: This guide is geared toward the Samsung Captivate. If you have a different device, try your device's forum, or search this thread.
Are you using ICS and pulled your phone out of your pocket only to find that it had this screen, saying "Encryption unsuccessful" and your only option a button that said "Reset Phone"? Don't press it! Try rebooting a few times with your external sdcard out first. Sometimes that will fix the issue. If not, take a deep breath and follow the guide below to get your phone usable again:
Too late? Already hit the button? Then you know this screen:
Here's the bad news:
Your partitions for /data and /sdcard are no longer accessible. Latest news points to a bug in the firmware for the memory card in your phone. ICS uses a new function that doesn't work correctly with the affected phones.
Good news:
I found a *workaround* to get my phone to at least work again. Note: You will need to perform steps 9-11 every time you flash a ROM or ROM update, because flashing overwrites the vold.fstab file.
Here were my steps to get your phone working again:
- Realize that you may have just lost whatever was on your sdcard and it's your own fault. For me, this was acceptance that *I* installed ICS on my phone and now CWM backups, photos, and more were gone. Once your realization has set in, move forward.
- Acquire an micro SD card that you will put into your phone. This will contain your new /data partition as well as your new /sdcard partition. I recommend at least 8GB. If you already have a card, backup whatever is currently on your micro SD card - you *WILL LOSE* everything on this card in the next few steps.
- Boot into clockwork mod, using either 'adb reboot recovery', or some other combination of buttons.
- Partition your mircosd card through CWM. This will be 'advanced' then 'Partition SD Card'. The first size you choose will be the size of your /data partition. I have a 16GB card and chose 2GB for /data. This will leave me with (16GB-2GB) 14GB for /sdcard. You can choose a different size if you like, depending on how big you want your internal data partition to be. Choose 0M for swap. This process will take a few minutes, so keep waiting, you impatient jerk.
- Download the latest build of ICS for your phone and put it on your micro SD card. (You can mount it to your computer at this point in CWM with 'mounts and storage' 'Mount USB storage')
- Create a full backup. Just in case. Put it on a computer, dropbox, whatever. Your phone isn't a safe place for backups.
- Wipe user data, cache, & system. Now install the ICS package you just put on your card and reboot.
- The first boot will take a while, as all first boots do, but after a while you should be back in ICS. Exhale (If you're not exhaling at this point, post something in this thread and I or someone else will help get you running)
- Check Settings > Storage and see if your new /sdcard partition (For me it was about 14GB) shows up as 'USB Storage' or 'SD Card' If it's USB storage, then your micro sd mounted to /sdcard successfully and you're done. You should be able to take a picture and have it save. If not...
- Edit etc/vold.fstab with whatever you use personally (root explorer for me) and swap paths for /emmc and /sdcard (the part that starts with /devices/platform...). Someone more intelligent than me can probably make this a CWM zip. This step is telling ICS to swap your /sdcard (broken internal sdcard) and your /emmc (working external sdcard). It will probably look like this when you're done:
Code:# internal sdcard that is no longer working dev_mount emmc /mnt/emmc 1 /devices/platform/s3c-sdhci.0/mmc_host/mmc0 # external sdcard dev_mount sdcard /mnt/sdcard auto /devices/platform/s3c-sdhci.2/mmc_host/mmc2 - Reboot with your new vold.fstab and check your storage amount in ICS and test your camera (easy test to see if Android can write to the sdcard). Hopefully now this is working for you.
Let me know if you have any questions or (hopefully not) problems!
Notes for myself and devs:
ICS is a lot pickier about mounting filesystems, and if it can't mount /data correctly, it assumes it is encrypted. It really isn't, firing off https://source.android.com/tech/encryption/android_crypto_implementation.html an misleading encryption message.
In ICS and in CWM, when I look at /dev/block/platform/ I only see s3c-sdhci.2 and s5pc110-onenand. The s3c-sdhci.0 block is missing completely. I'm not sure how to even touch the /data or /sdcard filesystem at *ALL*
Oh well.16May have found a glitch solution, or an anomaly
Uhhh guys, I had something weird happen... I encountered the dreaded encryption unsuccessful message over a month ago. Since then, I used this OP to create a partition on my external sdcard. Anywayz, I was experimenting with a B7 version kernel I kinda edited, (just placed the boot.img i extracted from Doc's Master Rom and put it in a B6 zip). It resulted in having all the B7 settings, but the clockwork recovery looked like normal cm9. Well, today, I was going to flash a gps fix zip, so i go into recovery and to install zip from sdcard, and I saw all of my old files!!!!!!! They are still there!!!! So I reboot, and it says that its upgrading, like i wiped the cache or something, and when I fully reboot, I get some conflicts and apps not working (also wifi not working). I then reverted the etc/vold.fstab to what it originally was and rebooted. My old stuff is back! My phone was borked over a month eazy, maybe 2. But this may mean its a software access problem, but all my files are back, that may mean that all phones data is recoverable!!! I will update with any new info i get.
edit: wifi working again too
on i897 bootloaders
Slim 3.513In another thread, they found the cause (and a potential solution) to seemingly the same issue we are having. The issue was acknowledged by sprint, samsung, AND even google. Everyone was involved because devolperes were trying to contact everyone so the bug information could reach the proper place to get corrected. This bug was even present in OTA ics releases. More on this later since there could be two different bugs (or maybe they are the same bug). This effect of the bug depend's on what EMMC firmware the phone contains. We have the fireware that locks up the card.
Here is my summary on all the information I have read scattered EVERYWHERE on the issue. I hope it helps some dev. I do not have the knowledge to further apply it.
The Issue:
The issue we are seeing is that the EMMC is locking up when being accessed. This happens only at certain portions within the EMMC card.
The Cause
The lockup is happening because of a wear leveling algorithm bug inside the EMMC firmware.
Some background:
Inside flash memory, each bit can only be written a finite amount of times before it goes bad. Because of this flash manufactures spread writes all around the card to level off the wear and extend life.
Inside conventional harddrive's writing new data by rewriting existing data or writing the new data to emptied (zero'd) data happens at the same speed. But inside flash memory, it is faster to write to zero'd data than existing data. The issue now is wheter the OS should handle where all data is exactly written to, or will it cooperate with the embedded controllers and let some operations occur low level.
Developers have found that the issue is most likely coming from the kernal changes in ICS that deal with how files are deleted on the EMMC card. The kernal itself is not buggy but the low level firmware in the EMMC card that handles file operations is.
It is speculated that the TRIM command and even the MMC_CAP_ERASE command are the ones triggering the issue. Older kernels such as (GB, etc) didn't support these commands.
It is also said that the I9100 ICS kernel doesn't support the TRIM or ERASE commands either. Mabye for now we should try switching to this kernal for our ICS builds?
The issue expanded
It is said that on EMMC cards that have firmware 0x19 (hexadecimal), that when the commands above are triggered they have the potential to lockup/brick the card. We are not sure what is causing the lockup.
For EMMC cards with firmware 0x25, samsung has coded up a fix to take care of the locking up issue but on this firmware version a potential for data curruption (on the order of 32KB) each time still remains.
Yet these two seperate bugs may be one and the same. It could be the but it is speculated that critical data structures on FW 0x19 are being overwritten by the 32kb of zeroes and that is why the card locks up. They data structures are not overwritten by the kernel but by the low level controller due to a bug.
We are not sure if it is the same issue in both 0x19 and 0x25, but for now we know that 0x19 locks up with those commands, and 0x25 has the data curruption problem.
Here is a link the FW 0x25 patch provided by an engineer from google, but was coded by an engineer from samsung to fix the 32kb of zeroes issue. This cannot be applied to our 0x19 firmware version since it was coded specifically for the 0x25 firmware. Possible black hole, phone blowing up, but most likely it just wont work.
https://bitbucket.org/franciscofranco/android-tuna-omap/changeset/cea631bdac53
Seemingly, we just need to disable the commands to stop the issue. That or samsung fix their damn buggy hardware or invent a workaround in the kernal.
Google says from their side, all of their code is okay and this mess is a result of samsung's buggy hardware.
Furthurmore this issue has been pushed closer to attention to samsung and sprint. It has been brought to their attention that large files operations on OTA ICS builds such as wiping from recovery manager could also brick phones. This is because these operations execute the same commands. Sprint/Samsung has developed another patch (maybe the same one from before *I don't know*) and tested with it a batch of phones with it.
Samsung/Sprint have tested 20 devices. 14 were with the patch, 6 were without. All 14 with the patch passed. Out of the 6 without, 4 of them bricked. All of them bricked since the error does not happen everytime the command is ran. It was done with sprint since the patch was for their epic 4g. They have been suffering from the same issue and bricking before us.
... Final words...
I see all of this is a lot of progress from and a lot of positive information compared to our lack of knowledge before. It could be that we suffering from the same bug and we are seeing it officially being fixed on some models. I hope we can learn and apply their fix.
It could be the same issue. What is see is that we are wiping using our safe non trim/MMC_ERASE commands. We are then installing the new kernal with the buggy commands. The google dev said that curruption happens in the /data location since it is the most used. It could be that its the 32kb of zeores at the wrong place locked up the card. Or something else to do with those commands locking up the card.
On a positive note, the google dev said that he has fixed the 0x19 firmware card by doing a full wipe but he cannot release his fix without authorization since it is proprietary information. Presumably to fix, we would have to make the card enter some special vendor mode, and clear EVERYTHING, then blast it with a working flash configuration.
I hope we can learn from the sprint/samsung released patch. Or maybe even the earlier released patch by samsung to google.
For now, lets try using I9100 ICS kernals. (or is that what he had the whole time).10CM9 with /data on the external SD working!
Hi,
finally got the time to modify and compile CM9 to use /data on the external SD. I've just installed my modified CM9 running with /data on a partitioned SanDisk class 4 SD card with good performance (off course slower than from the internal SD...)
To those of you that have not been following this very long thread I proposed a workaround to avoid crippling our phones with ICS: forcing CM9 to use /data on the external SD instead of the internal. In this way I hope the EU bug will corrupt/break the external SD instead of the internal. Considering that my patched CM9 does not even mount /data on the internal SD and mounts the external SD FAT partition as /sdcard, it does not even require the internal 16GB FAT partition... well in theory it is less likely that the EU will kill the internal SD...
Tomorrow I will post a new thread with the hacked CM9 and some short instructions to make it work. Keep in mind that I have no idea what I'm doing since I'm not a developer and I've asked around, but I did not receive any technical feedback so far.
The sad news... it is not possible to use any other kernel with my modified CM9 because AFAIK the mapping of /data -> external SD is part of the kernel boot.img... In theory it is possible to extract from a boot.img file the init.rc file with the mappings and modify it, but I have not idea how (some help devs?). Well, if we can solve that, I can write a shell script to convert any(?) ICS based rom or kernel and modify it to use /data on the external sd.
Going to sleep now10
I cannot agree more with this post and many levels.
Once the gravity of this thing hit yours and our sides, I put a BIG FAT WARNING in my ICS install guide about it and links to this thread and on on our side. There are only a handful of ROM threads that have it acknowledged in their OPs in the Vibrant fora.
I was thinking about compiling all our data and the stuff recently found out about TRIM,...and the things in KRock's [REF] thread and putting it together and submitting it to an XDA news writer to see if we can get something on the front page. Maybe someone out there who hardly ever reads the Cappy/Vibrant General/Q&A threads will see it and something wil go off. We have so many bright people working on this but we just can't get past the one thing that is eluding us. If we could catch a break somewhere, I have no doubt that it could be fixed. I mean isn't that what XDA is all about?
What do you guys think about something like that? We could take all our info and dump it on them and they could write about it or we could write it and show our references (flashback to my college days).
I have no problem writing it if you want but it is going to take some time to compile and I am sure I will miss something here or there. You could PM me post links and a *short* reason why you are sending it and then I'll put it all together and PM out for proof-reading. Will/could take a few weeks or so bc of my schedule but at this point we need more exposure. if anyone else wants to do it by all means but I agree with swayjd, it is time to get it more out there. - Realize that you may have just lost whatever was on your sdcard and it's your own fault. For me, this was acceptance that *I* installed ICS on my phone and now CWM backups, photos, and more were gone. Once your realization has set in, move forward.
