yashsingh1/xdaforums huggingface dataset:
[Captivate Android Development] raz123:
I'm a huge android/linux noob, but perhaps I can get the ball rolling for more advanced minds to chime in.

We're fairly certain that the problem we're encountering is a software-based one.

If we knew which file(s) were causing the issue, we could restore their original version and hopefully our internal SDs would be resurrected.

Let's start by trying to tighten the grip on what partition the culprits could be in.

This is the partition table on SGS devices:

Partition	Size	Description
bml1	256 KB	contains boot.bin (262144 bytes), Primary Boot Loader (low-level hardware initialization)
bml2	256 KB	contains PIT file first 512 bytes
[COLOR="Blue"]bml3	10240 KB	/dev/block/stl3 /efs[/COLOR]
bml4	1280 KB	contains Sbl.bin (1310720 bytes) Secondary Boot Loader (loads the Linux kernel and passes the necessary arguments)
bml5	1280 KB	contains Secondary Boot Loader (for recovery, etc)
bml6	5120 KB	param.lfs /mnt/.lfs j4fs
bml7	7680 KB	contains zImage and initramfs
bml8	7680 KB	empty - on Epic 4G and Fascinate, contains recovery.bin
[COLOR="blue"]bml9	293376 KB	factoryfs.rfs ( /system RFS Partition) /dev/block/stl9
bml10	137216 KB	dbdata.rfs ( /dbdata RFS Partition) /dev/block/stl10
bml11	35840 KB	cache.rfs ( /cache RFS Partition) /dev/block/stl11[/COLOR]
bml12	12800 KB	modem.bin

In blue are the partitions that a nandroid backup should restore. Restoring these partitions has not fixed the present issue, according to a member here who has tried it. We can therefore strike out these partitions (bml3, bml9, bml10, bml11).

bml12 contains the modem file, so we can strike it as well.

This leaves us with bmls 1, 2, 4, 5, 6, 7, 8.

If we could have someone here backup these partitions from his/her phone, we could apply them to ours and see if it fixes the issue. If successful, we would continue the tightening process.

It looks like using these commands from an adb shell would backup the needed partitions:

dd if=/dev/bmlX of=/sdcard/bmlX.bak
dd if=/dev/block/stlX of=/sdcard/stlX.bak

*Where X = bml number

So.. anyone has a working Captivate at hand that's willing to upload his partitions? :)
[Captivate Android Development] cgugino:
A slowly mounting partition may be confused with an encrypted one. A mounting timeout may need to be increased.
[Captivate Android Development] cgugino:
I tried reflashing the device with a .pit file that writes these partitions and it did not work. Furthermore, the data and sdcard partition are gigabytes in size and not listed on your table. Lastly, for the dd command to work, we would need to be able to access the output file, which we cannot.

I appreciate you looking into this!
[Captivate Android Development] RichMD:
I'm interested to see if this can be narrowed down. However, if restoring any partition via CWM could work then I would "assume" that a full one-click flash to stock (which repartions with BLs, etc) and master clear (format SD) would resolve the problem - correct? Or, are you questioning if it is a partition that isn't even touched by that process (/efs as an example maybe)?
[Captivate Android Development] jcjcc:
Ah, even s3c-sdhci.2 is gone for me (might just be because I don't have an external SD in though).

I never pushed the Reset button, and also never had an external SD card in my phone at any time... tsk.

If I were to venture a guess, apparently the internal SD card/MoviNAND is not being detected as present ("no media").

--------- beginning of /dev/log/system
I/Vold ( 113): Vold 2.1 (the revenge) firing up
D/Vold ( 113): Volume sdcard state changing -1 (Initializing) -> 0 (No-Media)
D/Vold ( 113): Volume emmc state changing -1 (Initializing) -> 0 (No-Media)

Regarding the partition table posted, I believe those are for the OneNAND (which is working perfectly for us), but thanks to everyone working together to try and figure out a solution.

EDIT: Captivate MoviNAND MBR from an old thread.

http://xdaforums.com/showpost.php?p=7872394&postcount=26
[Captivate Android Development] raz123:
Hey bud. Again, huge noob here, so don't hesitate to shoot down my ignorance ;)

I also did try restoring the pit file and it did not work, but it seems that there is more to it than the pit file.. Indeed, according to z4ziggy: "[...] the pit file which does NOT contain a new partition-table layout. it contains only the partition list (without sizes) – parition id, partition name, partition dump filename"

As for the data and sdcard partitions, I think we'll agree that they're mostly user data and don't contain system-crucial files like the one(s) that might be corrupted in our case.

As for dd, are you certain that we can't get it to output to the microSD using the workaround method you posted?

Yep, the MoviNAND is working for us, but do you not suppose that some of its partitions could contain file(s) that are causing our issue? For example, vold.fstab is present on bml9 (iirc), and that file deals with mounting int/ext SD.

Cool find (MBR). Would have to dump ours and see how they compare.

EDIT: Attached my MBR. Significantly different vs the posted one. Not sure what to make of it nor how to verbalize it.

EDIT2: I guess (need to confirm) that this "MBR" comes from what vold.fstab mounts as the internal SD. Since I'm using the posted workaround, in reality it is then coming from my ext SD. Not sure how this helps our cause.
[Captivate Android Development] jeff.leonard:
Add me to the list of people that got the problem the next reboot after I connected to my PC for file transfer; you may be on to something here.
[Captivate Android Development] silvertag:
Interesting.

Source Android engineer Dan Morril

From the previous test it sounds like the MTP is messing up the system because it's actually touching both partition at the same time and by design leaving them r/w accessible to the device something the usb protocol is not.
[Captivate Android Development] jmtheiss:
To the people who had this happen after mounting via MTP - did you go through all the safe dismount steps (assuming you're in Windows) to disconnect? In other words, did you do the "eject internal SD, eject external SD, disconnect USB storage" steps, or did you just pull the cord?

Just to be clear, I'm asking because maybe there is a correlation between allowing both the PC and Android to disconnect gracefully and the success of MTP transfers.

My thinking is that if Woodrube's information about MTP being a possible culprit is correct, maybe the error occurs when the device doesn't get a chance to properly dismount the volume.
[Captivate Android Development] Wdustin1:
I blame Verizon because the are the only carrier that opted to not include internal storage. They Knew! Lol.

Anyways back on topic I just flashed a custom rom and kernel to my tf101 last night and I did do a file transfer from my windows vista pc to my tablet via usb cord and just pulled the code when complete and I didn't know recieve any errors as as of yet(fingers crossed!) maybe I lucked out very happy to see somebody has a new hunch that hasn't been thought if yet :D

Sent from my AOKP Captivate.
[Captivate Android Development] Woody:
I would just be careful and hold your breath when you reboot (or get a random one that is plaguing out TFs).

Some in my other forum (Rootz) are able to move files in and out but all the ones that they are moving are music, pngs/jpgs, mp4s,...media. When I tried last night to move .apks and .tar (Titanium files) they wouldn't go and the PC threw an error. Think this is where the Media Transfer Protocol part comes in.

Also I always eject the sdcards one by one, as that was my second rule I was taught (first was to back up). I am also getting confirmations that my scenarios was similar to those having these problems, at least on the Vibrant side. Still haven't heard back from the Transformer people yet.
[Captivate Android Development] Wdustin1:
All I transferred was the recovery installer.apk to my downloads folder and I installed it from the tablet. I have rebooted plenty of times since then. But now I'm gonna be worried on every reboot lol

Sent from my AOKP Captivate.
[Captivate Android Development] jeff.leonard:
I have always lived dangerously, I just pull the plug and let it remount to the phone. That may change! I can handle lost data which is all I thought would be at risk, not a lost device.

I'm wondering if this problem could be part of the reason so many of the ICS phones are not coming out with external sd storage.

Lastly, if this new theory proves to be accurate is there a way to change ICS to use USB Mass Storage instead of Media Transfer Protocol?
[Captivate Android Development] Woody:
Grip it and Rip it!!!

Br1ck'd, the developer of the Zen ROM on our side (Vibrant) of the fora, has mentioned that he locked down the Mass Storage instead of MTP via the build.prop. Still though, there have been reports of 2 people that got hit (one had Froyo bootloaders if that makes any difference) with the Zen ROM (AOKP based).

Let's see if this is the cause first before we submit a solution. I'll let you know how it goes and what he tells about it. Still some variables to work out but this does seem like a feasible cause now that more people are weighing in on it.

Sorry dude. Didn't mean to make you paranoid. Not my intention, just a fellow TF-User warning.
[Captivate Android Development] DaNaRkI:
If it is caused by connecting to a PC then it must be a Windows problem. Cuz I always download ROMs via PC then usb to phone, but I'm running Linux (ubuntu to be exact).

And I've ended up disconnecting all 3 ways: "safe" unmounts on PC then android disconnect then unplug, "usual" just android disconnect then unplug, and "hurried" straight unplug. No problems here.

Update: it was brought to my attention that this observation of mine is misguided, so you might wanna ignore it. Since it's already been quoted I won't try to hide that I said something presumptuously.

leaked from my

ICS

- FUSED SGS I897 contaminating you via XDA app.
[Captivate Android Development] silvertag:
Maybe just luck, maybe it had already finished transferring the files and was not in the middle of that process. There is still alot to investigate before pinning this on the OS (not that it could not be) but i find it premature to point fingers there.

Lets see what Woodrube reports
[Captivate Android Development] Woody:
From the reditt link a page or two back.

It might behoove us to figure out how and why this app works.

USB mode switch for SGS1 on CM

It was made by CM for SGSI. Might lead to another piece of the puzzle or maybe the bigger picture. Anyone know anyone in Team Hacksung?

I am out for now, as I have to get some "real" work done but I'll check in later. Happy Hunting.
[Captivate Android Development] jeff.leonard:
Did you configure Ubuntu to use MTP? See the Linux instructions toward the bottom of this page http://www.androidcentral.com/ics-feature-mtp-what-it-why-use-it-and-how-set-it.
[Captivate Android Development] silvertag:
This app is implementing the setprop commands to switch between the usb and mtp mode.

http://xdaforums.com/showpost.php?p=23930506&postcount=55
[Captivate Android Development] DaNaRkI:
Nope, and it does not look like it's worth the effort.

Point taken, so I guess what I said there was rather useless.

leaked from my

ICS

- FUSED SGS I897 contaminating you via XDA app.
[Captivate Android Development] jeff.leonard:
I didn't mean to have a point, yet:) and what you described is not useless.

If you didn't configure Ubuntu to use MTP then how did it connect, was it as a Mass Storage Device? If so it may show the device falls back to mass storage mode if the PC operating system doesn't support MTP. This could prove useful knowledge until someone finds a way to force the phone to only use mass storage like with the team hacksung app but for our phone and any ICS ROM.
[Captivate Android Development] DaNaRkI:
Neither, I have debugging enabled all the time. So it does not allow for any form of auto-connect/communication.

I do a fair amount of "tester" work or just random messing with android to bother having it set any other way.

Also, I was addressing how the initial idea was being due to MTP, which I was not using. So my experiences in the area of PC connection is different and thus unrelated.

leaked from my

ICS

- FUSED SGS I897 contaminating you via XDA app.
[Captivate Android Development] DaNaRkI:
* oops, I pressed the wrong button..., ignore*
[Captivate Android Development] RootTheMachine:
Hmm... I like this MTP theory, but when I got Encryption Unsuccessful on a friend's captivate, it was on first boot after installing ICS. Meaning I didn't do any file transfers over MTP. But the phone was probably plugged in to USB at the time. And it was easily fixed too.

Sent from my CM9 ICS i897 Captivate
[Captivate Android Development] yguns76:
i was using Dark Knight v3 ICS 4.0.4
[Captivate Android Development] silvertag:
What rom was that ? It's rather strange he got it at first boot as most report it was sudden and the phone was working correctly for a period of time.

Also i'm questioning, what about external sd's ? After reading the OP again i think we should also include if a external sd was present at the moment people got the error message and not just the rom. I'm no divine but i suspect there could be more involve then we think regarding the MTP, the rom used and external sd.
[Captivate Android Development] swehes:
I know I am using a Vibrant, but I did not have an SD card in my phone when this issue hit me. It was sudden. I have been running ICS since it first was a ROM for the Vibrant.
[Captivate Android Development] daskanda:
I got this message a while back when I flashed cm9 alpha building 16 I think.... Got it on first boot but didn't click the reset button just pulled battery and factory reset from recovery and flashed again and it booted up fine.... And no external sd card..... Haven't had the message since and been on ics for months now and flashed pretty much every rom on here
[Captivate Android Development] bimbim18:
hmm me too, slim ICS 1007, it hit me in 5 days though.
[Captivate Android Development] Woody:
Just a word about more casualties on the Vibrant side.

4 new people

All running ICS (obviously)

-1 Slim

-2 Passion

-1 Zenwich

Every one of them had their phone connected to their PC and got the error on their next reboot.

I am working on a theory to get the internal to remount so that we can reformat it, wipe it and the Odin to profit. But as of now it is only a theory and I am still trying to figure out the right commands.

Just an fyi since I haven't posted in a few days.
[Captivate Android Development] silvertag:
So all of them switched from usb storage to MTP (or was default) and got the error on the next reboot ?
[Captivate Android Development] Woody:
MTP was the default but the one that was on Zenwich [RC1 was was based on build 26 or 27 I think] (which Br1ck'd changed the build.prop to mount as mass storage as default) was on Passion (AOSP) and Euphoria (AOKP) right before going to Zen.

Saw you just posted over there. I know I am in your forum, but Welcome. We all need to work together on this and not be segmented into our own fora of solitude.
[Captivate Android Development] Wdustin1:
I think this is the strongest lead yet. Watching this thread closely :)
[Captivate Android Development] silvertag:
Making the same request as in the Vibrant forum so if someone can, please do so, thanks :
[Captivate Android Development] the_stift:
I installed Sllim ICS and got the same message by the first start after an update from 2.3.3. But I hit the reset button and after a new reboot everything just works fine.
[Captivate Android Development] Woody:
Someone just got tagged on the OG Transformer again. He was flashing a kernel and screwed up. I asked if it was mounted to PC before his reboot but he hasn't answered yet.

It seems that this "theory" I have could actually be the cause. Now we need the why and the how to fix.

Small steps my friends but it does seems like they are at least in the right direction. I would suggest you maybe put out a warning to your forum-mates about this. I have an ICS installation guide on our side and have already put something in it but may now make it really stand out as a warning.
[Captivate Android Development] swayjd:
to be fair, if someone is flashing something, chances are they downloaded it with a PC and transferred it via usb.
[Captivate Android Development] Woody:
Not necessarily always the case. There is more than one way to connect to your PC. In fact since this bug became a known ICS issue I only use my dropbox to move file to and fro on my tablet. Also my question to him over there was in greater detail than I relayed beck in here.
[Captivate Android Development] Wdustin1:
I haven't connected my phone to since using aokp
[Captivate Android Development] visionlogic:
Question: For those downloading to a PC connected to a router providing wireless access would AirDroid be a "safe" method? I use it frequently.
[Captivate Android Development] bballer182:
I download straight from the net to my phone and flash away. I have had my phone connected one time to my computer but I'm pretty sure I did the safe disconnect procedure. Knowing now that this error is highly likely related to connecting to a PC. My phone stays in "fast charge" mode to eliminate that possibility.
[Captivate Android Development] shaolin95:
So based on what I have been reading, is the problem thought to be related to transferring files from the computer to the phone ? My phone stays connected via USB to my work computer 8 hours a day but is not in that other transfer mode where you can access from both phone and pc at the same time.

I need to "mount" the USB device from the pulldown window to have the phone appear on my computer so, based on what I am reading, it seems I am out of the danger zone or still not clear about that?

I am a tester/flasher so this error kind of put a stop to my flash happy attitude. :D

'
[Captivate Android Development] ctrclckws:
on my phone that got this problem, I don't remember having connected to the PC, but it's been a busy month, so I might have done so, to restore data, but maybe so, maybe not.
[Captivate Android Development] silvertag:
For now only MTP mode is suspected and not usb mass storage mode. You should be fine under this mode. If you flash alot you check the OP's of the rom to make sure MTP is not set as the default.
[Captivate Android Development] shaolin95:
Thanks for the advice mate.
[Captivate Android Development] jeff.leonard:
I think I'm convinced enough that MTP is the issue to flash ICS again and just avoid PC connection. I may also look at forcing the default connection to be UMS when I get a little more courage (what I really mean is when SGSIII is available in the US). It will be Dark Knight 4 with the Semaphore kernel on a 1010 Captivate (the only working one I have left). May not be the smartest thing I have ever done but I just can't keep using GB when ICS is out there. Wish me luck!
[Captivate Android Development] Demetris:
I was also on AOKP and MTP.

Vibrant phone.

Sorry for posting wrong info
[Captivate Android Development] jeff.leonard:
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?
[Captivate Android Development] Demetris:
Corected, was sleepy when typed.

Correct internal storage completely not mountable and not able to be fixed.
[Captivate Android Development] jeff.leonard:
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.
[Captivate Android Development] Woody:
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
[Captivate Android Development] raz123:
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 Android Development] jeff.leonard:
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.
[Captivate Android Development] Woody:
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.
[Captivate Android Development] jeff.leonard:
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!
[Captivate Android Development] shaker2k:
I agree
[Captivate Android Development] Johnsondr80:
Agreed. I am following this closely.

Don't want to lose the ones that are really making a difference.

i717 running Seraphim Collective ICS with tapatalk2
[Captivate Android Development] Wdustin1:
Agree as well, your theory is the best one yet. The great Adam couldn't fix it. you may be our last hope ;)
[Captivate Android Development] gcamp0730:
+1