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 just read a news here in xda that mentioned CWM as the culprit of some hard bricked galaxy note devices. Is it possible that this case might happen to us 7.7 users? I'm bothered as I just installed CWM today.
Sent from my GT-P6800 using XDA Premium HD app
Sent from my GT-P6800 using XDA Premium HD app
kencad said:
I just read a news here in xda that mentioned CWM as the culprit of some hard bricked galaxy note devices. Is it possible that this case might happen to us 7.7 users? I'm bothered as I just installed CWM today.
Sent from my GT-P6800 using XDA Premium HD app
Click to expand...
Click to collapse
First of all: our eMMC chips have a major bug that can cause the device to be bricked. Same as the Note, the SGSII, and other Samsung models. This is a hardware bug, there is nothing we can do to correct it. (Actually, not ALL of those devices have the bug. Check yours with GotBrickbug?, but don't hold your hopes up.)
Now, this bug is only triggered under some situations. The trigger we're familiar with is when some eMMC operations (partition wipes, for example) are done with a kernel that has the option MMC_CAP_ERASE enabled.
The problem is that Samsung's 4.0.4 kernels have it enabled. This means that a stock kernel has a chance to brick your device. The stock recovery seems to trigger the bug less often than CWM, though. Stock kernels with CWM recoveries (the popular cf-root kernels for the SGS series, for example) are directly affected.
The good news is that our device uses one kernel for the system and one for the recovery. locerra's CWM includes a kernel with MMC_CAP_ERASE disabled. This means that locerra's CWM should be as safe as you can be.
Note that it's possible that there are other, not so widespread triggers for the hardware bug (I know of none, so, to the best of my knowledge, using locerra's CWM should make you safe). This means that until Samsung releases all the information and gets the bug completely isolated, it is possible that you will have problems. They most likely won't be CWM related, though.
EDIT: Please, let me make this as clear as possible. CWM does NOT brick devices. A hardware defect of the memory chip bricks devices. CWM (and the standard recovery, and possibly TWRP) can only trigger this defect.
Thanks for the informative reply.
Ps. : I flashed CWM recovery that I downloaded from the Internet. Can I replace it with locerra's? Is there any difference?
Sent from my GT-P6800 using XDA Premium HD app
The especially dangerous cwm was touch cwm.zip that was used for rooting ics. Do not use this temporary cwm. I bricked my note using it.
Sent from my GT-P6800 using xda premium
I actually used that cwm. Zip to root my tab. Phew! Good for me as my device wasn't bricked.
Ps. : when a device gets hard bricked, what does it mean? Is it dead? What is the best option when I'm hard bricked?
Anybody? Thanks
Sent from my GT-P6800 using XDA Premium HD app
means... your motherboard fried and need replacement...
Now, this bug is only triggered under some situations. The trigger we're familiar with is when some eMMC operations (partition wipes, for example) are done with a kernel that has the option MMC_CAP_ERASE enabled.
The problem is that Samsung's 4.0.4 kernels have it enabled. This means that a stock kernel has a chance to brick your device. The stock recovery seems to trigger the bug less often than CWM, though. Stock kernels with CWM recoveries (the popular cf-root kernels for the SGS series, for example) are directly affected.
The good news is that our device uses one kernel for the system and one for the recovery. locerra's CWM includes a kernel with MMC_CAP_ERASE disabled. This means that locerra's CWM should be as safe as you can be.
what then is the safest way to format my tab/restore to factory settings in ICS?
kencad said:
when a device gets hard bricked, what does it mean? Is it dead? What is the best option when I'm hard bricked?
Click to expand...
Click to collapse
It means that a portion of your internal memory went to an irremediably unusable state. Looks like it may be possible to get it back to life by using a specially tailored PIT (the thread is for the Note, but the OP added a PIT for the P6800 in the first post. He may build a PIT for other devices, if you ask him to). You lose a few GB of your /sdcard (data) storage, and all data on your device, but you get it back. The other option is to go to a Samsung's repair centre and say you left it charging overnight and couldn't turn it on in the morning, or something to that effect.
kencad said:
what then is the safest way to format my tab/restore to factory settings in ICS?
Click to expand...
Click to collapse
Install locerra's CWM and do the data reset from there. Alternatively, I've never seen someone get a brick by erasing through the Settings menu.
Thanks a lot. After reading this forum, I immediately searched for locerra's CWM and updated the one I installed. Now I have the v. 6.x.x.x and it's great.
Thanks steve_max for explaining and locerra for the CWM for 7.7
I just made a backup of my current rom(stock) and hopefully, I may try CM9 after some reading. (still a newbie)
Sent from my GT-P6800 using XDA Premium HD app
Hey everyone and thanks in advance. I have a couple questions..
Is safe strap the only recovery the RAZR m has at the moment? You can only allocate up go 3 gigs of data space per ROM... and I can't even so that because I don't have enough space.
Why is it that the maximum amount of internal data space I have is only 4 gigs... but it says out of 8 gigs.
When I had the droid 3, we could use a program to block the connection between the phone and Verizon so we could use the built in tethering apps... can we do the same thing for the M?
Lastly.. I see people talking about a dev and consumer version. What's the difference and which do I have.
Thanks!
To answer your first question, I must explain the answer to the last one. Dev edition can be bootloader unlocked, meaning custom recoveries can be flashed. Retail must use safestrap.
Sent from my XT907 using Tapatalk 2
So where do I start....I'm new and as such I obviously have a question.....Hey all!
I've been following this thread (http://forum.xda-developers.com/showthread.php?t=2369130&page=36) for a while regarding rooting and flashing android 4.3 on my S4 (International LTE). I have done so and I love it.
My question is why can't I access all my internal memory (16GB of it), It only shows at 9.25GB ish free. I know the stock S4 used a lot of memory, but why, after a wipe/reset can I still not access it? I would have thought it would be gone.
Is it a case of it being needed for use by my newly flashed 4.3 ROM (is the ROM using it as the stock one did), or is it just sitting there being wasted? How could I wipe it and what are the implications of doing so?
If this has been asked before I haven't looked hard enough, please link me to the relevant thread and I'll dispose of this one.
Many Thanks
Anthony
You can't use it because it is the system partition. It is reserved space.
Sent from my Nexus 7 using Tapatalk HD
OK thanks for the reply
Sent from my Nexus 7 using Tapatalk 4 Beta
Since after MM 6.0.1 update nightmare I am unable to use my N4 Canadian version, It started extremely freezing and lagging even without installing a single app, I flashed different custom ROMs and kernels even downgraded to Stock LP and even KK 4.4.4 but the problem remains the same.
After searching different threads I came across that EMMC ram is the culprit. Now I am wondering to perform Re-paration OR erase the NAND ram data but confused to do this because I never tried this before so need your advice.
Also anyone's knows how to check if the "system Partition OR EMMC is corrupted ?
Thanks
SM-n910w8
masood8 said:
Since after MM 6.0.1 update nightmare I am unable to use my N4 Canadian version, It started extremely freezing and lagging even without installing a single app, I flashed different custom ROMs and kernels even downgraded to Stock LP and even KK 4.4.4 but the problem remains the same.
After searching different threads I came across that EMMC ram is the culprit. Now I am wondering to perform Re-paration OR erase the NAND ram data but confused to do this because I never tried this before so need your advice.
Also anyone's knows how to check if the "system Partition OR EMMC is corrupted ?
Thanks
SM-n910w8
Click to expand...
Click to collapse
Well there is lots guides in general forum but it will reduce the lag and freezes but won't solve the emmc bug and it will get worse each day.
the only solution is to replace the motherboard.
If you're still under warranty they will replace the motherboard for free.
There's emmc bug check app in the playstore i am not sure if this app really works but you can give it a try https://play.google.com/store/apps/details?id=net.vinagre.android.emmc_check
Sent from my SM-N910G using Tapatalk
Thanks for the reply.
I already used this app but it says that my EMMC memory is fine.
I am confused now what is happening and what to do.
?