[Guide] Encryption Unsuccessful - Reset Android [ICS Issue]

Note: 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:

1. 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.
   
2. 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.
   
3. Boot into clockwork mod, using either 'adb reboot recovery', or some other combination of buttons.
   
4. 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.
   
5. 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')
   
6. Create a full backup. Just in case. Put it on a computer, dropbox, whatever. Your phone isn't a safe place for backups.
   
7. Wipe user data, cache, & system. Now install the ICS package you just put on your card and reboot.
   
8. 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)
   
9. 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...
   
10. 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

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

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

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

As I mentioned in the previous post, firmware rev 0x19 has a bug where the emmc chip can lockup after an erase command is given. Not every time, but often enough. Usually, the device can reboot after this, but then lockup during the boot process. Very rarely, it can lockup even before fastboot is loaded. Your tester was unlucky. Since you can't even start fastboot, the device is probably bricked. :-( If he could run fastboot, then the device could probably be recovered with the firmware update code I have, assuming I can share it. I'll ask.

Click to expand...

Click to collapse

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

CM9 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 now

swayjd said:

I think we should find a way to raise awareness for this issue. tons of people running around completely oblivious of how serious this is.

I used ics for a couple months before learning about this, quickly rolled back cause I'm not one to play with fire.

ROM threads have the responsibility dump in big bold letters as we all know, but they all know about this and it seems they chose to close their eyes to it hoping it goes away. A simple warning would hurt their downloads but would do wonders fire their character.

Click to expand...

Click to collapse

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.