Related
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.
I have flashed my rooted SGN to LPY ROM using mobile ODIN. First two days i had issues however now it seems fine.
1. Battery working fine 24Hrs on average with single charge (With 3G and Wifi on always)
2. No issues with screen or swype.
3. No issues with any other apps as of now
With all the Kernel related posts i'm a little worried. My phone kernel also shows as XXLPY. Please suggest if I need to do anythig to fix it.
Sent from my GT-N7000 using XDA
just do not do any full wipe, either from phone or CWM and you should be safe.
cracklenet said:
I have flashed my rooted SGN to LPY ROM using mobile ODIN. First two days i had issues however now it seems fine.
1. Battery working fine 24Hrs on average with single charge (With 3G and Wifi on always)
2. No issues with screen or swype.
3. No issues with any other apps as of now
With all the Kernel related posts i'm a little worried. My phone kernel also shows as XXLPY. Please suggest if I need to do anythig to fix it.
Sent from my GT-N7000 using XDA
Click to expand...
Click to collapse
Danger lies in changing ROMs, as long as you keep it you're safe.
Should you decide to flash sth different, then read the instructions several times, then again, and one more time, part of the bricks happened due to small mistakes by experienced flashers.
Sent from my GT-N7000 using xda premium
Is Full wipe and Factory Reset the same?
After installing the ROM i had done a factory reset. Nothing happemed but for some setting changes. I'm able the use without issues.
Please advise.
Sent from my GT-N7000 using XDA
cracklenet said:
Is Full wipe and Factory Reset the same?
After installing the ROM i had done a factory reset. Nothing happemed but for some setting changes. I'm able the use without issues.
Please advise.
Sent from my GT-N7000 using XDA
Click to expand...
Click to collapse
yeah someone pls reply to this question cause i flashed LPY twice and i did the factory reset and cleared the cache but did not get any problem.
I also flashed and wiped a couple of times while in LPY. I'm having no problems so far, but I read someone tried to flash with PC Odin and brocked because his eMMC was ALREADY damaged.
Is there a way to know if my device has some kind of damage?
aami.aami said:
yeah someone pls reply to this question cause i flashed LPY twice and i did the factory reset and cleared the cache but did not get any problem.
Click to expand...
Click to collapse
Wipe data/factory reset is where the problem lies. You can do it and be fine but you could do it again and be bricked. I did a wipe after install before the problem was known.
Just do what has already been posted don't factory reset from cwm or settings. If changing rom read everything several times before flashing
Sent from my GT-N7000 using xda premium
cracklenet said:
I have flashed my rooted SGN to LPY ROM using mobile ODIN. First two days i had issues however now it seems fine.
1. Battery working fine 24Hrs on average with single charge (With 3G and Wifi on always)
2. No issues with screen or swype.
3. No issues with any other apps as of now
With all the Kernel related posts i'm a little worried. My phone kernel also shows as XXLPY. Please suggest if I need to do anythig to fix it.
Sent from my GT-N7000 using XDA
Click to expand...
Click to collapse
I am in the same boat as you bro. I think that you should stick to ICS for now. I am doing the same. It seems that google and samsung are already aware of this bug so i choose to wait instead of risking a bad flash. It seems that none of the methods are 100% right now so just i recommend you stick to ICS just be cautious and don't delete large files (larger than 1gb) and don't use CWM nor factory reset for now... In the end we are lucky we didnt get our devices bricked in the first place.
yllivia said:
I am in the same boat as you bro. I think that you should stick to ICS for now. I am doing the same. It seems that google and samsung are already aware of this bug so i choose to wait instead of risking a bad flash. It seems that none of the methods are 100% right now so just i recommend you stick to ICS just be cautious and don't delete large files (larger than 1gb) and don't use CWM nor factory reset for now... In the end we are lucky we didnt get our devices bricked in the first place.
Click to expand...
Click to collapse
there is already new ICS LPF, reportedly safe and faster than LPY - there is also/already dr ketan's guide on whats and hows
yllivia said:
I am in the same boat as you bro. I think that you should stick to ICS for now. I am doing the same. It seems that google and samsung are already aware of this bug so i choose to wait instead of risking a bad flash. It seems that none of the methods are 100% right now so just i recommend you stick to ICS just be cautious and don't delete large files (larger than 1gb) and don't use CWM nor factory reset for now... In the end we are lucky we didnt get our devices bricked in the first place.
Click to expand...
Click to collapse
yea ,,in the same boat as well and equally confused man .....
wish thr was a magic wand for this to fix it ,,,lol
so i guess most of us are finally deciding to stay on LPY even after entropy is saying to stay away from LPY ?
---------- Post added at 08:11 PM ---------- Previous post was at 08:10 PM ----------
p107r0 said:
there is already new ICS LPF, reportedly safe and faster than LPY - there is also/already dr ketan's guide on whats and hows
Click to expand...
Click to collapse
u see the issue with that idea is that most of us have already wiped the cache after installing LPY so now trying to go to LPF cud potentially result in bricking it .....what do ?
p107r0 said:
there is already new ICS LPF, reportedly safe and faster than LPY - there is also/already dr ketan's guide on whats and hows
Click to expand...
Click to collapse
From what i have read LPF has 0x19 firmware therefore has potentialy the same problem with bricking
Sent from my GT-N7000 using xda premium
Being afraid of the bug I flashed a rooted GB kernel before using Odin to upgrade from LPY to LPF The bug is apparently in the way the kernel sets the emmc chip erase process This apparently mainly affects the /data partition so flashing a gb kernel should be safe. I then used odin to update to the newer firmware.
Sent from my GT-N7000 using xda premium
gurnishdhillon said:
yea ,,in the same boat as well and equally confused man .....
wish thr was a magic wand for this to fix it ,,,lol
so i guess most of us are finally deciding to stay on LPY even after entropy is saying to stay away from LPY ?
---------- Post added at 08:11 PM ---------- Previous post was at 08:10 PM ----------
u see the issue with that idea is that most of us have already wiped the cache after installing LPY so now trying to go to LPF cud potentially result in bricking it .....what do ?
Click to expand...
Click to collapse
As far as i know there has been no reports of bricks on LPF but most of the people that flashed LPF flashed it from GB. We in the other hand are stuck we might have a leftover from flashing LPY. I would rather risk downgrading to GB then jumping to another unsettled ship. I am staying here just taking precautions NOT to use Recovery nor any kind of thing that involves wiping data.
Originally Posted by Chainfire
Ok so it still isn't really clear if the problem is still present in LPY, or if the issue is "left-over" due to previous ROMs.
It's all possible. Either way, what I wan't to make absolutely clear again:
If the problem is present in CF-Root LPY (and it's not a "leftover" problem from previous ROM - this is possibly the case), then it's also present in stock LPY. This means you *can* randomly brick your phone even if fully booted into Android, under heavy I/O load.
(on the Note there normal and recovery kernels are the same, and CWM is just a userspace program, nothing special(!) - so if the problem can happen in CWM, it can happen in Android)
Click to expand...
Click to collapse
gurnishdhillon said:
yea ,,in the same boat as well and equally confused man .....
wish thr was a magic wand for this to fix it ,,,lol
so i guess most of us are finally deciding to stay on LPY even after entropy is saying to stay away from LPY ?
---------- Post added at 08:11 PM ---------- Previous post was at 08:10 PM ----------
u see the issue with that idea is that most of us have already wiped the cache after installing LPY so now trying to go to LPF cud potentially result in bricking it .....what do ?
Click to expand...
Click to collapse
What you can do is only swap the kernel using mobile odin. I swapped it with the LPF CF-Kernel and everything is fine. But be advised, LPF has not been confirmed to be save yet.
Sent from my Galaxy Note running ICS
cracklenet said:
Is Full wipe and Factory Reset the same?
After installing the ROM i had done a factory reset. Nothing happemed but for some setting changes. I'm able the use without issues.
Please advise.
Sent from my GT-N7000 using XDA
Click to expand...
Click to collapse
Yes. The problem is intermittent - you can often wipe once or twice, sometimes even ten times, before getting nailed.
Others (like xplodwild) get nailed the first time.
craig432 said:
From what i have read LPF has 0x19 firmware therefore has potentialy the same problem with bricking
Sent from my GT-N7000 using xda premium
Click to expand...
Click to collapse
No, XXLPY/ZSLPF don't "have" the eMMC firmware. The eMMC firmware is part of the eMMC chip itself - right now, whatever you have is what came with your phone. There is currently no way to change it.
The problem is that the firmware has a bug that will cause it to sometimes do VERY bad things if an erase command is sent to it:
I9100 update4 kernels don't support MMC ERASE at all - so they don't trigger the bug in the firmware in the first place
M250S Update5 does - So it triggers the bug - We don't have source for any other ICS kernel yet but I suspect they all have MMC_CAP_ERASE set
What I can't figure out is why Gingerbread isn't dangerous despite having MMC_CAP_ERASE set. I need to read in more detail, but it might be that even if the driver supports MMC_CAP_ERASE, some other change between 2.6.35 and 3.0 makes ERASE get used in situations it didn't get used in previously.
You need two things: buggy firmware (so far, nearly every Note and Exynos-based GS2 has this) and a kernel that will fire ERASE commands at the chip when wiping.
If a method can be found to update the flash chip's firmware, then XXLPY and ZSLPF will become safe when running on fixed chips.
Hey entropy is it possible to use the cm9 kernel with lpy? I'm assuming it is but don't want to take any risks
Somebody please shed light on this ?
- Is it possible that affected kernels inflict damage every time you perform factory reset or wipe data from recovery but it does not brick your phone.
But in future it might get bricked even on safe kernel just because you had used affected kernels ??
**** I had used recovery on LPY many times.
More info and source credits here, thanks to codeworkx https://plus.google.com/111398485184813224730/posts/21pTYfTsCkB.
ATTENTION:
We've contacted Samsung about the problem where performing a mmc erase could hardbrick your phone (i9100, i9100g, n7000, m250 - MAG4FA, VYL00M, and KYL00M with firmware revision 0x19 // T989 and I727 with fw rev 0x12) if it's having a faulty emmc chip.
Read this thread for more informations about it: http://forum.xda-developers.com/showthread.php?t=1644364
They're working as hard as possible on a clean solution which will be ready soon.
Please be patient and try to not flash any leaked kernels or kernels based on sources where MMC_CAP_ERASE is present.
This app http://forum.xda-developers.com/showpost.php?p=27014974&postcount=1 can be used to identify if your phone is affected or not.
CM9 kernels are safe to flash.
Please share!
Update 14:56 CEST:
Patches will be out in form of new official ROMs and also sourcecode releases after testing, which might take some time.
Click to expand...
Click to collapse
New Clarifications by Entropy : http://forum.xda-developers.com/showpost.php?p=28416723&postcount=403 - Must Read.
To check whether your phone has the brick bug, download the Got Brickbug app from Chainfire: http://forum.xda-developers.com/showthread.php?t=1693704
Also do read the article on xda for more info.: http://www.xda-developers.com/android/samsung-diligently-working-towards-hardbrick-fix/
Nice!
That is a really good news after some time.
Sent from my GT-N7000 using Tapatalk 2
Good news!
Looking forward to see how Samsung solve this nightmare
Sent from my GT-N7000 using xda premium
How many time to fix this Samsung BUG? How maby people need ti brick our 600€? If samsung knows why no first before? Grrrrr...
All hard work its from XDA devs!!!! Thank you devs!!
Enviado desde mi GT-N7000 usando Tapatalk 2
Hmmm don't want to get my hopes up
But hmmm ok let's hope saw but how do we know is true ?
Sent from my iPad using Tapatalk
nandihno said:
Hmmm don't want to get my hopes up
But hmmm ok let's hope saw but how do we know is true ?
Sent from my iPad using Tapatalk
Click to expand...
Click to collapse
Teamhacksung dev codeworkx been in touch with Sammy guys so its genuine news...check link in op
Sent from my GT-N7000 using xda premium
at least we now have some hope...hopefully...
So to be clear...
Can someone confirm the following is correct please?
I have a N7000 on official (german) ICS, with the dodgy mmc chip. I must have been lucky since ive flashed a bunch of roms (including CM9, back to gingerbread, then official ICS) without issue. Ive also done a few CWM backup and restores... phew!
1. Flashing anything from the phone itself (eg using mobile odin or CWM recovery) is a no-go (assuming it issues the erase command)
2. Flashing from the PC is OK ??? (via desktop ODIN)?
If 2 is untrue, how is sammy gonna issue an update (with the erase capability turned off) without bricking a load of phones during the update process? can they maybe provide a custom app which re-flashes the kernel without doing an erase first?
thanks
George
ripnetuk said:
Can someone confirm the following is correct please?
I have a N7000 on official (german) ICS, with the dodgy mmc chip. I must have been lucky since ive flashed a bunch of roms (including CM9, back to gingerbread, then official ICS) without issue. Ive also done a few CWM backup and restores... phew!
1. Flashing anything from the phone itself (eg using mobile odin or CWM recovery) is a no-go (assuming it issues the erase command)
2. Flashing from the PC is OK ??? (via desktop ODIN)?
If 2 is untrue, how is sammy gonna issue an update (with the erase capability turned off) without bricking a load of phones during the update process? can they maybe provide a custom app which re-flashes the kernel without doing an erase first?
thanks
George
Click to expand...
Click to collapse
Flashing is not the problem but wiping is
So if they release a new update then simply don't wipe on your ics but wipe only after you install the new update
If however you want to be extra careful like I am
Flash a gb rom via odin then wipe that then flash said ics update via Odin
Sent from my iPad using Tapatalk
While there have been brickage reports using either PC Odin or CWM, there have been none regarding Odin Mobile Pro. So, when I flashed back GB, I used Odin mobile Pro. Everything went smooth.
//troll mode activated
It's just like Microsoft patching windows vista
//troll mode off
This is a true victory for XDA developers!
My deepest respect for all of you guys :thumbup:!!
Are they releasing a fix for brickd phone or a prevention update?
blue_panther9_9 said:
Are they releasing a fix for brickd phone or a prevention update?
Click to expand...
Click to collapse
Prevention.
Sent from my GT-N7000 using xda premium
I really hope this mess will soon be over. Let's hope while they are resolving the brick bug they also take a look at the wakelock thing. Contrary to others I have encountered this problem very rarely (1 time so far). Nonetheless it would be nice to see a solution.
Sent from my Galaxy Note running ICS
Good news but given that we haven't seen ics roll out in all countries, who knows when this will get fixed.
Another thing that bugs me. Is there possibility that Samsung push the solution for this bug and carriers just ignore it and continue with pushing the infected ics?
I guess that all we need is just one good release and everyone can flash it.
Hope to see it soon.
Sent from my Samsung Galaxy Note using XDA app
ripnetuk said:
Can someone confirm the following is correct please?
If 2 is untrue, how is sammy gonna issue an update (with the erase capability turned off) without bricking a load of phones during the update process? can they maybe provide a custom app which re-flashes the kernel without doing an erase first?
Click to expand...
Click to collapse
In all probability it might show a message over kies / OTA message asking to connect to kies on the comp .. and provide an update for kies desktop having 0din in it
ashoksoft said:
In all probability it might show a message over kies / OTA message asking to connect to kies on the comp .. and provide an update for kies desktop having 0din in it
Click to expand...
Click to collapse
Update 14:56 CEST:
Patches will be out in form of new official ROMs and also sourcecode releases after testing, which might take some time.
Just updated op too
This is great news! Many thanks to entropy and chasmodo and all who've worked on this and sacrificed for us!
Also thanls to those who took it seriously.
Sent from my GT-N7000 using xda premium
It was nice 8 months experience,just Super bricked my Note while perfotming a wipe with CWM,too bad couldnt claim the warrenty.
Thanks for everyone who helped me during this period,both Developers and Members.
Jack
Sorry for your phone man.
Btw which kernel were you using?
Boy124 said:
Sorry for your phone man.
Btw which kernel were you using?
Click to expand...
Click to collapse
German LRK DBT stock 4.0.4 and it was running fine no problems,just wiped it to test the Paranoid Android JB 4.1.1,which was actually the last thing it did.
I see. But you can't flash roms using stock recovery. Anyways it confirms the bug still exists.
What CWM did you use or did you wipe from stock recovery?
Does it give any sign of life?
If it boots you can use: https://play.google.com/store/apps/details?id=net.vinagre.android.emmc_check
to see if you have emmc damage.
jgaviota said:
What CWM did you use or did you wipe from stock recovery?
Does it give any sign of life?
If it boots you can use: https://play.google.com/store/apps/details?id=net.vinagre.android.emmc_check
to see if you have emmc damage.
Click to expand...
Click to collapse
Unfortunately doesnt boot up,just stuck on the Gt-7000 logo but the download screen works,however when try to flash with PC Odin stops at the factoryfs.img which after research discovered is a Superbrick symptom.
hagba said:
too bad couldnt claim the warrenty.
Click to expand...
Click to collapse
Hello hagba, since you cannot claim warranty have you thought of getting your device repaired via the Samsung service centre in your region?
I would suggest you to enquire about the repair cost and then make a suitable decision.
Have you tried this? it worked for many users.
http://forum.xda-developers.com/showthread.php?p=26285877
YLNdroid said:
Hello hagba, since you cannot claim warranty have you thought of getting your device repaired via the Samsung service centre in your region?
I would suggest you to enquire about the repair cost and then make a suitable decision.
Click to expand...
Click to collapse
First thing on monday,
dr.ketan said:
Have you tried this? it worked for many users.
http://forum.xda-developers.com/showthread.php?p=26285877
Click to expand...
Click to collapse
Dr.Ketan,
I have tried the PIT procedure,but its such a long and tedious process Im not sure will be able to make viable partition for normal usage.
However will see what Samsung does on Monday.
So does this mean that Stock ROMS are still unsafe to wipe rather than how samsung claims that Stock ROM wont brick?
Did you report this to Entropy? Did you wipe after flashing Paranoid ROM successfully or did you wipe on stock. If it was after succesfully flashing the CM10 based JB ROM, it should mean that CM10 doesnt have MMC_CAP_ERASE disabled or maybe no ICS kernel is safe.
Should report to Entropy if you didnt.
He already.wrote 'wipe it to test jb' means wiped on.stock.
Entropy aleeady aware of this (i have already reported 2 case on 4.0.4). And he hav mentioned on his thread, stock ics are known unsafe kernels.
Sent from my GT-N7000 using xda premium
dr.ketan said:
He already.wrote 'wipe it to test jb' means wiped on.stock.
Entropy aleeady aware of this (i have already reported 2 case on 4.0.4). And he hav mentioned on his thread, stock ics are known unsafe kernels.
Sent from my GT-N7000 using xda premium
Click to expand...
Click to collapse
I made a mistake of wiping twice from Settings under android in Indian Stock DDLP8 stock 4.0.3 but luckily never bricked. But now I take care not to. But do you think I may have caused damage in the first two wipes? I see no issues till now but just asked.
It cause damage once in while, not every wipe/reset result to brick (good if it was like that, sammy must have find solution then)
Still if you have any doubts find 'emmc brick bug' application from market n scan ur device.
Sent from my GT-N7000 using xda premium
dr.ketan said:
It cause damage once in while, not every wipe/reset result to brick (good if it was like that, sammy must have find solution then)
Still if you have any doubts find 'emmc brick bug' application from market n scan ur device.
Sent from my GT-N7000 using xda premium
Click to expand...
Click to collapse
I have the affected emmc firmware VYLOOM 0x19. Its just that I turned out to be lucky. I dont believe Samsung would fix the Indian firmware (4.0.3) while the bug remains on the latest 4.0.4 ROMS. If there is a fix from Samsung, we Indians are the ones who usually get it last. But strangely, I havent heard of any superbricked Indian Notes in this forum.
satishp said:
So does this mean that Stock ROMS are still unsafe to wipe rather than how samsung claims that Stock ROM wont brick?
Did you report this to Entropy? Did you wipe after flashing Paranoid ROM successfully or did you wipe on stock. If it was after succesfully flashing the CM10 based JB ROM, it should mean that CM10 doesnt have MMC_CAP_ERASE disabled or maybe no ICS kernel is safe.
Should report to Entropy if you didnt.
Click to expand...
Click to collapse
I think Samsung's claim was that you won't get bricked if you stick to stock and don't root. I'm not saying that's true . Even seems unlikely since I think you can factory wipe from the settings without root, IIRC (memory's rusty, haven't been on a stock ROM for ages).
There were some bricks with CM10, but only from people who flashed from stock ICS or stock ICS based ROMs. Flashing from the safe ICS kernels seems to still be safe.
satishp said:
But strangely, I havent heard of any superbricked Indian Notes in this forum.
Click to expand...
Click to collapse
Maybe that's because Indians are careful enough to read the instructions before risking their device? I doubt it's because Indian Notes have had some special pixie dust sprinkled over them while they passed customs.
If you dont mod your device then how many chances are.there to make hard reset device?
I know lot ppl they purchasing and selling.device without single reset.
So rooting opens.100 ways to explore ur device, simultaneously opens 100 ways to put u in situation,u needs reset. That is the only reason rate.of bricking is high with rooted device, but if you read carefully and avoid reset/wiping there is almost zero chances to brick.
And yes if you look, compare to selling of notes in india, u don't see indians are quite less on forum?
Sent from my GT-N7000 using xda premium
dr.ketan said:
If you dont mod your device then how many chances are.there to make hard reset device?
I know lot ppl they purchasing and selling.device without single reset.
So rooting opens.100 ways to explore ur device, simultaneously opens 100 ways to put u in situation,u needs reset. That is the only reason rate.of bricking is high with rooted device, but if you read carefully and avoid reset/wiping there is almost zero chances to brick.
And yes if you look, compare to selling of notes in india, u don't see indians are quite less on forum?
Sent from my GT-N7000 using xda premium
Click to expand...
Click to collapse
I'm really worried because you said if I avoid wiping I'm almost zero chance of briking.. I got my note clean, I mean I don't dare to put music and movies into it because then I don't dare to delete all those files... Will this brick my phone? I'm stock 4.0.4 rooted
Enviado desde mi GT-N7000 usando Tapatalk 2
Obviously the culprit is wiping with CWM,I have factory Reset million times with no consequences at all,and just once with CWM was enough to Superbrick it,and yes I was on stock ROM.
msedek said:
I'm really worried because you said if I avoid wiping I'm almost zero chance of briking.. I got my note clean, I mean I don't dare to put music and movies into it because then I don't dare to delete all those files... Will this brick my phone? I'm stock 4.0.4 rooted
Enviado desde mi GT-N7000 usando Tapatalk 2
Click to expand...
Click to collapse
It says big files shudn't be deleted. Though frankly speaking i have not seen any case brick by that, though we cant ignore comments from recognised developer.
But wat best idea i found to manage file is
Connect device with PC as mass storage and manage files from PC explorer. I believe that is safe way.
hagba said:
Obviously the culprit is wiping with CWM,I have factory Reset million times with no consequences at all,and just once with CWM was enough to Superbrick it,and yes I was on stock ROM.
Click to expand...
Click to collapse
That was your bad luck this time, otherwise both have same effect.
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