Database Users

Anyone bricked from iMilka's AOSP/CM9?

Entropy recently stated that using any leaked build was dangerous.
I have used every single version of AOSP and CM9 from the beginning to current, jumping between and back and forth from GB many times with no issues.
I have also never SEEN a report of anyone bricking (when properly) flashing around with these roms.
Just curious if a case actually exists.

crawlgsx said:
Entropy recently stated that using any leaked build was dangerous.
I have used every single version of AOSP and CM9 from the beginning to current, jumping between and back and forth from GB many times with no issues.
I have also never SEEN a report of anyone bricking (when properly) flashing around with these roms.
Just curious if a case actually exists.
Click to expand...
Click to collapse
No but there is a risk. And the question is : "Do you want to take this risk while CM9 is announce next week with a safe kernel".
I was using Imilka Cm9, and yesterday i flashed back to GB. Maybe you could wait one week and avoid flashing a hazardous repack !

I had no issues with Imikas cm9 roms, I used all 3 of them and have since flashed to a stock gingerbread as the video playback in all the ICS roms is not good enough yet compared to GB roms.
I have tried all the ICS leaks and gone back to GB with no issues, just waiting for a proper stable release of ICS with good video playback performance as I get in GB then I will stick with the Ice Cream

remixtech said:
No but there is a risk. And the question is : "Do you want to take this risk while CM9 is announce next week with a safe kernel".
I was using Imilka Cm9, and yesterday i flashed back to GB. Maybe you could wait one week and avoid flashing a hazardous repack !
Click to expand...
Click to collapse
I wasn't stating that there isn't a risk, or that anyone should chance it. Just simply that I have not heard of a single case of anyone having a problem with iMilka's releases (killing the board). Therefore my none developer point of view is that the risk must be VERY small IF said risk does truly exist with all Kernel Leak builds.
It SEEMS to me that the problem does not lie with the kernel build but the way it is scripted and executed. Hence why no one has ever had the problem with AOSP/CM9, but the problem came up with Angelom's kernel and the last Stunner build. The problems were also immediate in both cases, again where no one has ever had this problem caused by AOSP/CM9. So YES, I am sure AOSP/CM9 could have caused the problem if iMilka made whatever mistake was made by Stunner/Angelom, but I would say to me it is quite obvious he did not, and that the problem IS a mistake in the way the kernel is handled. Speculation and opinion only of course.
I have been running them since the beginning, so I am not saying I personally would have chanced it this close to offical ICS / Official CM9, but i've been running his releases for quite some time.

crawlgsx said:
Entropy recently stated that using any leaked build was dangerous.
I have used every single version of AOSP and CM9 from the beginning to current, jumping between and back and forth from GB many times with no issues.
I have also never SEEN a report of anyone bricking (when properly) flashing around with these roms.
Just curious if a case actually exists.
Click to expand...
Click to collapse
Flashed all imilka Roms from day one, and never had as much as a hiccup on any one of them.

The question is if anyone tried to restore a cwm backup ? The most of the bricks were caused by doing that task..
Sent from my GT-N7000 using xda premium

No issues here either with Midnote or TeamMid ROMS (also tried a couple of Alba versions and Stunner).
I have flashed many times and with LP5 kernel through CWMR or Mobile Odin including full wipes.
I have made nandroid backups but haven't tried to restore any, perhaps this has saved me?

Tried CWM restore twice on ICS (missed reports that it is not recommended). Both times ended with corrupted system partition. But both times fixed this problem by flashing stock ROM with desktop Odin. Had no problems after.
Sent from my GT-N7000 using xda premium

dimcus said:
Tried CWM restore twice on ICS (missed reports that it is not recommended). Both times ended with corrupted system partition. But both times fixed this problem by flashing stock ROM with desktop Odin. Had no problems after.
Sent from my GT-N7000 using xda premium
Click to expand...
Click to collapse
Exactly the same here. Unable to format /system partition after restoring.
Odin managed to fix it tho.

jscurtu said:
The question is if anyone tried to restore a cwm backup ? The most of the bricks were caused by doing that task..
Sent from my GT-N7000 using xda premium
Click to expand...
Click to collapse
I have multiple times. CWM Backup restore works sometimes for me ICS to ICS, and fine GB to GB. ICS to GB or GB to ICS causes issues but I can easily fix them with a flash/odin/etc and still have complete access to download mode / CWM. ICS to ICS I have run in to problems such as funky root or partition issues, once again still easily fixable and still have plenty of access to the phone/flash abilities, By no means even close to a brick.
That said at this point in the game I wouldn't even consider doing a CWM restore, why even chance it!

dimcus said:
Tried CWM restore twice on ICS (missed reports that it is not recommended). Both times ended with corrupted system partition. But both times fixed this problem by flashing stock ROM with desktop Odin. Had no problems after.
Sent from my GT-N7000 using xda premium
Click to expand...
Click to collapse
Just to report, I experienced exactly the same.
Regards!
Sent from my GT-N7000 using xda premium

dimcus said:
Tried CWM restore twice on ICS (missed reports that it is not recommended). Both times ended with corrupted system partition. But both times fixed this problem by flashing stock ROM with desktop Odin. Had no problems after.
Sent from my GT-N7000 using xda premium
Click to expand...
Click to collapse
Which kernel were you on?

chill392 said:
Which kernel were you on?
Click to expand...
Click to collapse
The first leaked one - LP1.

jscurtu said:
The question is if anyone tried to restore a cwm backup ? The most of the bricks were caused by doing that task..
Sent from my GT-N7000 using xda premium
Click to expand...
Click to collapse
I think you are wrong.Bricks caused when trying to format /system
Sent from my GT-N7000 using Tapatalk

Bricks were caused by anything that tried to wipe a partition - and restoring a nandroid will first wipe a partition.
What kernel is imilka's a repack of? Maybe it's an unaffected one. I recall seeing stuff in imilka's thread saying not to use its CWM.
Without source for the leak kernels it's impossible to tell what's changed and declare one kernel "safe" and another "dangerous" - as long as some are proven dangerous they should all be considered dangerous.

afilopou said:
I think you are wrong.Bricks caused when trying to format /system
Sent from my GT-N7000 using Tapatalk
Click to expand...
Click to collapse
When restoring a backup , you usually format /system ; )...so basically yes that is correct, I only mentioned that it mostly happened while doing that task..
Sent from my GT-N7000 using xda premium

Entropy512 said:
What kernel is imilka's a repack of? Maybe it's an unaffected one. I recall seeing stuff in imilka's thread saying not to use its CWM.
Without source for the leak kernels it's impossible to tell what's changed and declare one kernel "safe" and another "dangerous" - as long as some are proven dangerous they should all be considered dangerous.
Click to expand...
Click to collapse
It was multiple different kernels, up to LP5 and LP6 even.
I understand the logic and respect your words of caution with what is most certainly from someone who has a much better understanding than I, I just feel it is the way the kernel was used/modified/implemented that caused the potential problems (by the devs), not the kernel itself. Based on the logic I provided earlier in the thread. I am not saying the problem still does not exist in the kernel, I have no idea, but it is obviously something that did not come out in many rom implementations, just those 2.

Flashed all roms from maxicet and some repack stock ICS roms. Never got any problems. Tested over 10 ICS roms... And now using maxicet's ROM as daily.

crawlgsx said:
It was multiple different kernels, up to LP5 and LP6 even.
I understand the logic and respect your words of caution with what is most certainly from someone who has a much better understanding than I, I just feel it is the way the kernel was used/modified/implemented that caused the potential problems (by the devs), not the kernel itself. Based on the logic I provided earlier in the thread. I am not saying the problem still does not exist in the kernel, I have no idea, but it is obviously something that did not come out in many rom implementations, just those 2.
Click to expand...
Click to collapse
The thing is, this has happened over multiple devices, with multiple recovery implementations, including recovery implementations that work fine with other kernel bases. The end result is the same - fried eMMC that can't even be recovered with JTAG.

Entropy512 said:
The thing is, this has happened over multiple devices, with multiple recovery implementations, including recovery implementations that work fine with other kernel bases. The end result is the same - fried eMMC that can't even be recovered with JTAG.
Click to expand...
Click to collapse
Agreed, very bad.
All I am saying is that it ONLY happened on those 2 botched kernel implementations. It is obviously SOMETHING the Dev's did with the kernel that caused this, seeing how ALL the other roms/versions clearly have not caused this. Since the result was immediate with both of those and many of us have jumped/cwm'ed/etc from MANY different Leaked kernel builds and NOT had that problem.
I am not trying to put them at blame, running any rom/dev is strictly at your own responsibility and risk, just stating that I don't think it is fair to place every leaked rom build in the same category of danger. Is there a risk, certainly, as the dev's could accidentally make said same mistake (I am not even clear if "we" know what causes it?) in a future version. That said I feel pretty confident that if the "final" versions of iMilka's roms were going to cause that issue, it would've happened by now. That is why I wanted to see if anyone had ever been bricked (fried eMMC) from them, and it seems, no.

Samsung responds to Galaxy S II / Note eMMC bug problem

If you own a Samsung Galaxy S II or the Galaxy Note and are a regular member of the xda-developers forum, you may already be aware of a bug with some of these devices where erasing the eMMC could hard brick your phone.
This problem would surface if the user tried to flash a custom ROM or kernel that used MMC_CAP_ERASE. Thankfully, developer Chainfire came up with an app that would let you know if your device was shipped with a faulty eMMC.
Apparently, this issue has existed for a long time now and even though it was noticed a couple of months ago and was much talked about in the developer community Samsung did not respond to it, until now.
According to user Daniel Hillenbrand on Google+, Samsung has said that "Patches will be out in form of new official ROMs and also sourcecode releases after testing, which might take some time."
If you have a Galaxy S II or Galaxy Note, just use the Chainfire GotBrickbug app from here and see if the eMMC in your device is affected. If it is, refrain from any kind of ROM flashing (except for CM9 kernels, which are safe to flash) until the patch from Samsung starts rolling out.
SOURCE

Atleast give source of info and links ?

anshmiester78900 said:
Atleast give source of info and links ?
Click to expand...
Click to collapse
It's there, but in camouflage:
https://plus.google.com/111398485184813224730/posts/21pTYfTsCkB
Cheers.

buzzboy said:
It's there, but in camouflage:
https://plus.google.com/111398485184813224730/posts/21pTYfTsCkB
Cheers.
Click to expand...
Click to collapse
Cheers mate and it is good to know that samsung is working hard on it

Stupid question but does that mean that we need to wait first Samsung to release something and then rom and kernel makers to implement it in their products? I just flashed slimics rom and now checked that I have brick bug, nice!
Sent from my GT-I9100

I don't really think it's Samsung fault. They have spend a lot of time working on those devices, and of course, bugs are all part of the development. I don't think that Samsung is a bad company, but they need at least to figure out the problem and fix in the next device or firmware, so that's enough to me.
edit: well, it's kindda samsung's fault, hehehe.

I have the bug, according to Chainfire's app, but I've never had any problems after many, many flashes.
Am I just lucky?
How likely are those whose eMMC chips are faulty in this way to be bitten by the bug?
I've typically flashed all new leaks of Stock ROMs only. How do we know if are using kernels based on sources where MMC_CAP_ERASE is present?

donalgodon said:
I have the bug, according to Chainfire's app, but I've never had any problems after many, many flashes.
Am I just lucky?
How likely are those whose eMMC chips are faulty in this way to be bitten by the bug?
I've typically flashed all new leaks of Stock ROMs only.
Click to expand...
Click to collapse
It's only triggered if using certain kernels (Or, more worrying, some stock GNote builds)
There is a thread listing "bad" kernels and an explanation kicking around on XDA if you want to know more.
In short.. Stick to well known and well tested kernels and you'll never have a problem

Azurren said:
It's only triggered if using certain kernels (Or, more worrying, some stock GNote builds)
There is a thread listing "bad" kernels and an explanation kicking around on XDA if you want to know more.
In short.. Stick to well known and well tested kernels and you'll never have a problem
Click to expand...
Click to collapse
Does that list get updated?
How do we know if are using kernels based on sources where MMC_CAP_ERASE is present?
I assume that since this is such a potentially serious issue, the MMC_CAP_ERASE issue is something that devs are well aware of. I wasn't aware of it until very recently.
IF I understand correctly, are you saying that the stock kernels no longer have this issue or do they still and can MMC_CAP_ERASE be removed from the kernel?

it will b great if the patches roll out soon

Just curious, what effect does MMC_CAP_ERASE have? I mean what does it actually do? And is not being able to perform it somehow reduces the performance of our emmc chips?

mzone1510 said:
Just curious, what effect does MMC_CAP_ERASE have? I mean what does it actually do? And is not being able to perform it somehow reduces the performance of our emmc chips?
Click to expand...
Click to collapse
this thing can destroy your mobile
MMC_CAP_ERASE is one of the big reason to hardbrick the sgs2 phone.

NOMIOMI said:
If you have a Galaxy S II or Galaxy Note, just use the Chainfire GotBrickbug app from here and see if the eMMC in your device is affected. If it is, refrain from any kind of ROM flashing (except for CM9 kernels, which are safe to flash) until the patch from Samsung starts rolling out.
Click to expand...
Click to collapse
I normally ignore posts like this but just need to clear something up as you only make things worse for new members who are unaware when you spread false information through a forum like this. Can you please remove or reword what you've said. I'll break it down for you:
If you have a Galaxy S II or Galaxy Note, just use the Chainfire GotBrickbug app from here and see if the eMMC in your device is affected - This is fine as people can run that app.
If it is, refrain from any kind of ROM flashing (except for CM9 kernels, which are safe to flash) until the patch from Samsung starts rolling out. - So wrong it hurts! Everyone should completely ignore this sentence and actually read the thread of the app which states all currently available kernels based on Update4 sources (so all custom kernels in the dev areas) are safe. It was particular leaks that raised this issue as found in an earlier Siyah beta which was rectified as quick as Gok could do it but to this day people still question devs on their kernels. Please read the thread and add useful guidance only or direct people to the post which states the safe kernels!
And as a last note, please don't post in kernel threads asking if they're safe, simply do a search as it's been asked stupid amounts of times and no more spam is required.
Thanks and happy flashing

AvRS said:
I normally ignore posts like this but just need to clear something up as you only make things worse for new members who are unaware when you spread false information through a forum like this. Can you please remove or reword what you've said. I'll break it down for you:
If you have a Galaxy S II or Galaxy Note, just use the Chainfire GotBrickbug app from here and see if the eMMC in your device is affected - This is fine as people can run that app.
If it is, refrain from any kind of ROM flashing (except for CM9 kernels, which are safe to flash) until the patch from Samsung starts rolling out. - So wrong it hurts! Everyone should completely ignore this sentence and actually read the thread of the app which states all currently available kernels based on Update4 sources (so all custom kernels in the dev areas) are safe. It was particular leaks that raised this issue as found in an earlier Siyah beta which was rectified as quick as Gok could do it but to this day people still question devs on their kernels. Please read the thread and add useful guidance only or direct people to the post which states the safe kernels!
And as a last note, please don't post in kernel threads asking if they're safe, simply do a search as it's been asked stupid amounts of times and no more spam is required.
Thanks and happy flashing
Click to expand...
Click to collapse
Im sick of seeing people asking/commenting about this in the Kernel threads, when they have no idea what they are on about!

superleeds27 said:
Im sick of seeing people asking/commenting about this in the Kernel threads, when they have no idea what they are on about!
Click to expand...
Click to collapse
Indeed and unfortunately it starts due to threads like these, sorry OP.
Here's some further reading for those who avoid using search so sit down, read and then forget:
Entropy512 said:
It would be beneficial to provide more information on the brick bug to avoid some people getting unnecessarily scared (such as most I9100 users).
This bug requires three things for you to be in danger, and ALL of these conditions must be met for danger:
1) A defective eMMC chip/fwrev that is unable to handle eMMC ERASE commands (command 38) properly. (I'll provide a link with more detail on the nature of the bug later) - This condition is the one Chainfire's new app checks for. By the way, M8G2FA fwrev 0x11 (seen on some Kindle Fires) is also suspected of being defective.
2) A recovery binary that attempts to erase partitions when formatting them. Most ICS recovery binaries fit in this category, most Gingerbread recoveries do not attempt to perform an erase operation so are safe. Note that also, an affected update-binary in a ZIP could be a cause of problems too. (e.g. flashing a firmware that has an ICS update-binary and formats the partition could cause a problem even with a "safe" recovery.) So a kernel can be repacked with a "safe" CWM (such as the most recent CF-Root releases) but it will still only be partially safe.
3) A kernel that allows attempts to erase a partition to actually happen. (as opposed to reporting "not supported" and doing nothing.) - A common way of rendering a kernel safe is to remove MMC_CAP_ERASE from the capability flags in drivers/mmc/mshci.c
As of June 6, 2012, this is what I know as far as kernels that meet condition 3:
All GT-I9100 ICS leaks and official releases are SAFE (MMC_CAP_ERASE not present)
All kernels based on GT-I9100 ICS Update4 sources are SAFE (MMC_CAP_ERASE not present) - This includes all CM9 nightlies for SGH-I777, GT-I9100, and GT-N7000, all GT-I9100 custom kernels I am aware of, and all SGH-I777 custom kernels I am aware of
All GT-N7000 ICS leaks are UNSAFE
All GT-N7000 ICS official kernels are UNSAFE
All kernels built from the GT-N7000 sources are UNSAFE unless the following condition is met:
MMC_CAP_ERASE is removed from the capability flags in drivers/mmc/host/mshci.c - check the kernel features for this. Franco.kernel R3 and later and all Speedmod ICS releases are SAFE due to this.
All SHW-M250S/K/L ICS kernels are suspected to be UNSAFE
All SHW-M250S/K/L ICS source releases as of this date are UNSAFE (SHW-M250L Update4 was the cause of the SiyahKernel 3.1rc6 incident. Other Siyah releases are SAFE)
All SPH-D710 ICS releases as of this date are UNSAFE - Rumor has it that the official OTA may have a fixed kernel, but it is recommended to consider this kernel UNSAFE until source code is released and can be reviewed.
The SGH-I777 UCLD3 leak is UNSAFE, as is most likely every other leak for that device. Fortunately nearly everyone is using I9100 Update4-based custom kernels.
SGH-I727 and SGH-T989 ICS leaks are UNSAFE - However as these two devices use separate recovery and operational kernels, if you have a Gingerbread recovery/kernel, you should be safe regardless of what you are booting for normal operation.
It's hard to get ALL of the cases and evaluate them, but in general in terms of levels of danger (As of June 6, 2012 - this could change with time):
SPH-D710 users are in the most danger - They have no official ICS releases AND the I9100 Update4 source base can't be used to build a usable kernel for their device without major developer work
GT-N7000 users are second on the list - They are the only ones outside of Korea to receive official ICS updates that trigger the eMMC firmware defect. However, I9100 Update4 sources required only minor work to create "safe" kernels, and developers know the proper procedure for rendering the official N7000 Update3 source drop "safe"
SGH-I777 users are next - I777 leaks proved to be dangerous a month or so ago. However, the SGH-I777 required the least amount of work to be able to use the GT-I9100 Update4 source base, and as a result, with the exception of the leaks themselves, nearly all I777 ICS kernels are based off of safe source code bases.
GT-I9100 users are in the least danger - No leak, official binary release, or source code release for this device has been dangerous. Only one I9100 kernel has ever proven dangerous and that was quickly pulled by its developer.
I am not evaluating the SHW-M250S/K/L in the above list, as while I know their source and binaries are dangerous, the language/culture barrier means we have very little information on how this fiasco is panning out for those users.
UPDATE:
We have at least one confirmed report of this bug occurring with KYL00M fwrev 0x12 on a Samsung Skyrocket (SGH-I727) with their ICS leak kernels
In addition, Samsung Hercules (SGH-T989) has the same fwrev and I've been told that they have observed bricks of this type with their ICS leaks
UPDATE 2:
I've received an email from a contact at Samsung who has indicated they are working on some sort of fix to be deployed to devices with an "UNSAFE" configuration listed above. I have requested that I receive an explicit list of which binary builds contain this fix, as without that I cannot know for sure which builds are fixed and which are not. Fixes are not yet deployed to affected devices.
Click to expand...
Click to collapse

HELP!
I have bad news (for me, of course) my phone is bricked, I write here because I want my phone back and I find no solution so far for this model, only for the Note and Epic 4G. Anyone have any ideas to solve the problem of brick MMC_CAP_ERASE for i9100? I'm reading from 6am..
if the moderator feels that this post should not go here, is his right of disposal. I just want an answer and a possible solution. thanx

I got the emmc bug too..good thing nothing happened when I flashed my phone. using siyah 4.1.5 kernel

I got to emmc bug and o tried all stuff i have jtag-et device 4 times but nothing always same when instaling something my phone freazes. And i have byed new sgs2 and my old phone is just waiting bether times
Sent from my GT-I9100 using xda app-developers app

Got my Note hard bricked with ...

So i am the first to hard brick his Note with CF ROOT 5.6!
I don't blame anyone beside Samsung for this!
Fortunatly i have my warranty valid until abril 2014!
So:
For about 4 days ago i went to pickup my bricked Note with a new motherboard from Samsung Service Center!
A new motherboard was given to me.. all have it came with Gingerbread KK1!
So came home, flashed a firmware from here:
[STOCK ODEX PRE ROOTED ROMs] for Odin PC no counter & triangle
All happy i got root on my Note i exitated from flashing ICS!
I read and read and read about the faulty kernels and then i found Chainfire that he had a workaround!
So to my mind came this:" I have warranty for my baby, even if i brick i will get a new motherboard for free! "
Anyway, flashed cf-root 5.6, flashed midnote 1.6!
And flashed again cf-root 5.6 just to be sure i had it to avoid any bricking!
Today morning i was on N7000 development thread, made a nandroid of my system and did a full wipe: cache, dalvik, /system and /data!
After it finished to flash paranoidandroid 0.2 i rebooted my Note and well.. the rest is history:
Nothing appears on screen, the jig doesn't work, no download mode, no cwm mode!
My Note is now a very expensive paperweight!
Here is the first person that has bricked his Note with CF ROOT 5.6!
Will bring it again to Samsung Service Center to get a new motherboard for free!
I got my Note for free, and two motherboards for free!
ahahhaa
Thank you Entropy, Chainfire and to all the devs out there that are trying to get this issue solved!

It sucks! I know people are afraid of flashing... but i did because i have warranty that covers the motherboard replacement... but i guess they will be very surprised when i get my Note back again!
The best part is that i won my Note in a contest and Samsung will have to give me two motherboards for free! lol

So you just flashed CF5.6 again without booting up the phone to check if it was actually 5.6
You should have gotten a visual confirmation that it was indeed CF-ROOT 5.6. How did you flash it? Via CWM? via Mobile Odin?

Okay samsung is officially sued....lol....but seriously getting bricked has become common mow....because ppl forget ro do some research first....but its easy to come out of it...thanks to pc odin...it was easy for me...

Well, the CF-Root thread DOES say that his changes to make it "safer" can't protect you against unsafe update-binaries... It's in the big red "PLEASE READ THIS POST BEFORE FLASHING"...

PoisonWolf said:
So you just flashed CF5.6 again without booting up the phone to check if it was actually 5.6
You should have gotten a visual confirmation that it was indeed CF-ROOT 5.6. How did you flash it? Via CWM? via Mobile Odin?
Click to expand...
Click to collapse
Poisonwolf via PC Odin! And of course i let the rom booted first!
I do am sure 200% that i flashed CF Root 5.6 thru PC Odin!
Afterwards i did what i told in OP and my phone dies!
Entropy512 said:
Well, the CF-Root thread DOES say that his changes to make it "safer" can't protect you against unsafe update-binaries... It's in the big red "PLEASE READ THIS POST BEFORE FLASHING"...
Click to expand...
Click to collapse
I know mate.. and i'm not worried.. Samsung will give me a free motherboard!
The only ones to blame is the manufacturer! They should test the firmwares and everything they launch.. if it did made a kernel i would fully test it myself before it came to public!
Of course i will keep supporting Samsung because i do love their phones but this sucks.. i mean.. i don't care about the bricking.. but in less then a week i am without my phone!
Entropy just a question:
How do i check if an update-binary is safe?

zylor said:
Entropy512 said:
Well, the CF-Root thread DOES say that his changes to make it "safer" can't protect you against unsafe update-binaries... It's in the big red "PLEASE READ THIS POST BEFORE FLASHING"...
Click to expand...
Click to collapse
I know mate.. and i'm not worried.. Samsung will give me a free motherboard!
The only ones to blame is the manufacturer! They should test the firmwares and everything they launch.. if it did made a kernel i would fully test it myself before it came to public!
Of course i will keep supporting Samsung because i do love their phones but this sucks.. i mean.. i don't care about the bricking.. but in less then a week i am without my phone!
Entropy just a question:
How do i check if an update-binary is safe?
Click to expand...
Click to collapse
The people that release roms should make sure that their update-binary is safe. I think that it is unforgivable that someone releases a rom with an update-binary that issues the erase command.
The user can make sure that the install script does not use the format command, using delete recursive instead.

jgaviota said:
The people that release roms should make sure that their update-binary is safe. I think that it is unforgivable that someone releases a rom with an update-binary that issues the erase command.
The user can make sure that the install script does not use the format command, using delete recursive instead.
Click to expand...
Click to collapse
Paranoidandroid android seems to have a format command on updater-script.. Will make when i am in my laptop
Sent from my GT-I9100 using Tapatalk 2

So far I've performed backup-restore and wipe data/factory reset with 5.6 countless times but I never used it to flash customs roms.
CF had made it clear that update zip that contain format command might brick.
If I'm not mistaken, it means update script included in custom roms that contain code like
format("ext4", "EMMC", "/dev/block/mmcblk0p9");
format("ext4", "EMMC", "/dev/block/mmcblk0p7");
can trigger the bug.

Boy124 said:
So far I've performed backup-restore and wipe data/factory reset with 5.6 countless times but I never used it to flash customs roms.
CF had made it clear that update zip that contain format command might brick.
If I'm not mistaken, it means update script included in custom roms that contain code like
format("ext4", "EMMC", "/dev/block/mmcblk0p9");
format("ext4", "EMMC", "/dev/block/mmcblk0p7");
can trigger the bug.
Click to expand...
Click to collapse
You are completely correct.
Does any of the things zylor flashed contain this ?
Which ROM developer still includes those commands on their custom ROMs ?! When we know it causes bricks ?!

I am running Cf-root LQ3 5.6 with same rom than zylor, and i don't wanna send my note again to samsung service.
It´s safe change to Paranandroid ? What procedure should I use?

Confirmed, found this line in updater-script:
format("ext4", "EMMC", "/dev/block/mmcblk0p9", "0");
That's the cause of your brick right there, PARANOIDANDROID ...
EDIT #1:
(MIDNOTE doesn't seem to have anything to do with this, but to be certain, I'm also checking that one ...)
EDIT #2:
MIDNOTE seems to be clean. Adjusting thread title to stop giving MIDNOTE a bad name
None of this is surprising, btw ...
Don't flash ParanoidAndroid for the time being !

Thanks, i'm gonna keep MIDNOTE 1.6.

Chainfire said:
You are completely correct.
Does any of the things zylor flashed contain this ?
Which ROM developer still includes those commands on their custom ROMs ?! When we know it causes bricks ?!
Click to expand...
Click to collapse
Chainfire said:
Confirmed, found this line in updater-script:
format("ext4", "EMMC", "/dev/block/mmcblk0p9", "0");
That's the cause of your brick right there, PARANOIDANDROID ...
EDIT #1:
(MIDNOTE doesn't seem to have anything to do with this, but to be certain, I'm also checking that one ...)
EDIT #2:
MIDNOTE seems to be clean. Adjusting thread title to stop giving MIDNOTE a bad name
None of this is surprising, btw ...
Don't flash ParanoidAndroid for the time being !
Click to expand...
Click to collapse
Well well.. And Imilka knows this... he is a respected developer and still he made a tremendous error on this!

Chainfire said:
Confirmed, found this line in updater-script:
format("ext4", "EMMC", "/dev/block/mmcblk0p9", "0");
That's the cause of your brick right there, PARANOIDANDROID ...
EDIT #1:
(MIDNOTE doesn't seem to have anything to do with this, but to be certain, I'm also checking that one ...)
EDIT #2:
MIDNOTE seems to be clean. Adjusting thread title to stop giving MIDNOTE a bad name
None of this is surprising, btw ...
Don't flash ParanoidAndroid for the time being !
Click to expand...
Click to collapse
I guess I was lucky. I flashed paranoid android a few days ago and used it for a couple of days. Just got off it to try another rom. I was just considering reflashing it back.
Now I have a quick question, IF you are say on ParanoidAndroid or any other ROM that has something like that on it's code BUT you are on a kernel with the command disabled... is there still a risk of bricking the phone?

Already contacted Imilka on this issue!! What a tremendous error!
I am starting to develop Midnote and even i, yes i am an amateur compared to all you senior devs out here, even i know that using format command triggers the bug!
Chainfire thanks for reading my PM
And thanks Entropy for all your hard work on this bug!
Thank you both for all

If you are running a kernel that has the ERASE command disabled in the kernel itself, I believe you are safe.
But many kernels are not safe, and thus we should avoid using the format command altogether.
This is not imilka's fault, or my fault, or zylor's fault, or anything. It's a combination of factors that creates a dangerous situation, a combination of factors that we hope Samsung will fix soon in their kernels !

Chainfire said:
If you are running a kernel that has the ERASE command disabled in the kernel itself, I believe you are safe.
But many kernels are not safe, and thus we should avoid using the format command altogether.
This is not imilka's fault, or my fault, or zylor's fault, or anything. It's a combination of factors that creates a dangerous situation, a combination of factors that we hope Samsung will fix soon in their kernels !
Click to expand...
Click to collapse
I am waiting for Samsung to fix it... but damn... in a full week i had my Note bricked twice! What a damn record..
Next time i'll make sure that i review the updater-script before flashing a rom!

Chainfire said:
Confirmed, found this line in updater-script:
format("ext4", "EMMC", "/dev/block/mmcblk0p9", "0");
That's the cause of your brick right there, ...
Don't flash ParanoidAndroid for the time being !
Click to expand...
Click to collapse
So the error will occur when flashing the affected ROM and not when flashing another ROM from it. Just double checking.
Can a script be developed to check for this line in a ROM.

Chainfire said:
If you are running a kernel that has the ERASE command disabled in the kernel itself, I believe you are safe.
But many kernels are not safe, and thus we should avoid using the format command altogether.
This is not imilka's fault, or my fault, or zylor's fault, or anything. It's a combination of factors that creates a dangerous situation, a combination of factors that we hope Samsung will fix soon in their kernels !
Click to expand...
Click to collapse
Thank you for the clarification. And thank you to all the devs who works on our wonderful device. IMO you guys do better work than samsung devs.
We all know the risks going into rooting and flashing. I myself bricked my note trying to flash a rom during the early days of this bug. Kudos to Samsung for replacing the mother board without cost but I do hope they resolve this issue asap.

XXLS1 JB leak and eMMC "brickbug" safety

I was going to put this in the JB thread, but that has apparently been locked due to flaming.
As mentioned in other threads on the eMMC "brickbug", Samsung's official patch for this issue is NOT to remove MMC_CAP_ERASE, but to only disable secure erase in the kernel.
See: https://patchwork.kernel.org/patch/1383661/
Now, we've been highly disappointed that Samsung hasn't included this patch in many updates for a variety of devices. However, on analyzing the kernel, it appears it *might* be safe due to having Samsung's official patch.
If you unpack the kernel, and then run "strings" on the unpacked image, you will see the following:
Code:
M8G2FA
MAG4FA
MBG8FA
MCGAFA
VAL00M
VYL00M
KYL00M
VZL00M
e.g. the exact list from the above patch, in the correct order.
So it looks like the XXLS1 JB leak is *probably* safe from the Brickbug - unless Samsung is wrong about nonsecure erase being safe.

+1
Good news for Note Community

I agree..... thanks for taking the time to share your findings with us.
:good:

Good to see some improvements from Samsung! Thanks a lot Entropy.. without your precious help this wouldn't be possible

Many thanks Entropy..
So now we can do full wipe without any fear...??
Sent from my GT-N7000 using xda app-developers app

Brilliant..thanks mate!
Sent from my GT-N7000 using xda premium

thanks for the update.
Its great to see people like you care for the rest

Entropy512 said:
I was going to put this in the JB thread, but that has apparently been locked due to flaming.
As mentioned in other threads on the eMMC "brickbug", Samsung's official patch for this issue is NOT to remove MMC_CAP_ERASE, but to only disable secure erase in the kernel.
See: https://patchwork.kernel.org/patch/1383661/
Now, we've been highly disappointed that Samsung hasn't included this patch in many updates for a variety of devices. However, on analyzing the kernel, it appears it *might* be safe due to having Samsung's official patch.
If you unpack the kernel, and then run "strings" on the unpacked image, you will see the following:
Code:
M8G2FA
MAG4FA
MBG8FA
MCGAFA
VAL00M
VYL00M
KYL00M
VZL00M
e.g. the exact list from the above patch, in the correct order.
So it looks like the XXLS1 JB leak is *probably* safe from the Brickbug - unless Samsung is wrong about nonsecure erase being safe.
Click to expand...
Click to collapse
Well, well.
Samsung finally at last!
Thanks Entropy for the good find.

Lets hope Samsung did a good job !
Now to download that leak.......

I am still wondering about the update. If we have the brick bug in ics how are we able to flash ota jelly bean?? Wont there be chances of bricking while updating our phone to jb.
Sent from my GT-N7000 using xda app-developers app

qazibasit said:
I am still wondering about the update. If we have the brick bug in ics how are we able to flash ota jelly bean?? Wont there be chances of bricking while updating our phone to jb.
Sent from my GT-N7000 using xda app-developers app
Click to expand...
Click to collapse
The usual applies... Flashing anything via Odin is safe. Flashing anything from a safe kernel is safe. Flashing something with a "safe" update-binary should be safe even on a dangerous kernel.
I'm not going to guarantee the safety of the XXLS1 kernel, as it's hard to guarantee that it is doing what we think it is, but it is PROBABLY safe as opposed to definitively dangerous like any previous official ICS kernel binary. We won't know unless people take risks unfortunately...

ok using the jb rom i did indeed soft brick has taken 5 hrs to get my note working, i had a custom rooted 404 rom on with hydracore install the jb with cwm and that was it stuck on samsung logo ,so i then tried to flash stock 404 with pc odin and was stuck on flashing fs image,finally got it working with the pit method and by updating bootloader and clear efs, this has kinda scared me as after a cple hrs trying that it would be sent to repair
be aware this worked for me it may not for anyone else

[/COLOR]
anubis1126 said:
ok using the jb rom i did indeed soft brick has taken 5 hrs to get my note working, i had a custom rooted 404 rom on with hydracore install the jb with cwm and that was it stuck on samsung logo ,so i then tried to flash stock 404 with pc odin and was stuck on flashing fs image,finally got it working with the pit method and by updating bootloader and clear efs, this has kinda scared me as after a cple hrs trying that it would be sent to repair
be aware this worked for me it may not for anyone else
Click to expand...
Click to collapse
I was going to write a sarcastic post but... that sucks
This means the Samsung work around did not work.
Either that or you might have repartitioned for no reason.
Did you try a nandroid restore first?

anubis1126 said:
ok using the jb rom i did indeed soft brick has taken 5 hrs to get my note working, i had a custom rooted 404 rom on with hydracore install the jb with cwm and that was it stuck on samsung logo ,so i then tried to flash stock 404 with pc odin and was stuck on flashing factoryfs....
Click to expand...
Click to collapse
So you bricked bricked flashing on Hydracore? I thought that was safe!

shoey63 said:
So you bricked bricked flashing on Hydracore? I thought that was safe!
Click to expand...
Click to collapse
He already flashed the jb leak, overwriting hc with its own kernel in the process. Flashing back to 4.0.4 on the leaked rom caused the soft brick, NOT hc.
Sent from my Asylumized shopping cart.

randomtext said:
He already flashed the jb leak, overwriting hc with its own kernel in the process. Flashing back to 4.0.4 on the leaked rom caused the soft brick, NOT hc.
Sent from my Asylumized shopping cart.
Click to expand...
Click to collapse
He used PC Odin to "flash back". I thought that was safe too!
Anyway odin stuck on factoryfs and needing PIT file method to revive Note is SUPERBRICK, not "softbrick"

Entropy512 said:
The usual applies... Flashing anything via Odin is safe. Flashing anything from a safe kernel is safe. Flashing something with a "safe" update-binary should be safe even on a dangerous kernel.
I'm not going to guarantee the safety of the XXLS1 kernel, as it's hard to guarantee that it is doing what we think it is, but it is PROBABLY safe as opposed to definitively dangerous like any previous official ICS kernel binary. We won't know unless people take risks unfortunately...
Click to expand...
Click to collapse
I've tried it a dozen times and seems to be ok
Ran the check and lost no memory at al
Thanks would be nice for my daring? Stupidity ? Did full wipes etc
Sent from my GT-N7000 using Tapatalk 2

howard bamber said:
I've tried it a dozen times and seems to be ok
Ran the check and lost no memory at al
Thanks would be nice for my daring? Stupidity ? Did full wipes etc
Sent from my GT-N7000 using Tapatalk 2
Click to expand...
Click to collapse
Actually it's the same as wiping on stock ICS recovery. Well done for trying to verify :thumbup:

what can i say i am a flashaholic flash at least once a week trying varied roms themes etc this time it just happened to me
redone pit file and gained a bit more space

anubis1126 said:
what can i say i am a flashaholic flash at least once a week trying varied roms themes etc this time it just happened to me
redone pit file and gained a bit more space
Click to expand...
Click to collapse
Happened to me too useing stupid Cwm.zip - accidentally hit factory reset and BANG! Superbrick! Thankfully grey retailer replaced it.:thumbup:
Sent from my GT-N7000 using xda app-developers app

[GT-I9300] Compilation of issues and fixes

The objective of this thread is to have all the knowns issues and known (or potential) fixes for the I9300 in an OP.
Latest Updates
- What to do if you only want warranty
- Updated CF-Auto-Root
- Perseus Kernel patched
Universal
There are mainly two major issues I've found around the forums: Exynos Root Exploit and Sudden Death (eMMC failure).
Exynos Root Exploit
alephzain said:
Recently discover a way to obtain root on S3 without ODIN flashing.
The security hole is in kernel, exactly with the device /dev/exynos-mem.
This device is R/W by all users and give access to all physical memory.
Click to expand...
Click to collapse
It was fixed by Samsung in the XELLA/XELLC kernel.
Stock ROMs collection.
Sudden Death
Sudden Death Syndrome (SDS): Some S3 devices which have a faulty eMMC chip seem to just die. Most victims have found their phone completely unresponsive while taking it out of charge. Some have managed to boot into download mode but are unable to flash any ROM (presumably because the NAND is already damaged).
There are two theories of this: both are explained below:
rlorange said:
Guys we don't know enough to say for sure that previous faulty wear leveling has already dine damage.
According to the best informed guess by Entropy, the faulty wear leveling firmware causes a brick only when it decides to move critical data to fresh block which DOESN'T EXIST.
Wear leveling works by keeping track of read/write cycles for data blocks. The faulty emmc controller is guessed to have a bad block address move as part of it's wear leveling which causes the failure.
There is no evidence that the brick happens because of too many read/writes in one place which eventually fails (Theory 1). Rather if and when the wear leveling controller moves a block there is a bug which screws this up somehow (Theory 2).
Assuming the kernel patch prevents the emmc wear leveling code from triggering the buggy block move then it really will prevent the affected NAND chips from ever failing.
We don't yet know for Sure but Entropy seems to think that the failure event is triggered during normal wear level block moving which goes wrong and does the damage then. Not the other scenario of the wear leveling actually never moving blocks thus after time eventually "wearing a block out" due to too many read/write cycles.
Click to expand...
Click to collapse
rootSU said:
The "Sudden Death" issue is caused by firmware on the (16 GB) VTU00M, revision 0xf1 eMMC (Embedded MultiMedia Card or internal memory if you like). Samsungs Kernel Source Code (Update 7) has been identified as the fix.
Click to expand...
Click to collapse
Appropriate fixes found in the OP.
NOTE
A lot of people seem to be confused about this: there are effectively two kernels that need to be patched: the obvious one: which Android runs on, and also the less obvious recovery.
- If you are running stock, flashing LLA onwards is enough to prevent further NAND damage
- If you are running a custom ROM or flashing a custom recovery, make sure you flash a patched recovery!
As of 14th January 2013:
EViollet said:
You have 3 different software parts on the GS3:
* bootloader
* recovery
* rom
The bootloader appears not to have the fix. NO bootloader is currently known to have the fix. So, any version will do. It won't protect you.
There is currently ONE known recovery that includes the kernel that fixes the SDS : philz recovery. No more.
ROM. This is what you're running on your phone. It comes bundled with a kernel. The SDS fix is included in the kernel. If you use the latest Siyah kernel, then you're safe. Up until the moment you boot recovery. Then you depend on the recovery you currently have on your phone.
Siyah kernel, however, has a peculiarity: it comes bundled with it's own TEMPORARY recovery that is used to manage 2 ROMs.
If you reboot in recovery from the Siyah STweaks tool, then you'll be using the Siyah recovery, which is correctly patched.
If you reboot in recovery from the ROM (or any other means of rebooting to recovery), you'll be back on your default recovery.
You can also "hijack recovery" from the Siyah STweaks tool. This will overwrite your current recovery with the Siyah recovery. And you will be protected whichever means of rebooting to recovery you choose.
Click to expand...
Click to collapse
rootSU said:
For those who don't care about being "safe" and only care about warranty, the step is simple.
Step 1: Do nothing
For those who don't care about being "safe" and only care about warranty AND are rooted
[Step 0: Flash ICS sboot]
Step 1: Reset flash counter
Step 2: Flash stock ROM [flashing patched firmware should make you "safe" too]
Click to expand...
Click to collapse
As of now ClockworkMod recovery is not patched.
Use PhilZ recovery instead.
Siyah kernel has been patched.
rootSU said:
Chainfire has updated to the ELLC recovery in Cf-auto-root
Click to expand...
Click to collapse
Update:
Patched Perseus Kernel
AndreiLux said:
Perseus alpha31 (09/01):
Removed my own security fixes and replaced them with the official Samsung one. I guess it can now be disclosed: exynos-mem was only one of multiple entry-points for the memory exploit. We discovered the s5p-smem exploit ourselves back in December but kept it quiet, I fixed that one back in version 29.2 without mentioning. Nobody was secure from a smart exploiter up until then, SuperCurios or Chainfire's software fixes are also just patching a single hole in what is a Swiss cheese. Kernels >v31 and beyond stock LLA are now the only truly protected ones.
Samsung's fix for the sudden death syndrome (SDS) included. It is caused by eMMC failure on phones with VTU00M internal memory chips with revision 0xF1. You can check your phone with the "eMMC Brickbug Check" in the Play Store (Ignore the message if it says you're not affected, the type and revision is what matters). The patch is a firmware soft-patch that is applied on every boot and MMC resume, it is not a permanent fix. You will need to stay forever on kernels which include the patch, this also includes updated recoveries and their embedded kernels.
Some other minor MMC changes extracted from Update 7 sources.
Click to expand...
Click to collapse
Bootloader Exclamation Mark
Apparently after flashing LLA bootloader, the red exclamation mark notoriously keeps reappearing unless you follow very specific steps, involving TraingleAway, recovery and ODIN flashing.
Original thread
EdgaBimbam said:
To start with, I'm flash addict and always trying to flash new roms/firmwares. However after flashing one of the newest samsung firmware i got this little red exlamation mark
Click to expand...
Click to collapse
Thread listing workarounds
Android 4.2 (CyanogenMod 10.1)
NFC Fix
It seems most devices coming from Stock Jellybean 4.1 to JB 4.2 are facing broken NFC. The current considered permanent solution is to:
1) Take a Nandroid backup
2) Flash a stock 4.0 ROM
3) Switch on WiFi and NFC
4) Restore from Nandroid
There is also a separate fix for CM10.1. ONLY apply the fix if your NFC is not working.
View attachment NFCFix.zip
Official CM10.1 discussion thread
Note: Not sure if this is a CM-specific issue. Let me know if that is the case.

don't you mean devices coming from Jellybean 4.1 to Jellybean 4.2? coming from ICS to JB 4.2.1 doesn't have the issue with NFC.
just checking.
EDIT: minor typo fixed.

you can add the downgrade from LLA bootloader to avoid the red exclamation mark..

''It seems most devices coming from Ice Cream Sandwich to Jellybean 4.2 are facing broken NFC.''
I think you meant devices coming from STOCK Jelly Bean to CM10.1 are facing the NFC problems

thegh0sts said:
don't you mean devices coming from Jellybean 4.1 to Jellybean 4.2? coming from ICS to JB 4.2.1 does have the issue with NFC.
just checking.
Click to expand...
Click to collapse
erto90 said:
you can add the downgrade from LLA bootloader to avoid the red exclamation mark..
Click to expand...
Click to collapse
PLUG313 said:
I think you meant devices coming from STOCK Jelly Bean to CM10.1 are facing the NFC problems
Click to expand...
Click to collapse
Done!

me thinks the NFC issue exists is because of the updated firmware in stock JB 4.1 and for some reason it can't communicate with CM10.1.

you can add my "KeepRil" zip if you like ... http://forum.xda-developers.com/showpost.php?p=35790900&postcount=1069

75markus said:
you can add my "KeepRil" zip if you like ... http://forum.xda-developers.com/showpost.php?p=35790900&postcount=1069
Click to expand...
Click to collapse
Is it a fix to a known issue of this phone? My understanding was that you need a matched RIL and Modem no matter what, i.e., it's not an "issue" as such, it's a technical constraint.

what about sdcard0/0 ... 0 issue ?
is not a real issue , i know , is just the way should be when running CM 10.1 Android 4.2.1
i think people found difficulties to understand how it works and how to deal with it in view of reverting to a Sammy Rom ... etc
i opened a thread in Q&A but i`m not sure if is complete or/and helpful enough
have a look please :angel:
http://forum.xda-developers.com/showthread.php?t=2075162

xanthrax said:
what about sdcard0/0 ... 0 issue ?
is not a real issue , i know , is just the way should be when running CM 10.1 Android 4.2.1
i think people found difficulties to understand how it works and how to deal with it in view of reverting to a Sammy Rom ... etc
i opened a thread in Q&A but i`m not sure if is complete or/and helpful enough
have a look please :angel:
http://forum.xda-developers.com/showthread.php?t=2075162
Click to expand...
Click to collapse
As far as I recall, It's an Android 4.2 "feature" (or issue, whatever way you look at it), not really specific to either CM or the I9300 device in particular.

pickandwhammy said:
As far as I recall, It's an Android 4.2 "feature" (or issue, whatever way you look at it), not really specific to either CM or the I9300 device in particular.
Click to expand...
Click to collapse
is this from your signature ?
ROM: CyanogenMod 10.1 (Android 4.2.1) Latest Nightly
don`t you have this sdcard 0 feature ?
of course is not specific to sg s3 but is specific for a ROM available for sg s4 ...
you confused me ... i`ll think about it ...

xanthrax said:
is this from your signature ?
ROM: CyanogenMod 10.1 (Android 4.2.1) Latest Nightly
don`t you have this sdcard 0 feature ?
of course is not specific to sg s3 but is specific for a ROM available for sg s4 ...
you confused me ... i`ll think about it ...
Click to expand...
Click to collapse
What I meant was it's a Google feature, which turns out to be not-very-user-friendly on phones (as opposed to tablets). It's not an issue with the device, be it hardware or firmware.

KERNEL issue or bootloader ?
pickandwhammy said:
The objective of this thread is to have all the knowns issues and known (or potential) fixes for the I9300 in an OP.
Exynos Root Exploit
It was fixed by Samsung in the XELLA/XELLC bootloader.
Click to expand...
Click to collapse
I thought Exynos bug was solved by KERNEL fix (XELLA , Perseus) .... NOT bootloader ??
could you please confirm ,
Thks

Got my answser : the exynos fix is in the kernel NOT in the booloader ...

philgalaxs3 said:
Got my answser : the exynos fix is in the kernel NOT in the booloader ...
Click to expand...
Click to collapse
Please post the thread/post URL elaborating on that, I'll update the first post with it.

pickandwhammy said:
Please post the thread/post URL elaborating on that, I'll update the first post with it.
Click to expand...
Click to collapse
Thks for the post update . But sorry I don't understand your "thread/post URL" remark ? seems Im on the correct thread and no need any URL ?

philgalaxs3 said:
Thks for the post update . But sorry I don't understand your "thread/post URL" remark ? seems Im on the correct thread and no need any URL ?
Click to expand...
Click to collapse
Okay. I thought the bootloader was initially believed to be the fix, and then the kernel, so I guess it was my misunderstanding. Since I've never run stock, I've never had any first-hand experience

Okay ! Not easy to know everything ! and thks again for your compile post :good:

Thanks
Sent from my GT-I9300 using xda app-developers app

Hello, first thanks alot of ur topic giving us solutions to protect our phones from SDS , but i wanna add something , there is another patched kernel beside Siyah one, its Perseus kernel .
Envoyé depuis mon GT-I9300 avec Tapatalk