yashsingh1/xdaforums huggingface dataset:
[Captivate Android Development] RootTheMachine:
I really may not know what I'm talking about but... in this link posted by CyanogenMod a few pages back, do you think we can prevent the error from happening by removing the lines of code that trigger the false encryption state? I think it could probably be done without breaking encryption altogether. I would attempt it myself but I don't know exactly what to do. I have never even heard of "builtins.c" or have any idea where it belongs.

However, it is also remotely possible that the phone may end up being screwed over even without the phone ever thinking about encryption. Meaning something still might be caused to fail with ICS, with or without encryption.

And again, this is running away from the problem. It doesn't solve the issue, it only prevents more from getting it.
[Captivate Android Development] chavocarlos:
I think that line 431 and line 455 are critical, I should avoid this condition, I will prefer to never go inside this condition block and have to restart the phone, against has marked as encripted and screw my phone...

Anyways, only an idea, I am not Android developer, only Java and web developer, I suggest too this idea pages back.

I think that Cyanogen people knows this behaivor but for some reason is still there.
[Captivate Android Development] DaNaRkI:
After reading about MTP and how it is supposed to work. I see nothing in MTP that can possibly cause this. Nor anything in how MTP is expected to behave, since by design the OS is reading and writing to the memory exactly the same as it does in any other situation. The whole point to MTP being the new standard is so Android never gives up control nor access of the memory to any other device. (tho I do wish there was something about it and how exactly android employs it on their website...)

If anything, MTP

should

make something like this happen even less, MTP is a virtual state. It allows Android to communicate with other devices without causing any change to its internal behavior. Unlike USB mount which causes Android to break a number of internals so that the memory can be accessed by the PC.

Would do nothing what so ever. Assuming that everyone is getting stuck at the state that raz123 is, then there is nothing you can do to any part of the phone to fix aside from directly talking to the memory chip (something like a j-tag but your connecting to a different memory chip, one that does not have "easy-access" pads)

There is no reason to break encryption nor to alter any part of how it functions. The whole boot-up is a hands off approach (since there is nothing Android can do to an actually encrypted phone). We have already moved well past the point, the only relation that this issue has with encryption is that it is the first and only indicator that we have telling us the memory chip is not functioning properly.

Personally after all I read, I don't understand why we still have the option. MTP should be the only condition. I'm still waiting to hear about how other phones that are getting a "proper" ICS update behave. Will/Do those phones still have Mass Storage mode? Will/Do they still have a hard partition between app storage and "internal SD." I've asked a few people I know who are running leaks of ICS updates, but I've not gotten an answer. Plus, I'm waiting for a real 100% official update, I wanna see how the manufacturers deal with a problem they created.
[Captivate Android Development] s0ul_ali:
Lots of efforts by many peoples, but still no solution. When I had this issue I was asleep. I probably slept over my phone. Last time when I sync to PC was 14/16 hours before. I think most people faces this issue there phones were in pocket or in bag. There might be some thing related to light sensor or my be motion sensor. Or it could be extra pressure. this issue is more on ICS what is failure rate of internal memory chip? What message did people gets if there internal memory chips fails on GB ? We have to look deeply weather its hardware failure or created by ICS.
[Captivate Android Development] RootTheMachine:
It was never present in GB. Unfortunately I don't think any of those conditions would be factors in this

Sent from my ICS Samsung Captivate
[Captivate Android Development] brandon_L:
My captivate has been running just about every ICS rom out there and it's fine. My Kindle Fire on the other hand is another story. Been running a CM9 rom on it for a couple of days and today I had the encryption fail message. Rebooted into recovery factory reset and flashed another Rom. thankfully it seems to be working now. Just wanted to let you know this is happening every where!
[Captivate Android Development] octavia:
Thank you for your guide, I did everything and I guess it worked but there are a few things I don't understand. For starters, I did partition my card from CWM (a 16GB card with ~2gb/~14GB). So, I now do have /sdcard and /emmc on the root folder, but on Storage, there are only 2 items:

Internal storage with 1.88GB and USB storage with 12.92GB?

What does this mean? On sdcard, I see the contents of my external sd card but then since my phone still doesn't read my internal card, does that mean that it's lost for good?
[Captivate Android Development] yosup:
Those are the partitions you created on the external sdcard - ie. essentially the same configuration that was previously on your internal.

For now, most likely that data is not recoverable ... unless someone figures out how to reverse the situation. Woodrube is trying to see if he can at least access the internal sdcard and somehow format & re-use it. No promises, but a lot of people are putting their minds to it. Fingers crossed. :D

Btw ... the EU can happen again. The method in this thread is just a means to cope with it, but there doesn't seem to be a sure-fire way to necessarily prevent it (for now). Some good tips discussed here which may help minimize the threat ... but in the meantime, keep your data backed up! Cheers.
[Captivate Android Development] yosup:
My situation was odd, but the screen dimming actually did occur during the Boot Animation (ie. Annex's Enkyo BA is too distinctive to mistake).

I was doing the usual email / web / Tapatalk stuff. Put the phone down on my desk. After a bit, I looked over and noticed the dimmed BA screen - ie. I had never rebooted the phone during this sequence of events (and have no clue what actually triggered a reboot then).

Unfortunately, I can't specifically recall if the BA had actually locked up. Either the screen was too dim to tell (or I just didn't think it important enough to scrutinize). So, in my haste, I just held down the power button to reboot the phone ... then eventually (during the reboot sequence) I got the EU screen.

I don't ever recall the BA screen dimming during normal operation - ie. even during the long startup required after flashing a new rom. In hindsight, it would have been nice to test out Woodrube's suggested battery pull. Lol, maybe it could've at least given me "one last look" at that internal sd (so I could have at least backed up all that goodness). :rolleyes:
[Captivate Android Development] mr_psycho:
Not to wish any ill-will to anyone that has already suffered at the hands of this bug, but I'd be interested in seeing the issue happen to an /emmc card. At least, you can physically remove the micro sd card and check the file system or partition's integrity and see if/how the structure is changed, preventing access.

I'm thinking that might yield some sort of important information, considering the Nand chip is not removable for further analysis. Unless the issue is at an even lower level than the physical sd card.

MP
[Captivate Android Development] azunino:
Hi,

Would it be possible to apply cgugino's workaround before installing ICS and having the encryption unsuccessful problem on a fully working captivate? My theory is that if ICS does not see/touch the internal SD ever (including /data), it would be safer to try ICS without risking crippling our captivates, at the expense of slower I/O (depending of the external SD speed). The encryption unsuccessful bug may still occur, but considering ICS will not mount the internal SD, the bug would only corrupt the external SD and a complete reformat/reinstall/restore would fix it.
[Captivate Android Development] yosup:
Well (God forbid) if lightning strikes twice on me, I'll ask you for direction on doing the analysis. Great suggestion, btw.

There's a guy in Merio90's Vibrant thread that actually did get hit with EU again after doing the fix. Granted, at that point, it's just lather / rinse / repeat - ie. format the card and do the fix over again using the same external card. So the trauma-factor is substantially mitigated. Lol.
[Captivate Android Development] swayjd:
So it can actually be used as prevention? well hello ICS again!
[Captivate Android Development] Woody:
So now the tally is up to

Captivate

Vibrant

My wife's Nook Color

Transformer (OG) TF101

Transformer3g TF101g (got hit yesterday)

Kindle Fire

any more?

Arrgg!!!

I think that MP might be on to a better way of analysis. If someone gets tagged AFTER they do the workaround, it would be benifical bc the error would get thrown on the External SD and therefore an img could be burn and passed around for further review, as opposed to the whole dang phone. I think a calling all cars type thing could be issued for anyone that is using this workaround to save that card before the reformat it.
[Captivate Android Development] yosup:
Lol, definitely not prevention.

Rather, the guy I mentioned had it already happen to him ... and then happen again. So it's quite after-the-fact. I was just kinda joking that once you go through it, it gets easier to deal with (and hopefully you come out smarter about backing up your sdcard data). :D
[Captivate Android Development] yosup:
Yikes ... that's one ugly looking list (scary)!! :confused::eek:

( With the exception of your wife's Nook, of course ... :p )
[Captivate Android Development] azunino:
Well, may be a preventive measure, because if the internal SD card works and ICS never uses it because the mapping /data /sdcard -> external SD is performed before flashing ICS, the nasty encryption bug would only affect the external SD, leaving the internal SD intact. Is this correct? :confused:
[Captivate Android Development] swayjd:
I mean, doing the workaround BEFORE you actually get the problem.

As safety measure. It can strike the sdcard but who cares, rather have the sdcard formatted than have my phone go to ****.
[Captivate Android Development] FocuseD83:
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. :eek::eek::eek:

edit: wifi working again too

on i897 bootloaders

Slim 3.5
[Captivate Android Development] silvertag:
So you edited the kernel or just passed the B7 into the B6 update zip ?
[Captivate Android Development] FocuseD83:
Just placed the boot.img from docs rom on a b6 zip
[Captivate Android Development] Woody:
Bet he was like WTF!!! Wonder if he is making a backup? Out of thanks for the day but he should get some when I get them back.

Definitly need more info but this is great news. I am about to crack the Encryption Key with some code I found this morning, but if I don't need to and it is as simple as a kernel splice, that would be awesome. Also found out that it could be a simple init script not running e2fsck or fsck at boot.

Excuse my ignorance about kernel building but waht is B6 and B7?
[Captivate Android Development] daskanda:
Glitch kernel beta 6 and beta 7....beta 7 is not officially released so doesn't have a themed recovery yet and is only in the aokp ROMs and some others that extracted it from that rom like docs rom
[Captivate Android Development] b-eock:
Well the testing b7 does have a glitch recovery :D
[Captivate Android Development] FocuseD83:
Yes I was like WTMFIGOITB (you don't want to know the translation)... Creating backup and putting in cloud now... Hope others can have success! :D
[Captivate Android Development] jmtheiss:
I'll handle the translation:

WTMFIGOITB = Well then, Mr. Flapjacks is giving out internet tacos, baby!

Don't worry - people understand that sometimes you just want some Taco Bell.
[Captivate Android Development] melvinaury:
LOL
[Captivate Android Development] silvertag:
Care to upload that magic zip file here ? ;) for the moment it looks like its the best thing since the OP workaround.
[Captivate Android Development] silvercrown266:
Good news! Not too bad after all :D
[Captivate Android Development] FocuseD83:
Don't wanna piss any devs off by posting a version of their kernel without permission. Just do what I did (for now at least). ;) Interested to see if others can get theirs working too.
[Captivate Android Development] silvertag:
So that would be taking Doc's Master v10.5 boot.img (or AOKP M5 boot.img) from the rom and overwriting IcyGlitch B6 boot.img correct ?
[Captivate Android Development] FocuseD83:
yep
[Captivate Android Development] Nirmalspeed:
Any way to port that fix you found to the vibrant? I still miss all files I didnt have backed up :(
[Captivate Android Development] DaNaRkI:
Again going off what raz123 has given us as the "worst case." Then it would be sub-physical, the center of the problem in raz's case is that the memory chip does not finish its own internal prep process. Until it does no one can get anything out of the memory chip / SD card unless they were to literally rip the chip/card open and bypass the internal control circuitry (like opening an HDD and taking out the magnetic disks).

Then flash back the old setup, tell us you lost access again; flash an even older one and tell us you still don't have access. Then flash your custom set and tell us it's all good.
[Captivate Android Development] swayjd:
This. Am finding it hard to believe that a fix appeared randomly. Thinking it was just sheer dumb luck.
[Captivate Android Development] FocuseD83:
I said possible fix... It worked for me so why not try it? No way am i gonna do some of these "tests" that you all want me to do, this is my daily use phone. Bork my phone again on purpose? WTF are you talking about, no way... Just thought it might he helpful to others... Maybe devs can use this info.
[Captivate Android Development] Woody:
Maybe you could give a bit more info. Like what ROM/kernel were you running when you got the error (if you can remember). Was it B6 then? Was it another kernel? Did it have a custom recovery?

We would just like a little more info. Not that we don't believe you, but we are trying to recreate this and how you did it so that a fix can be implemented. And I am in no way wanting you to re-bork your phone, just you are the only one that brought it back from the dead or rather coma. That's all and welcome back.
[Captivate Android Development] FocuseD83:
I think i was on Slim 3.0 using Semaphore 1.0 scbm.
[Captivate Android Development] silvercrown266:
Agree!

@FocuseD83:

You don't need to defend yourself if you are on the side of truth...

Just provide the simple steps you took to get it working... This is a fix thread anyway...

What Rom & Kernel are you on when you do your fix?

Make the steps of your fix more detailed... Giving short answers doesn't really help... Every 1 short answer you give tens of questions are coming up...

So, a detailed process/ steps of your fix will greatly help...

Thanks!
[Captivate Android Development] DaNaRkI:
But that's what xda is for. Once you've made a copy of the internal memory, you've got nothing to lose.

I suspect that: A. You won't mess up the phone. or B. Within the next few weeks "it randomly rebooted and I got that screen again. Back to using the external..."

...darn xda app update went and changed things unnecessarily!
[Captivate Android Development] Woody:
Not to go too far off topic but the XDA app now shows the tapatalk icon (no biggie you can always change it ) but you have to reenter all your settings again including save folder, jump to, posts per page, ... At least with this update your faves are still there unlike last update.
[Captivate Android Development] FocuseD83:
There wasn't any type of process... As I stated in the previous in my first post in this thread, I was just going to install a gps fix in clockwork and went to install from the sdcard and my files were there. The phone was borked for almost 2 months and files were still intact. I had been using the modified glitch kernel for about 1 week, don't think i flashed anything in between the time i flashed the kernel and the gps fix. 1007 version cappy. Am on Slim 3.5 now, was on Slim 3.0 when it borked. If im not mistaken, was on Semaphore 1.0 scbm when it borked.

Another thing, was playing with the voltages and overclocking aggressively with a lot of reboots prior. That may play a factor. Since then, I've backed up my files, created a nandroid, and put my titanium backups in a cloud. Also, did a factory reset and just finished restoring files on my internal sdcard. Working perfectly now.

---------- Post added at 04:36 AM ---------- Previous post was at 04:27 AM ----------

I've got 16 gigs of space to lose dude. Just got it back. If it is gonna happen again, it's not going to be because I forced it into borking itself to prove a point.

Truth is I don't know how it came back, just trying to let people know what I did different prior to me recovering my sdcard data... Hope its helpful to someone.
[Captivate Android Development] Demetris:
Hi,

I try to EU again from internal SD card, success!

Aokp build 27 and replaced boot animation.zip with a 16mb instead of just 3mb that has already in. Boot and as boot animation was loading it dimmed my screen , like a faint black over it but never black.I think the back light went off and then the great EU came over once again.
[Captivate Android Development] AdamOutler:
On my Glaxy Nexus, if it's OEM locked, it will display that laying down android screen. Is it possible to use fastboot on the Captivate? Fastboot OEM Unlock will wipe the SDCard and all other data.
[Captivate Android Development] silvertag:
There's no bootloader mode or i can't find it. I tried "fastboot devices" in multiple modes but no dice, it could not find the device. Tried the bootloader reboot from the rom menu and it just rebooted into normal mode.

Edit: Same for adb reboot bootloader it just reboot into normal mode so no its not available on the Captivate.
[Captivate Android Development] b-eock:
No, fast boot cannot be used on the Captivate. The bootloaders don't contain fast boot, neither does the kernel. So fast boot is outta the question. What about the uDroid bootloader development? Can that be of any help to build fast boot bootloaders for the Captivate?
[Captivate Android Development] Woody:
Hi Adam,

No fastboot for Vibrant either. Think that is a Nexus-type thing obviously with the GNex but the Nexus S has it too.

Seems we might have a possible fix in the works as one user was able to recover all his data back, but the reasons for it are vague right now. Not sure if you have been following this thread or not but the error has hit Cappys, Vibrants, my wife's Nook Color, a few Asus Transformers and a Kindle Fire. I was able to bring my wife's NC back as it has the ability to boot from the removable sd card. Actually I was able to repeat the error over and over on her NC.

Another fix I am working on would destroy the enryption completely but also any data on the internal would be lost. Obviously data preservation is what we all want so the one user who was able to get his back, we'll need to find out how "exactly" it was done. My method involves ADB and e2fsck, fsck and cryptsetup wiping the encryption key, then remounting the internal and repartitioning through normal methods.

Still researching the ADB way for now, so if we can figure out why the changing of the boot.img fixes some, that would be ideal. I am now leaning towards some sort of CWM mismatch but still not sure about that. Maybe something with the "Touch Recovery" or possibly something else in the kernel. Not too long ago there was an issue with not being able to make a back up correctly with and ICS kernel, but it was found out later on that the kernel was breaking that ability in the init scripts. Not sure at this point but we are all working on it and would love to have you involved.

Wood
[Captivate Android Development] silvertag:
Adam, do you by any chance still have that bork phone that was sent to you ?

If you do, it would be a good way to test the new kernel revive that FocuseD83 found.

Simply use the latest aosk boot.img and insert into the IcyGlitch B6 package and flash away on the phone. This hopefully should revive the internal SD. Then restore the standard vold.fstab for full usage of internal sd. (If external sd workaround is applyed)

If anyone with a bork phone wanna test and report back it would be appreciated alot.
[Captivate Android Development] RootTheMachine:
Wait, can you explain this more?

Sent from my ICS Samsung Captivate
[Captivate Android Development] azunino:
Is it posible to use heimdall to flash a filesystem image to the internal SDcard? This could be a different way of wiping/initializing the SDCard with an empty filesystem and fixing the problem.

I have seen the --movinand <filename> parameter in heimdall, but I've found no documentation about it.
[Captivate Android Development] Woody:
Can't mount the internal. If we could do that, then this thread would be a lot shorter. ;)
[Captivate Android Development] Demetris:
What you didnt understand?

I replaced bootanimation.zip after opening the rom with winrar but with a bigger size, it was 3mb there i put 16.x mb bootanimation zip.

After flash that internal sd card corrupted :), so EU came up.

P.s.

Internal i mean external sd after the fix becomes internal. Hope you understand.

Fix: Remove from Phone, put into sd card reader, sd card formatter v3.1 all back to normal.
[Captivate Android Development] azunino:
I know that. However, heimdall does not require the filesystem to be mounted. In fact, heimdall does not even rely on the linux kernel installed on the phone, but only on the Download Mode. This may be a significant difference because on devices with non readable SD cards it is not possible to access the /dev/... of the internal SD and mounting is obviously not an option here.

From what I understand, heimdall is the Samsung "equivalent" to fastboot in other devices and it provides the support to flash filesystem images to SGS devices with working or non-working ROMs.

My question is: Can heimdall flash a filesystem image on the internal SD card?

Thanks for reading
[Captivate Android Development] silvertag:
I think the best person to respond to that would be the heimdall creator himself Benjamin Dobell.

http://www.glassechidna.com.au/