yashsingh1/xdaforums huggingface dataset:
[Captivate Android Development] robm1911:
As being one of the last GB ROM's for the Captivate still in active development Legend has seen a large increase of downloads over the past month and also a few comments on the thread on coming back to GB due to the EU issue. Just sayin
[Captivate Android Development] azunino:
/data on the external SD on non broken devices

As many of you have said, this bug has gone too far and the only way to prevent more crippled devices is to get a post published on the XDA news page. English is not my first language, but if I can help I'm more than willing to do so.

Despite the gravity of the EU bug, the short time I used ICS (AOKP) it was fantastic, but thanks to this thread I downgraded to CM7 before being hit by the EU bug. I've been wondering if there is some workaround, as the one that cgugino posted, to install ICS on non crippled devices that prevents the consequences of the EU bug. In other words, is there any "hack" to force ICS to use /data on the external SD (even when the internal SD is just fine)?

From the little bit I know about Android the mapping of /data to a partition is configured, for the case of CyanogenMod at least, in each platform init.<device>.rc, which in SGS devices is init.aries.rc (https://github.com/CyanogenMod/android_device_samsung_aries-common/blob/gingerbread/init.aries.rc). If a device internal SD works fine then mmcblk0p2 is the internal SD ext4 partition, otherwise (device with internal SD hit by the EU bug), mmcblk0p2 is the external SD ext4 partition. If we can force mmcblk0p2 (or /data?) to get mapped to the external SD for devices with internal SD working OK, I think it may help us both using ICS with less risk and also getting more information about the EU bug, because if it hits a device with /data on the external SD we may at lest reproduce the bug.

Sorry if this seems obvious/trivial for all you who are very experienced on Android, but I'm just trying to help.

Alex
[Captivate Android Development] fuloplori:
Hey guys, wanna ask if there's anyone who has been hit over on miui ics so far? They use the same kernels as in cm so I figured it's the same situation, somebody pls correct me if I'm wrong, thx.
[Captivate Android Development] vibranturk:
I definitly remember someone hits EU bug when he was a ICS based MIUI V4 rom...
[Captivate Android Development] swayjd:
Should you find the way, be sure to let me know. Very much interested in this.

a couple weeks back someone mentioned that a user did this on vibrant iirc, I suppose it is doable.

Side note/rant/vent:

In retrospect, given even friggin CM himself was here and nothing came out of it, we are probably pretty effed if you ask me.
[Captivate Android Development] freshjr:
If trim and other hardware commands were avaiable, I am confident that samsung did a hack job in those respective kernal's to make those commands play well with their hardware. After all, they have access to all the information and what exactly is happening. Meanwhile we are pushing new builds, with those commands, but they do not play nice with our hardware.

I stand firm believing that the kernals with those commands were heavily customized to work with the buggy hardware.

Quotes from the google dev/engineer confirm these types of happenings. He says he spends more time making sure that his code works with buggy hardware then on the code itself.

Sorry, sprint/samsung did all of that internally and pushed the update OTA. That response I quoted was the response the user got from them when he reported the bug. :/

Unfortunately true, its still a good phone. Mines still in good condition and I have a year left.
[Captivate Android Development] AtoZ0to9:
I think it may have something to do with the BML to MTD conversion....

So has this ever been reported on a phone that came stock with ICS?
[Captivate Android Development] RootTheMachine:
I don't think so, but pretty sure its happened on devices that don't use BML

Swyped from my ICS Samsung Captivate
[Captivate Android Development] stayintwisted:
ok so is this still happening to handsets of build date 1010 and earlier? I just reread the thread and did not see any changes in that,so are the later phones more likely to be safe? thanks in advance
[Captivate Android Development] Threezees:
I wouldn't bet the farm on that. I just don't think anything has been decidedly determined to be a contributing factor, yet.
[Captivate Android Development] raz123:
According to the KLMxGxxExx datasheet, Vendor-specific CMD62 allows for:

1. Boot partition settings

2. Smart Report (eg: troubleshooting info/diagnosis)

I see no commands to clear "everything". That being said, Smart Report could prove useful in informing us about the internal status of the movinand.

The problematic is then:

1. How do you manually interface with the movinand?

2. Will a movinand that does not make it beyond CMD1** (our present issue) respond to CMD62?

Finally, if we manage to interface with the movinand, "boot operation mode" seems like it could be used to recover data from the currently inaccessible movinand:

** See previous post about this very issue.

More info about CMD1, which in our case is constantly busy: CMD1 is a special synchronization command used to negotiate the operation voltage range and to poll the device until it is out of its power-up sequence. In addition to the operation voltage profile of the device, the response to CMD1 contains a busy flag indicating that the device is still working on its power-up procedure and is not ready for identification. This bit informs the host that the device is not ready, and the host must wait until this bit is cleared. The device must complete its initialization within 1 second of the first CMD1 issued with a valid OCR range.
[Captivate Android Development] fagnerkof:
ZOMG

I just took off the sd card from my vib and turned it on just to see if I still get no boot turning on the phone withouth the sd card, as expected when you get the EU error and workaround.

Then, without the sd card, it just booted (I'm using ICZen 1.7) and after the ICZen boot animation, just got the EU screen. Now I will try to connect USB and see what I get without push "reset phone" first.
[Captivate Android Development] AtoZ0to9:
Yea, see what that does, but also, an ODIN one-click is probably a good idea....
[Captivate Android Development] fagnerkof:
Rebooted it 3 times and still getting EU screen. Not sure of what to do first now, an odin or a flashing through CWM. I will trying reboot in CMW first to see what it does.

Right, computer recognizes there's my T959 plugged in, but drive is still inaccessible.

I rebooted phone (without touching "reset phone"), same error.

In CWR, I manage to format /system partition, but format /sdcard gives me an error, and format /data gives error "E:format_volume: make_extf4fs falied on /dev/block/mmcblk0p2".

Mount USB storage also don't work, gives message: "E: Unable to write to ums lunfile(No such file or directory)"

Choose zip from internal sdcard//external sdcard, giving errors "E:Can't mount /sdcard/ // /emmc/"

Since I got nothing on CWR, I odin'd stock JFD. It just took me back to the start, when the phone don't recognizes internal memory. And looks like I will have to flash my ICZen again. Damn.
[Captivate Android Development] AtoZ0to9:
Well you have the fix applied which would mean that trying to access the internal sd is being pointed to the emmc which is removed, correct? therefore neither are accessible through cwm.... think an odin one click is worth a shot...
[Captivate Android Development] dawei213:
Got hit with the EU bug here. Dang it. I wish I knew about it earlier, I would've sticked with gingerbread. Oh well, moving on. Ordering a 32gb micro SD card now.

Hypothetical question. If I flash the another ICS onto the microSD and get hit with the EU bug again, I should be able to just take the microSD card out and format it on a computer and start over again right? Would the encryption lockout prevent any further writes, including formatting, of the card?
[Captivate Android Development] AtoZ0to9:
It only affects the internal SD and you've already been hit... It won't happen to your external...
[Captivate Android Development] melvinaury:
Nope, as you mention you only take out the sd card, format and begin again. It's important to safe guard you're information.
[Captivate Android Development] yosup:
Fyi ... this is from Merio90's Vibrant thread. Viruss57 did get hit with EU again and used chkdsk on his external card - ie. to resume using the external sd without any apparent data loss (in his specific case).
[Captivate Android Development] dawei213:
Right, got that part. But if I reflash on onto the external SD and /data is now the external SD, then the EU bug can potential lock up the external SD.

Ok, that's what I thought but wanted to make sure that I can just format the microSD if it gets locked out. Now I'm making sure to back up my data on a more regular basis. I like ICS too much to go back to any other roms.

---------- Post added at 11:18 PM ---------- Previous post was at 11:17 PM ----------

Good to know! Thanks!
[Captivate Android Development] AtoZ0to9:
It's a longshot whether or not this will work, and I haven't had the EU bug, but I've been able to ODIN back to stock without the battery in... I used ODIN UCKK4 with bootloaders...

Open ODIN, have battery out, insert USB, hold both vols inserting battery to get download mode, remove the battery... download mode stays, and the ODIN flash completed... phone did not reboot... I had to put the battery back in and it powered right on...

Like I said, I have not had the EU bug, but have been able to ODIN with no battery... so since nothing anyone has done so far has worked, it may be worth a shot...
[Captivate Android Development] fagnerkof:
Good lord! I forgot to do an chkdsk.... well, I did all the restore and now I'm using ICZen 1.8. After that, powering on my vib without sd card brings me the EU again. Since that before my phone didn't even boot without the sd card... this may be an improvement. Also maybe I'll try doing what B-Naughty did.
[Captivate Android Development] AtoZ0to9:
It may be worth trying I897UCJF6-final-OCD-REV0 because it has a Master Clear in it to wipe the internal SD... future one-clicks don't have that... Is there such for vibrant?
[Captivate Android Development] OwenW71:
I have been watching these EU posts with growing trepidation. I've been running ICS since the first ROM dropped, and I'm beginning to think I'm pushing my luck.

I did a search on this and found no results, so here goes...What if I switched my Cappy to use the external card before the EU bug bites me? This would let me keep using ICS without the worry of a dead internal SD, and when the bug is finally fixed, I could switch back.

Are there reasons to not switch to external right now as a preemptive measure?
[Captivate Android Development] AtoZ0to9:
Does anyone with a dead phone wanna try I897UCJF6-final-OCD-REV0 with no battery?

Open ODIN, no battery, force download usual way, remove the battery, and click start, once completed, force download again, remove battery, master clear...
[Captivate Android Development] azunino:
I proposed that several days ago:

http://xdaforums.com/showpost.php?p=26593304&postcount=632

The problem is that IMHO moving /data to the external SD in phones with working internal SDs requires a bit of effort and some knowledge. I know almost nothing about Android internals, but from what I read it is necessary to modify at least one file and recompile ICS, which is not that difficult... but I've never tried and I'm not sure that is correct. I've posted here http://xdaforums.com/showthread.php?t=1362092 and in RootzWiki (captivate aokp forum) asking the developers for their opinion, but so far there are no answers. In the meantime I've installed Ubuntu 64 and I'm downloading CM9 sources.

Between us... as far as this bug is not solved I think all ICS based ROMs for SGS devices should use /data on the external SD card. But off course it's just a noob's opinion.

BTW, I'm a risk averse CM7 user missing ICS :-(
[Captivate Android Development] jmtheiss:
Good to see you taking that on.

I would like to propose option #2: A AOKP/AOSP build that has the portion of ICS that allows a partition to be marked as encrypted removed from the code. As I understand it, it's a few lines of code that say, "if the drive doesn't respond in x amount of time, mark it as encrypted". I would like to see it say, "if the drive doesn't respond in x amount of time, mark it as needing fsck and move on" or something like that. If completely removing encryption capabilities would be easier, so be it.

I think that giving the user the information about the loss of encryption capability in a rom and putting the risk into their own hands, but still giving them a safe rom is a viable alternative (assuming the code work isn't a nightmare, of course).

I personally would have no issue flashing a rom know that I could never encrypt a drive if it meant that I would never have to worry about the EU bug.

I throw this out there because I know I lack the knowledge, resources, and time to do this myself. If someone has thoughts on this, I would be very interested in hearing them.
[Captivate Android Development] dougc405:
Encryption has nothing to do with the problem, which is a hosed partition. The EU error is just a symptom that the partition cannot be read.
[Captivate Android Development] jmtheiss:
Understood. I guess the point I was shooting for was that if the EU error (of marking the messed up partition incorrectly as encrypted) is something in the code that falls within the "Encryption" umbrella as a whole, and the only way to effectively remove that piece of code was to remove encryption capabilities altogether, I for one would have no problem with that.
[Captivate Android Development] OwenW71:
Alex,

Sorry I missed your earlier post. I like your thinking on this, just build it into the ROMs until the problem is fixed. Until that happens, I'm still left wondering...

Is there any drawback to just using OP guide to move /data to the external SD before the EU bug strikes?
[Captivate Android Development] azunino:
OwenW71,

Well, I have not tried because AFAIK mmcblk0p2 is the internal SD ext4 partition with /data on fully working devices. The problem is that in order to change that it is necesary to, AFAIK, modify this file https://github.com/CyanogenMod/android_device_samsung_aries-common/blob/gingerbread/init.aries.rc and recompile? CM9. Not sure...

I'm going to try partitioning a micro SD card, but I suspect that on fully working devices with an external SD partitioned as the OP says, the external ext4 partition would be something different than mmcblk0p2, so /data would be on the internal SD.
[Captivate Android Development] millerja01a:
Not specically the EU error but this happened running KK4

My wife has been running KK4 since it's release and had no issues at all.

She let the phone battery die and plugged it back in only to enter bootloop hell. I entered 3e recovery and got all the mmcblk0p mount errors on /sdcard and /data. 3 sleepless days with no joy using Odin, Heimdall, to internal storage and I was able to get her phone active only with CM9 5-23 nightly on her 2GB extsd but there's alot of photos on the internal that we'd love to save.

Guys...is the data unrecoverable from internal storage?:confused:
[Captivate Android Development] vibranturk:
I dont understand totally(my eng is not good) Understand that you want to recover some photos...

There is a pc program named "Recuva"Install it to pc and use it..Maybe it helps...
[Captivate Android Development] brandon_L:
Not sure if this is the same thing?

I have a cappy that was running a KK4 gingerbread ROM. There was no SIM or external SD. Airplane and WIFI turned on. Phone was used for games and surfing.

Today when I turned it on, it went into a boot loop. Pulled battery and rebooted - same thing. Button combo to CWM and data factory reset and reboot - still boot loop.

Tried a heimdall oneclick a KH3 - rebooted - boot loop.

From CWM tried to mount Sd and it failed. Anything having to do with Sd fails.

Looks like there is no way to access it. Is this the same as the encryption issue? On gingerbread?

Anything left to try? This phone has always had problems though. Flashing has always been a challenge, where as my cappy that I use all the time, can flash and run anything without issue. I'm suspecting there may have been issues with this particular phone since the beginning.
[Captivate Android Development] OwenW71:
Alex,

So your thinking is that the procedure in the guide will produce different results if the internal SD is still working? If I understand the logic, even a partitioned external SD will not get the /data directory if the ROM installer is able to write to the internal SD. Only if the internal is completely borked will the installer jump to the external. Does that sum it up?

Has anyone confirmed this?
[Captivate Android Development] crt60:
Try this...

http://xdaforums.com/showpost.php?p=18370912&postcount=3
[Captivate Android Development] DaNaRkI:
Mark it and move on, to what? An empty phone. You'll still need to see an error screen. Else we'll get a lot of "HELP! My phone boots up but all the apps are gone and I can't install anything!" The actual EU screen is nothing more then an image and a button. Changing it or adding another is not a simple task, because it's in bits and pieces throughout the framework.

Breaking encryption, would only succeed in removing the one and only way for us to know something is wrong.

Which would you rather a boot-loop or a screen telling you there is a problem with the memory. Thanks to encryption we have been able to narrow down the issue to the memory chip, and that it's not initializing. Think of how many causes exist that make a phone boot-loop...

-xda app, too lazy for something interesting to say-
[Captivate Android Development] brandon_L:
Thanks for the suggestion, but still can't mount sd
[Captivate Android Development] jmtheiss:
That's a good point, and I hadn't considered that aspect of the issue. I know I'm not well versed in the hardware-software relationships used in Android devices, but it just seems excessive to me that the default action when a hardware issue is detected is to completely and permanently deny access to the device, even if the issue could be intermittent.

Here's an analogy for how I was seeing this whole issue: You own a shed full of your personal belongings, and you've hired a company (Andy, Inc.) to send out someone to watch your stuff and let you put in and take stuff out whenever you want/need to. The shed can only be accessed via one door, and that's the door that the Andy rep is guarding.

In the past, the Andy employees haven't really paid attention to the shed. If one of the roof beams in the shed gave out, they'd notice and tell you (as anyone would be able to see that), but it would take a pretty massive failure of the shed before they would do anything.

This new employee from Andy (Ichabod Sandovich), though, has a background in building design and maintenance, and knows some things about construction.

One day, you come to your shed, and find you can't open the door. You ask the Andy rep what's going on, and he says, "Oh, I noticed that you were using three lag bolts in your main support rafters instead of four, which would likely make the shed collapse. As a courtesy to you, I welded the door shut."

In the past, if the reps thought something was a little wrong, they would just put a note on the door that said that something wasn't right. You could still come in with a repair crew and see if something could be done, possibly getting your stuff out, but not any more.

To wrap this long post up, my point is that I'd like to see if there was a way to get an employee of Andy that doesn't weld the door shut, but puts a note on the door instead so the possibility of getting inside again exists.

I hope that wasn't a completely moronic post. :)

(Oh, and I'm going to do a thanks for you Danarki as soon as my 8 per day limit is over.)
[Captivate Android Development] DaNaRkI:
You've still got it backwards. The door gets jammed all on its own. Think of it more in terms of the lock on the shed, and that different OS versions are different keys. The ICS version of the key is shaped a little different and that causes the lock to get jammed. Once the locked is jammed no other key seems to turn it. Your employee is simply letting you know "something happened and I can't get the key to fit."

For a while everyone has been looking at all the different ways to force the lock back open. Others have been looking at the key to try and see what's different, but it's nothing so obvious. Until we can get the lock back open or can intentionally jam it we can't troubleshoot. In the interim we have had two of the locks free up (again all on it's own). We still don't know what exactly is getting stuck, and we don't have the proper tools to open the lock. xda only has the tools to make keys.

Your company and the guard are getting a bad name, but they aren't doing a thing good or bad.

Note: if you want to get more technical then the system is of key-cards that you swipe, thus the lock is all internal moving parts we can't get to.

-xda app, too lazy for something interesting to say-
[Captivate Android Development] jmtheiss:
That makes a lot of sense. Thanks for taking the time to spell it out.
[Captivate Android Development] s0ul_ali:
my phone is running very slow on external sd card then when it had internal running.? Can make it fast as before ? I'm using 8 GB class 10 sd card.
[Captivate Android Development] azunino:
Good question! Take a look here: http://xdaforums.com/showthread.php?t=1005633

The post is long, but the conclusion is that cheap Sandisk Class 2 or Class 4 microSD cards are the fastest alternatives for the type of r/w pattern Android does on /data
[Captivate Android Development] Woody:
Haha!!! I've posted that link before too.

In reality no external us going to be as fast as the hardwired internal. They are inherently two different types of "cards" and as such they work differently than each other. Both pro and con.

Btw I am still working on a "news story" to get some outside exposure but as I posted earlier, work is hectic and has to come first.
[Captivate Android Development] azunino:
OwenW71,

You are right. The 2nd partition on the external SD is /dev/block/mmcblk1p2 and gets mounted on /sd-ext when the internal SD works.

I have confirmed it.

BTW, the internal SD is faster than any external, however ICS runs fast enough from the external (sandisk class 4) on my Nook. I think that's the point... if we can run ICS with good enough performance, but without the risk of damaging the internal SD... I'll run ICS on my cappy.
[Captivate Android Development] Woody:
Need a Chinese to English Translator

Vibranturk sent me a link from a Chinese forum and it is clear that they are talking about our bug. You can see from the pictures and the limited English text there is. Granted they are talking about the Vibrant, but the bug is definitely the same.

Below is the PMs from Vibranturk and myself with the link. We need someone to translate this. Not sure if Google Translate will work or not on this. Maybe if any users have tablets, those seem to have more international types in them, so maybe we can get someone from there to help us.
[Captivate Android Development] Wakamatsu:
I think I induced this problem on my phone. I was moving several downloaded apks to /system/apps including Handcent. My phone didn't like that and gave me the Encryption Unsuccessful error. I pulled out my battery and rebooted. I tried opening Handcent but it kept FCing. I moved the apk back to /data/apps and the phone has been fine since.
[Captivate Android Development] fagnerkof:
According to google translator, they're only talking about the sd swap workaround, dont seem to know much more than us about this issue now, and using of lidroid rom to do the trick.