yashsingh1/xdaforums huggingface dataset:
[T-Mobile LG G2x] codecaine21:
I have a question regaurding the terminal emulator. I work on the command line a ton! With that said, yesterday I was creating/writing a bash script with nano and tried to save but there is no freaking enter button. I like the terminal emulator setup a great deal. So I am looking for a work around. Can I edit a file to add an enter button or would that require recompiling some Java file or APK? Suggestions?
[T-Mobile LG G2x] noobletsausecakebbq:
What keyboard are u using? As long as I can remember there's been a button with the enter function. On my stock 2.3.4 that button is the arrow pointing to the left in the bottom right corner
[T-Mobile LG G2x] codecaine21:
Dude, are you serious? Maybe your just not understanding my question. The enter button works just fine. Up until I create a new file and try and edit that file with nano. How do you think i created the new file and opened nano in the first place lol The enter button inside of the nano editor is non-existant.

Try for yourself!

My commands:

1) Mount -o remount,rw -t yaffs2 /Dec/block/mtdblock3 /system

2) touch /etc/init.d/firewall.sh

3) nano text.txt

Write to the file and try to save. You can use page down(volume up + n) to temporaryily simulate the enter key to create a newline. Volume down + x is exit plus save. This is where I need the exit button the most.
[T-Mobile LG G2x] codecaine21:
I talked to the dev, control + m is the work around. He also said that in the next up and coming version he is pushing a fix for the bug.
[Android Q&A, Help & Troubleshooting] alkhafaf:
Hello everyone

Can I make multiple nandroid backups for different ROMs using CWM ?

Thanks
[Android Q&A, Help & Troubleshooting] Flux-Dev:
Yes you can. You can nandroid any setup you may have. :)
[Android Q&A, Help & Troubleshooting] alkhafaf:
I meant that I want to Make many nandroid copies without replacing any old backup. Is that possible? Or just one copy is allowed?
[Android Q&A, Help & Troubleshooting] plainjane:
It doesn't replace the nandroid, it creates a new one. If you want to delete them for space later you can, but the recovery will not automatically overwrite it.
[Android Q&A, Help & Troubleshooting] AlwaysDroid:
Like they already said, you can do as any as you want. I currently have 4. One rooted stock rom, one Cyanogenmod 7.2 one Cyanogenmod 9 and an early Cm9 beta 4 :)
[Android Q&A, Help & Troubleshooting] gsw5700:
Don't forget to rename the backup with rom, kernel and date etc so easier to manage if you need to recover

Sent using TCP/IP
[Android Q&A, Help & Troubleshooting] alkhafaf:
Thanks alot everyone
[Android Q&A, Help & Troubleshooting] alkhafaf:
Thanks dude

But where is the folder directory and what's its name ?
[Android Q&A, Help & Troubleshooting] plainjane:
You actually need to be careful with this. On my device, if you don't rename them using a certain format (no spaces, etc) then they won't restore.

Assuming that you're using CWM (I don't), it should be somewhere in the ClockworkMod folder.
[Android Q&A, Help & Troubleshooting] alkhafaf:
Thanks dude
[Android Q&A, Help & Troubleshooting] n1newbie:
it will be under clockworkmod/backup. your backups will be sorted by the created date.
[Android Q&A, Help & Troubleshooting] mrclaver:
Don't forget to check if you have space enough for your backups. And remember what hboot you were using on all the different backups. I had a few problems with so many backups. Hehe
[Android Q&A, Help & Troubleshooting] alkhafaf:
Thanks dude

But what is hboot?

do u mean for example m5 ??

And y when I try to restore GB ROM from ICS, it fails?
[Android Q&A, Help & Troubleshooting] n1newbie:
well by hboot, i think he refers to the change in /system partition(but thats for htc phones like desire, so u dont have to worry abt that)

it fails??? wat msg do u get ?
[Android Q&A, Help & Troubleshooting] alkhafaf:
I think the error refers to rfs format in the system partition.

Could that be the ics ROM is in ext4 format?

cuz I checked its Backup folder and there was a file something like ext4-data. Otherwise, in the GB backup there is rfs-data.
[HTC One X] random_username_:
Has anyone really been far even as decided to use even go want to do look more like?
[HTC One X] TheAndroidSwap:
What an incredibly well worded question! Thumbs up if you agree! [trollface]
[Galaxy S II Q&A, Help & Troubleshooting] jcpangs:
Im wondering if this is possible for the s2:

1. Profile changes

is it possible to changed profile for sounds? (like in older phones). I would like my phone to have a different ringtone while im at the office. A different ringtone while im outside and another different one while im at home. instead of wasting time changing the settings.

2. Personal Message tone.

Could I have a dedicated message tone for different contacts? I was able to change ringtones for different contacts but is this possible for message tone as well?

Im on stock ICS. Do i need to root?
[Galaxy S II Q&A, Help & Troubleshooting] Deleted member 4038153:
1). The smallest amount of searching returned https://play.google.com/store/apps/details?id=de.softxperience.android.quickprofiles and about half a dozen others.

2). Considering my answer for 1), why not try searching yourself and let us know how you get on. Ten seconds of searching.
[Galaxy S II Q&A, Help & Troubleshooting] jcpangs:
Thanks. but there are a lot of them and I cant seem to find a good one. here's what im planning to do.

Profile for work.ringtone disabled. message tone enabled. full vibrate for both.

Profile for outdoors: max vibrate and max sounds to ringtone and message tone

Profile for home: off vibrate and medium sounds to ringtone and message tone.

I cant seem to do that on the apps that ive tried. any suggestions out there?
[Samsung Epic 4G Touch] ReActiveDisorder:
Good job sfhub. I am learning new stuff everyday :)
[Samsung Epic 4G Touch] Azrael.arach:
This is mine. I can try to help but not till weekend when my other phone gets here.

MAG4FA

0x0

0x0

0x000015

0x0100

11/2011

MMC
[Samsung Epic 4G Touch] nivron:
Sorry I don't have anything majorly different than the normal, but I have this on my phone:

MAG4FA

0x0

0x0

0x000015

0x0100

08/2011

MMC
[Samsung Epic 4G Touch] Wabem:
Mine is also the same,

MAG4FA

0x0

0x0

0x000015

0x0100

08/2011

MMC
[Samsung Epic 4G Touch] mmark27:
MAG4FA

0x0

0x0

0x000015

0x0100

08/2011

MMC

I am not available to test. Sorry.
[Samsung Epic 4G Touch] dtm_stretch:
MAG4FA

0x0

0x0

0x000015

0x0100

08/2011

MMC

Also unable to risk the brick. Good luck guys.
[Samsung Epic 4G Touch] pbassjunk:
MAG4FA

0x0

0x0

0x000015

0x0100

10/2011

MMC

I'll take one for the team if needed. I've been eyeballing the 720p Evo.
[Samsung Epic 4G Touch] krazyflipj:
Full readings from my /data bricked device. Let me know if you want me to check anything else out:

MAG4FA

0x0

0x0

0x000015

0x0100

08/2011

MMC
[Samsung Epic 4G Touch] azyouthinkeyeiz:
I can risk a brick to save future ones. I can help test.

/*

MAG4FA

0x0

0x000015

0x0100

12/2011

MMC*/
[Samsung Epic 4G Touch] garwynn:
Sorry for the delay on giving more details. I've got info that I'll be passing along soon, just want to read up on something a little more before I post it out here.

Regardless whether this fix turns out to be related to the issue we've been looking at, I want to throw this in now before getting into the weeds:

Big thanks to Ken Sumrall from the Android team as he's been good enough to share info with us about this bugfix. As the person who signed off on the change commit he's one of the best resources on this issue. Also want to give credit to Mr. Min of Samsung who developed the fix in question.

I'll be posting more shortly. Those with dev experience, particularly with C++ and/or Assembly may be able to help us as well.
[Samsung Epic 4G Touch] robertm2011:
MAG4FA

0x0

0x0

0x000015

0x0100

11/2011

MMC

If need be, will test.
[Samsung Epic 4G Touch] Azrael.arach:
So does this mean the new code in the kernel is to help this problem and what would be the steps to testing it?

Sorry if dumb questions, just trying to learn.
[Samsung Epic 4G Touch] robertm2011:
So theoretically, those of us who have posted are able to make full use of the ability to flash, backup, etc. with the proper modification to our kernels? (Hope I got this right.)
[Samsung Epic 4G Touch] garwynn:
I'm of the thought that 99% of all questions are never dumb. And that 1% is extremely rare.

The thread is somewhat of peer review and discussion about what we've found and as a community possibly confirm whether this is both the bug causing the bricks (and by doing so confirming that this is the fix.)

It means that the fix applies to those devices. What still isn't closed is whether the bug that this squishes is *the* bug (causing the ICS based bricks). I'm going to be posting more about that part here shortly for feedback and discussion.
[Samsung Epic 4G Touch] Docarut:
Very interesting but so far over my head....
[Samsung Epic 4G Touch] azyouthinkeyeiz:
/* Missed the first paragraph of the details section. Low level corruption would do what I was questioning. Nvm
[Samsung Epic 4G Touch] garwynn:
Discussion with Android Team

OK, now on to the bug that this fixes. This post will only contain the discussions between myself and Mr. Sumrall of the Android team.

Initial inquiry to Mr. Sumrall:

Initial Response:

We also knew this from the code:

* There is a bug in some Samsung emmc chips where the wear leveling
* code can insert 32 Kbytes of zeros into the storage. We can patch
* the firmware in such chips each time they are powered on to prevent
* the bug from occurring.

Note: Snipped last part of comment as it is already covered.

OK, so it's putting potentially zeros in the storage; but it doesn't give us any clues as to where the possible storage was or how this could corrupt the filesystem. So I sent some follow-up questions and got the following responses. (Regular is question to Mr. Sumrall, bold is response.

Thanks again to Mr. Sumrall for this information. More soon.
[Samsung Epic 4G Touch] keithatoz:
Here's what I have - hope it helps. I would help test, but not until after the weekend. Thanks for all the work and info.

MAG4FA

0x0

0x0

0x000015

0x0100

10/2011

MMC
[Samsung Epic 4G Touch] Entropy512:
It's relevant to why Google is unaware of any differences between Gingerbread and ICS on affected hardware - they have never run Gingerbread on affected hardware. The last hardware they worked on Gingerbread for was the Nexus S, which has a completely different flash architecture.

The fwrev 0x19 bug is clearly applicable to us - but there was discussion of why GB and ICS are different, and right now - no clue. Google would not have a clue because they have never run both Gingerbread and ICS on affected hardware.
[Samsung Epic 4G Touch] Entropy512:
Based on how I understood Ken's comments, it looks like if you have been affected, to fix it the MMC must be completely wiped and reset. This might be doable from a bootable system, but if it fails - JTAG time.

However this additional information might be what the RIFFbox guys need in order to be able to implement a JTAG fix.

That's exactly what has happened with GT-N7000 XXLPY - confirmed hardbricks from factory reset both from stock recovery and from Settings.

The best way to describe the past week in Galaxy Note land since XXLPY went official has been "let the bodies hit the floor".
[Samsung Epic 4G Touch] musashiro:
if they can patch it on E4GT, can we assume that the patch will work on N7000 builds??

the best word to describe the last 2 weeks of OTA ICS updates on note is "horrible"
[Samsung Epic 4G Touch] RainMotorsports:
Not sure if its worth noting at this point, for those who would rather count characters than type commands for this you can do something else if you have root explorer:

Navigate to /sys/class/block/mmcblk0/device and open cid in text editor. Character 19 and 20 are what your looking for though a quick glance at the example might be all you need to locate it.

But yeah MAG4FA and 0x19 for me.
[Samsung Epic 4G Touch] arnostienen:
Indeed, this is exactly what happened to me: I am in the subset of the subset. I got the OTA ICS update two days ago, wanted to do a clean start with it and went into Recovery to do the Factory Reset. Now my phone is dead. (It hangs on the data-part in Odin when trying to revert back to the stock GB ROM, so it clearly is the eMMC bug.)

I bought my Note from Amazon.de in February and have just contacted them to have it replaced.
[Samsung Epic 4G Touch] MR.change:
Interesting info ,but just so I get this right ,we are looking for (the highlighted in red) 19 as a reference to 0x19 fw?

I'm using the SGN N7000 and this is my Cid

15010056594c30304d192e1116052f99

Does it mean it has the 0x19 fw bug that Google mentioned ? I'm running cm9 by the way and it should be safe ,so I don't see how this is the case

I mean aren't all 0x19 revisions effected with the emmc bug ? How come cm9 also has the same revision but safe ?

Please enlighten me to this issue , I know very little about this.

EDIT: OK so after some deeper reading it's clear that cm9 doesn't have the mmc erase command cause it's built off gt i9100 source 4 ,which doesn't have that feature ,so it's safe even though it's based on that buggy 0x19 fwrev.

EDIT2: it just occurred to me that the mmc cid fwrev is in dependant of kernel or ROM and have to be pushed out independently ,am I right ? As I said ,I know very little about this .

Thanks
[Samsung Epic 4G Touch] fenixjn:
My understanding of this is that it is the chipset firmware not the ROM, the CID is constant across ROMs so it will be the same regardless of the ROM you flash. And having the firmware 0x19 means that your chipset is

vulnerable

to the bug (as in it might happen, not that it will happen)
[Samsung Epic 4G Touch] MR.change:
Thanks for the confirmation

And yes the problem did happen on my device when I flashed official ICS on my note ,then wiped from recovery.

I was among the first to encounter this bug (before all the buzz began actually) ,but luckily I was also among the lucky few where our emmc decided to respond after a dozen reboots and flashes .

What a heart stopping 15 minutes they were !
[Samsung Epic 4G Touch] Entropy512:
That's correct. To get nailed, you need BOTH:

1) A flash chip with the affected firmware. This appears to be the case for nearly all Samsung Exynos devices. There is currently no known way to change the firmware - what you have now is what the factory put in.

2) A kernel that triggers the firmware bug. I9100 update4 sources don't, Gingerbread kernels don't, nearly all other ICS releases do.

I'm still trying to figure out why Gingerbread doesn't cause this bug. Right now, one thing that seems to be the case is that Samsung did some of their own customization in the MMC subsystem, not just in the drivers for their specific hardware for Gingerbread kernels. ICS kernels seem to have less of this customization - so perhaps Samsung implemented a workaround in Gingerbread, didn't bother to implement it with ICS and just removed the MMC_CAP_ERASE flag, and then one of their teams turned it back on, unaware that Gingerbread had all sorts of workarounds for this. Of course, this is all just a guess so far.
[Samsung Epic 4G Touch] garwynn:
I want to get a list of follow-up questions together to send to Mr. Sumrall on Monday so anyone that has one still lingering please post here. I also want to note that this was apparently picked up on the XDA news section - thanks to all for spreading the news.

Link: http://www.xda-developers.com/android/hard-brick-bug-on-galaxy-s-ii-and-note-leaked-ics-kernels/

For those who want to try and get this resolved more quickly, the best suggestion I can make is contact your carrier. Inform them of this and have them ask Samsung to provide the fix. Hopefully we'll get some good news on that soon - I would hate to see both the carriers and Samsung lose a lot of cred for letting this one go unresolved. (It would hurt their image and bottom line)
[Samsung Epic 4G Touch] Entropy512:
There's been a discussion in the ERD forums on Superbrick for the past 2 weeks or so - it kind of died down for a while until your breakthrough in getting that gem of info from Mr. Sumrall. Even if you hadn't gotten that info, there would have been an article as a warning due to the fact that XXLPY is killing Notes right and left.

As to the carriers and Samsung losing a lot of cred - I would LOVE to see them lose cred over this, as it would teach them:

1) Don't be arrogant and ignore the development community like Samsung has - it's been known here for weeks (if not months in the case of the E4GT) that something was wrong

2) Don't be idiots and enable a kernel feature that is known and documented to be incompatible with the firmware revision of nearly every device that kernel will run on.

If this were ONLY an issue with leaks, I'd be more willing to let it slide - However, allowing GT-N7000 XXLPY and ZSLPF to go live with kernels that can trigger this bug is simply inexcusable. This firmware bug was apparently well known internally to both Google and Samsung, enough that Samsung created a new firmware revision of the flash chip for the Galaxy Nexus. Despite this, even new Exynos devices seem to be shipping with fwrev 0x19 (A Note owner just got their device back from service and immediately re-bricked it due to accidentally leaving an old ZIP of an affected kernel lying around. There is NO EXCUSE WHATSOEVER for taking a device that was damaged by this eMMC firmware bug and replacing it with another device that is STILL affected by the bug.). I can understand the difficulty of updating the eMMC firmware of devices already in the field - but continuing to ship affected devices AND enabling kernel features that will trigger a severe bug such as this when they are FULLY aware of what it will do is inexcusable.
[Samsung Epic 4G Touch] musashiro:
TOTALLY inexcusable...

What do you mean by infected zip lying around??
[Samsung Epic 4G Touch] mobilevil:
he rename files to his own liking update1.zip and update2.zip, then he mixed up the internal sdcard and external sd, so he flashed the wrong file and bricked,
[Samsung Epic 4G Touch] sfhub:
Unlike the direction one of the other threads started taking, let's try to keep this thread focused on finding solutions rather than assigning blame. If we start getting off track, it won't help us get solutions and it could end up hurting us as people tend to not want to help you out if it will cause them trouble.

Once again, the primary focus should be on finding a solution.
[Samsung Epic 4G Touch] sniper:
In the news article:

Now obviously we know it's risky to flash using cwm or any other recovery, but why does this say not to use mobile odin which is what everyone has been doing on the E4GT for a long time?
[Samsung Epic 4G Touch] Robotu:
For the profy ignorants out there, not on this thread, well i just have seen one in this thread too!!!! This problem have solutions, and one have been found!!!

http://xdaforums.com/show...&postcount=218

Originally Posted by uggies

Yessssssss it finally boots into cm9 !!!!!!!!!!!!!!!!!!

Holy fuuuuuuuu !!! I cant explain how excited i am!!!! 2 full days of working !!!!!!!

Omfg thanks heaps especially forest1971 !!!!!!!!!!!

Wowowo i still cant believe this

Nicely done to you and Forest1971, been following this thread since it began.
[Samsung Epic 4G Touch] mobilevil:
i am excited but your link is bad!
[Samsung Epic 4G Touch] Robotu:
They have changet the name of the thread to a more relevant one due to solving of the issue... Take this http://xdaforums.com/showpost.php?p=26363045&postcount=218
[Samsung Epic 4G Touch] Entropy512:
Looks like he didn't fix it at all, just somehow caused the wear leveler to move the affected blocks to the partition for internal SD.

Edit: He repartitioned to try and make the bad block unused. That isn't even remotely a fix, it's just a fairly bad workaround.
[Samsung Epic 4G Touch] Robotu:
The point is that this can be a solution, and a good one. He did what he could. He do not have enough knowledge, and i do not enough, he have been guided through forum remotely by another guy, wich maybe himself could not be enough skilfull. The point is that the guys that can do that, should give some credit to this method and so 99% could be improved by skillful ones in a matter of days. Ive been trying few days ago to gain your attention (the devs) with this theory, but ive been ignored. Mybe you thought that is only the pain of loss.... Ha, ha, ha...! That it will pass and after that i will understand that the only solutin is replacing the MOBO....... Well, eventualy i will, but not so soon. I am not a linux programer, but yet, in mi had do not have enough space to swallow an issue that is not logic...
[Samsung Epic 4G Touch] jgaviota:
Most probably he won't be allowed to give its the firmware fix, and we cannot apply it because we don't have fastboot, so the follow up question must be:

What is the command to wipe or reset the emmc?

Can it be applied by JTag as we don't have fastboot?

Is there any public documentation available?

Here is where an UnbrickableMod would help, as I recall Adam can use lower level commands from his bootloaders
[Samsung Epic 4G Touch] garwynn:
Actually, I went over those posts - and it seems to be an attempt to do on the Note what drnull did on the E4GT - repartition to avoid the corrupted area. It hasn't been long term tested nor does it fix the underlying problem which we know now. I'm glad that someone read the potential workaround but it's not a fix - and why at least the E4GT community moved on past it.

We have reason to believe a fix (prior to bricking) does exist but is not available to the public. There are even cases where it may be able to save a bricked device without having to replace the mb - but we need more info on it. Oddly enough, AT&T's Note (I believe the D717 is the Note) have the 0x25 firmware on there and so they're not susceptible to the "superbrick". Anyone that has connections at AT&T might want to ask and see if they have the fix...

So please understand this is why it is going a different direction - your potential fix is several months old and was concluded to be a "bandage" at best, not a "cure."

---------- Post added at 03:16 PM ---------- Previous post was at 03:09 PM ----------

I'm trying every avenue I can to get it released - We're waiting on a reply from Mr. Sumrall and separately from Samsung, and I'm going to pass this info on to Sprint in about an hour. It doesn't even have to get to the community - if it's code and it can just be added to the ICS build I'd be happy with that as a solution.

Regarding the follow up questions:

1) Find the difference between the global build that doesn't brick and the ones that do - and then apply to all builds for affected devices. I believe Entropy has done a lot of legwork on that already and has a good idea on what it may be.

2) Sounds like no - but we really need the patch code itself to send to someone and have them check. I'm holding out hope that it will work...

3) Very little. Most of the legwork done on this problem so far has been by scouring the internet and available Android code... but even that didn't answer everything.