Hi guys, I've read in many places that all ROMs based on CM9 are safe from the hardbrick bug. Is this true? And if it is, why is it?
Sent from my GT-N7000 using XDA Premium HD app
robb13 said:
Hi guys, I've read in many places that all ROMs based on CM9 are safe from the hardbrick bug. Is this true? And if it is, why is it?
Sent from my GT-N7000 using XDA Premium HD app
Click to expand...
Click to collapse
The official CM9 kernel is safe from emmc_cap_erase, that is, the command called by the kernel in cases of wiping and mass deletion of data (typically within recovery). Coupled together with specific firmware versions of the Note's internal storage chips (usually fwrev 0x19, the most common version among the N7000) and data wiping via recovery, stock ICS kernels compiled for the N7000 currently run the risk of hardbricking by a corruption of the critical partitions. On the contrary, the official development of CM9 on the Note compiles its kernel from source code for the i9100 (update 4) which resolved possible emmc corruption because the emmc_cap_erase command is not evoked by the i9100 code. Hence, this "brick bug" does not rear its ugly head when data wipes are performed via the different kernel.
However, as I a not presently following N7000 Cyanogenmod, I am unaware if perhaps some developers decided to compile CM kernels for the Note by the recently released N7000 ICS source code. So, just make sure that whatever rendition of CM9 you want to run has a kernel compiled either from i9100 source, or else one in which the developer deliberately rid the kernel of the emmc_cap_erase command (at least before you perform data wipes, mass deletion of files, or NAND restores with ICS). For instance, I am presently running stock LQ2 ICS with Hardcore's kernel, which is compiled from N7000 source code, but has been rid of emmc_cap_erase. As a result, even this practically "stock" kernel is innocuous.
lurchbyrep said:
The official CM9 kernel is safe from emmc_cap_erase, that is, the command called by the kernel in cases of wiping and mass deletion of data (typically within recovery). Coupled together with specific firmware versions of the Note's internal storage chips (usually fwrev 0x19, the most common version among the N7000) and data wiping via recovery, stock ICS kernels compiled for the N7000 currently run the risk of hardbricking by a corruption of the critical partitions. On the contrary, the official development of CM9 on the Note compiles its kernel from source code for the i9100 (update 4) which resolved possible emmc corruption because the emmc_cap_erase command is not evoked by the i9100 code. Hence, this "brick bug" does not rear its ugly head when data wipes are performed via the different kernel.
However, as I a not presently following N7000 Cyanogenmod, I am unaware if perhaps some developers decided to compile CM kernels for the Note by the recently released N7000 ICS source code. So, just make sure that whatever rendition of CM9 you want to run has a kernel compiled either from i9100 source, or else one in which the developer deliberately rid the kernel of the emmc_cap_erase command (at least before you perform data wipes, mass deletion of files, or NAND restores with ICS). For instance, I am presently running stock LQ2 ICS with Hardcore's kernel, which is compiled from N7000 source code, but has been rid of emmc_cap_erase. As a result, even this practically "stock" kernel is innocuous.
Click to expand...
Click to collapse
Wow excellent answer. Thank you so much!
Sent from my GT-N7000 using XDA Premium HD app
is lq2 safe from the HardBrick Bug?
Did you even read the second post? No, no you didn't.
lurchbyrep said:
The official CM9 kernel is safe from emmc_cap_erase, that is, the command called by the kernel in cases of wiping and mass deletion of data (typically within recovery). Coupled together with specific firmware versions of the Note's internal storage chips (usually fwrev 0x19, the most common version among the N7000) and data wiping via recovery, stock ICS kernels compiled for the N7000 currently run the risk of hardbricking by a corruption of the critical partitions. On the contrary, the official development of CM9 on the Note compiles its kernel from source code for the i9100 (update 4) which resolved possible emmc corruption because the emmc_cap_erase command is not evoked by the i9100 code. Hence, this "brick bug" does not rear its ugly head when data wipes are performed via the different kernel.
However, as I a not presently following N7000 Cyanogenmod, I am unaware if perhaps some developers decided to compile CM kernels for the Note by the recently released N7000 ICS source code. So, just make sure that whatever rendition of CM9 you want to run has a kernel compiled either from i9100 source, or else one in which the developer deliberately rid the kernel of the emmc_cap_erase command (at least before you perform data wipes, mass deletion of files, or NAND restores with ICS). For instance, I am presently running stock LQ2 ICS with Hardcore's kernel, which is compiled from N7000 source code, but has been rid of emmc_cap_erase. As a result, even this practically "stock" kernel is innocuous.
Click to expand...
Click to collapse
So if I update using the stock ICS release and then update to the kernel you mentioned I should be safe from the hardbrick bug?
(sorry if this is a noob question, I have been reading a lot of threads but I don't understand most of the stuff being posted about this issue)
deviantish said:
So if I update using the stock ICS release and then update to the kernel you mentioned I should be safe from the hardbrick bug?
(sorry if this is a noob question, I have been reading a lot of threads but I don't understand most of the stuff being posted about this issue)
Click to expand...
Click to collapse
Yes, Hardcore's Speedmod and franco.kernel are both compiled from N7000 source and have the command which catalyzes the "bug" disabled. Our most knowledgeable devs on this forum have said that kernels like these make data wiping under ICS safe again. There are also kernels developed in our forum which are compiled from the i9100 Update 4 source, to which I refered earlier. These are also "safe."
I only put the word in quotations because this is no guarantee of any kernel's infallibility. Other "bugs" occur for some people (WiFi not working has been a common report, but certainly not universal). Also, some ICS kernels may be incompatible with some ROM versions (just read what people are saying on the thread). But as for the terror-striking eMMC "hard brick bug," these aforementioned kernels take that risk away, as our developers have concluded.
But with regard to the installation process, I would just go ahead and install an ICS ROM with one of the fixed kernels AT THE SAME TIME through Mobile Odin. Just have the app open the official update, and then change the kernel file to the zImage of a safe kernel. That way, you don't even have to go through the affected kernel. Though, you should be okay on the affected kernel if you're just using it to move to a safe one, and not wiping data, or performing factory resets, or deleting large files, or restoring NAND backups. But, why not err on the side of safety? It is, after all, a single-step method, and therefore simpler as well.
Related
Reinbeau asked me to summarize the situation with ICS leaks in a way that can be stickied, so here it is:
DO NOT FLASH OR WIPE USING ANY ICS REPACK
The list of "known safe" kernels is below in this post - there are currently two known-safe ICS kernels, but only two.
These kernels are fundamentally dangerous. Samsung introduced some sort of bug in the eMMC driver that can permanently damage the eMMC flash storage of the phone. This leads to unusable partitions at best, and at worst a hardbricked device. The nature of the failure is so severe that the usual method for hardbrick recovery (JTAG) is unable to recover devices damaged in this manner.
Kernels that have been confirmed affected are:
All ICS leaks for the Samsung Epic 4G Touch (SPH-D710)
All ICS leaks for the Samsung Galaxy Note (GT-N7000)
XXLPY official ICS release for GT-N7000 - at least one hardbrick (chasmodo), 2 people with damaged partitions (unusable /data or /system), at least 1 person with unusable /data after a wipe in *factory* recovery - it's not just CWM, and one person who hardbricked after wiping in Settings
ZSLPF official ICS release for GT-N7000 - http://forum.xda-developers.com/show....php?t=1661590 and http://forum.xda-developers.com/show...1#post26275391 are the first two reports.
UCLD3 ICS leak for the AT&T Samsung Galaxy S II (SGH-I777) - Other leaks may also be affected
Kernels built using the most recent SHW-M250S/K/L official source code release as of May 3, 2012 - This includes SiyahKernel 3.1rc6 for GT-I9100 (all other Siyah releases are safe)
Damage is not guaranteed - it may only affect a small percentage of users, but even a 5% chance is far more dangerous than the effectively 0% chance of hardbricking due to kernel bugs in safe kernels.
Also, some people will not fully hardbrick - /data or /system will become unwritable, resulting in a phone that can enter download mode, can flash kernels, can write to some partitions in recovery, but is overall unusable due to one or more critical partitions being unusable.
Kernels that have been confirmed safe:
All known Gingerbread kernels for the Galaxy Note and other affected devices listed above
Kernels built from the GT-I9100 Update4 source code release - this includes XplodWILD's CM9 release and my DAFUQ release, hopefully more kernel choices will become available soon
Kernels that have had MMC_CAP_ERASE disabled in mshci.c should be safe, look for it in the listed features of the kernel - preliminary results are good, no bricks have been reported by anyone confirmed to be actually running such a kernel yet.
If you are running an affected kernel:
STOP USING IT IMMEDIATELY. FLASH A SAFE KERNEL USING ODIN/HEIMDALL.
DO NOT wipe in recovery
DO NOT flash anything else in recovery
In general, DO NOT use recovery at all
Right now, what we know:
Some people can wipe with affected kernels as often as they want without problems. Just because you didn't brick, DO NOT advise other users that they will be OK.
Based on reports from the Epic 4G Touch community, some people can wipe/flash 20-30 times before hardbricking - Just because you didn't brick once, DO NOT continue flashing with an affected kernel
The source of the problem is somewhere within the changes between I9100 Update4 and SHW-M250S Update5 - https://github.com/Entropy512/kernel_galaxys2_ics/tree/m250s_dangerous
What we don't know:
Exactly which source commit above is responsible
How to determine if a future kernel or source release is safe without putting user's devices at risk - You only need to reproduce the problem once to be hosed.
Additional information
From this post
Elle233 said:
I know this tread is not about bricks, but your warning must have saved lots of souls from bricks and sorrow. Just wanting to ask, for those currently running ROMs with affected kernels, though, ROMs could be working, could any undetected/unobservable damage possible without one's knowing?
Click to expand...
Click to collapse
Entropy replies: Possible - With the Siyah 3.1rc6 fiasco, some people had situations where just one or two partitions became hosed up (usually /data)
It could be possible that some devices might only have a few damaged sectors in the eMMC - but I haven't seen confirmed reports of this yet. It has always been my suspicion that deleting large files on affected kernels could be dangerous - but I'm not sure about this.
Mod note: I copied this post here from its original thread as it contains pertinent information.
Chainfire said:
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
Additional information: I've seen at least one report of someone's device dying after a wipe in stock recovery, and one report of someone's device dying by doing a factory reset in Settings.
Which confirms everything you just said.
Latest from Android Team
Well, it's been some time but thankfully Mr. Sumrall from Android did get back to us on our questions. I think the community will find that this was worth the wait.
Issue: fwrev not set properly.
As we suspected the bugfix is not in our build. (The patch applies this unconditionally.)
Ken Sumrall said:
The patch includes a line in mmc.c setting fwrev to the rights bits from the cid register. Before this patch, the file /sys/class/block/mmcblk0/device/fwrev was not initialized from the CID for emmc devices rev 4 and greater, and thus showed zero.
(On second inquiry)
fwrev is zero until the patch is applied.
Click to expand...
Click to collapse
Question: Revision didn't match the fix
(Emphasis mine in red as it discusses the superbrick issue.)
Ken Sumrall said:
You probably have the bug, but rev 0x19 was a previous version of the firmware we had in our prototype devices, but we found it had another bug that if you issued an mmc erase command, it could screw up the data structures in the chip and lead to the device locking up until it was powered cycled. We discovered this when many of our developers were doing a fastboot erase userdata while we were developing ICS. So Samsung fixed the problem and moved to firmware revision 0x25. Yes, it is very annoying that 0x19 is decimal 25, and that led to lots of confusion when trying to diagnose emmc firmware issues. I finally learned to _ALWAYS_ refer to emmc version in hexadecimal, and precede the number with 0x just to be unambiguous.
However, even though 0x19 probably has the bug that can insert 32 Kbytes of zeros into the flash, you can't use this patch on devices with firmware revision 0x19. This patch does a very specific hack to two bytes of code in the revision 0x25 firmware, and the patch most likely will not work on 0x19, and will probably cause the chip to malfunction at best, and lose data at worst. There is a reason the selection criteria are so strict for applying this patch to the emmc firmware.
I passed on our results a few days later mentioning that the file system didn't corrupt until the wipe. This is a response to that follow-up.
As I mentioned in the previous post, firmware rev 0x19 has a bug where the emmc chip can lockup after an erase command is given. Not every time, but often enough. Usually, the device can reboot after this, but then lockup during the boot process. Very rarely, it can lockup even before fastboot is loaded. Your tester was unlucky. Since you can't even start fastboot, the device is probably bricked. :-( If he could run fastboot, then the device could probably be recovered with the firmware update code I have, assuming I can share it. I'll ask.
Click to expand...
Click to collapse
Question: Why the /data partition?
Ken Sumrall (Android SE) said:
Because /data is the place the chip that experiences the most write activity. /system is never written to (except during an system update) and /cache is rarely used (mostly to receiving OTAs).
Click to expand...
Click to collapse
Question: Why JTAG won't work?
Ken Sumrall said:
As I mention above, the revision 0x19 firmware had a bug that after an emmc erase command, it could leave the internal data structures of the emmc chip in a bad state that cause the chip to lock up when a particular sector was accessed. The only fix was to wipe the chip, and update the firmware. I have code to do that, but I don't know if I can share it. I'll ask.
Click to expand...
Click to collapse
Question: Can a corrupted file system be repaired (on the eMMC)?
Ken Sumrall said:
e2fsck can repair the filesystem, but often the 32 Kbytes were inserted at the start of a block group, which erased many inodes, and thus running e2fsck would often result in many files getting lost.
Click to expand...
Click to collapse
So, while the fix doesn't apply to us at the moment, we've been given a great insight into the superbrick issue as well as information that a fix is already developed (hopefully we'll see it released!). The bug likely applies to us and assuming the fix for the 0x19 firmware is given then it would apply to our devices.
On a lighter note, I wanted to include his close:
Ken Sumrall said:
You are getting a glimpse into the exciting life of an Android kernel developer. Turns out the job is mostly fighting with buggy hardware. At least, it seems that way sometimes.
Click to expand...
Click to collapse
garwynn said:
Well, it's been some time but thankfully Mr. Sumrall from Android did get back to us on our questions. I think the community will find that this was worth the wait.
Issue: fwrev not set properly.
As we suspected the bugfix is not in our build. (The patch applies this unconditionally.)
Question: Revision didn't match the fix
(Emphasis mine in red as it discusses the superbrick issue.)
Question: Why the /data partition?
Question: Why JTAG won't work?
Question: Can a corrupted file system be repaired (on the eMMC)?
So, while the fix doesn't apply to us at the moment, we've been given a great insight into the superbrick issue as well as information that a fix is already developed (hopefully we'll see it released!). The bug likely applies to us and assuming the fix for the 0x19 firmware is given then it would apply to our devices.
On a lighter note, I wanted to include his close:
Click to expand...
Click to collapse
BOOYA! (unfortunately, my quote of your post likely doesn't include Mr. Sumrall's comments)
So, in short - the AOSP patch in 4.0.4 is not relevant to our devices, HOWEVER:
There is a known issue that does affect our devices.
A bug with the ERASE command is EXACTLY what one would expect to cause this kind of behavior.
The remaining question is:
Gingerbread kernels have MMC_CAP_ERASE enabled for the MMC driver- why don't they cause problems, unless there's something somewhere else that prevents the ERASE function from being used even though the controller supports it?
This also explains why I9100 update4 is safe - one of the major differences between I9100 update4 and SHW-M250* sources is that MMC_CAP_ERASE is enabled in the SHW-M250* sources and not in I9100 update4.
This post on the portal is a very informative read. The take away quote for me:
Originally Posted by Ken Sumrall
You are getting a glimpse into the exciting life of an Android kernel developer. Turns out the job is mostly fighting with buggy hardware. At least, it seems that way sometimes.
Please stay clear from flashing anything ICS onto your devices until this has been solved.
Click to expand...
Click to collapse
Trying to find an OC-capable kernel for the N7000 and can't seem to find one that actually lets you overclock. Even the ones that claim overclock compatibility fail to work in SetCPU.
Also, I'm not really clear on how CWM works on Samsung devices. There is no recovery partition? It's built into the *kernel*? WTF kind of design is that? On any HTC device I've owned, you flash CWM into recovery and that's the end of it; it's accessible from HBOOT or any number of other methods, but on Samsung devices it depends on what kernel you have installed in the /system partition? Huh? Am I misunderstanding this?
TIA.
Bumping this, since I first asked this question in General and had my thread locked and edit-deleted and was rudely told to take my question here, where I had a strong suspicion it would not be answered.
Franco kernel allows overclocking and it is for samsung/touchwiz roms.
goku kernel.
Sent via carrier pigeon
The last time I tried Franco (a month ago?) SetCPU did not recognize that it could go past 1.4 GHz. Goku apparently breaks CWM. Did I do something wrong in flashing Franco? As far as I can tell I simply followed the directions. Is there some common pitfall when flashing a kernel on Samsung devices?
EDIT: Also, Goku does not support overclocking. http://forum.xda-developers.com/showthread.php?t=1710937
I know that there are other similar threads, but none seem to answer speciifically what I want to know.
I triewd to install a mod this morning on my new Galaxy note- the Ashish 4-bar blue battery circle in the Themes/Mods forum.
The Note arrived last week and I upgraded it to stock ICS using the Kies route.
This morning I couldn't get the mod to work, so I reread the instuctions on the thread. It suggested clearing the cache, so I booted into Recovery Mode and selected clear cache partition.
It is since doing this that I get stuck at the pulsing Samsung logo (post animation)
I understand (now!) after reading the threads on here that this may be the dreaded brickbug and necessitate sending the Note back to Samsung for a replacement.
My question is: what should I try before doing this? is there any way of telling whether it IS the brickbug?
Many thanks
If you did not touch the data wipe/factory reset your ok. Just flash again the stock ics through pc odin.
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
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....To locate the brickbug use this apk http://forum.xda-developers.com/attachment.php?attachmentid=1115293&d=1339163352 is a simple APK that reads out your chip's type and CID, and lets you know if we know that chip is dangerous or safe.Just uninstall again after using.
jonpaslim said:
If you did not touch the data wipe/factory reset your ok. Just flash again the stock ics through pc odin.
Click to expand...
Click to collapse
does this mean its safe to flash this german ROM,i own a galaxy note GT-N7000..my first sammy device. i have been waiting for what seems like an eternity for an official update here in SOUTH AFRICA. so i looked around the web for ways of updating safely and easily cause im a noob at this really. well, i found this http://www.theandroidsoul.com/xxlpy/
but then i also found a warning about flashing this ROM...
my question now is: how can i get ICS without rooting my phone and without bricking it? has the soultion been found to this eMMC bug?
and if i follow instructions on the link provided, will i be prompted to updated when sammy finally gets around to giving me an OTA?
how do i enjoy ICS without worrying about something being slowly corroded in my phone...
help
blacque said:
does this mean its safe to flash this german ROM,i own a galaxy note GT-N7000..my first sammy device. i have been waiting for what seems like an eternity for an official update here in SOUTH AFRICA. so i looked around the web for ways of updating safely and easily cause im a noob at this really. well, i found this http://www.theandroidsoul.com/xxlpy/
but then i also found a warning about flashing this ROM...
my question now is: how can i get ICS without rooting my phone and without bricking it? has the soultion been found to this eMMC bug?
and if i follow instructions on the link provided, will i be prompted to updated when sammy finally gets around to giving me an OTA?
how do i enjoy ICS without worrying about something being slowly corroded in my phone...
help
Click to expand...
Click to collapse
I answer you already on your own tread, look it up.
Once identified if in your kernel and present the bag or not ,performs updates with odin.
Just wanted to say that it flashed fine to gingerbread. Thanks a lot for all your help. Now running rooted rocket on ics, awesome
Sent from my GT-N7000 using Tapatalk 2
I updated to ICS around 3 weeks ago. So far, it's been very troublesome with deep sleep issues and just yesterday I also found out my kernel is likely infected with the infamous brick bug. Whilst I could downgrade to GB, I don't view this as an option as I always think it a good idea to have the latest version of Android available for my device due to support reasons.
So, what are some possible solutions to the brick bug? I understand this will likely require flashing, rooting or something along those lines, but what is the safest and most simple method for solving this?
The simplest way is to flash a SAFE kernel either in CWM or via ODIN
Check the dev section for kernels and see in the OP whether it is safe or not, For me, Abyss and Speedmod are safe.
There is no fix for the brick bug except getting your emmc chip replaced and as its embedded in the mobo they usually replace the whole mobo.
There is a work around to repartition effectively bypassing the damaged portion, but you will obviously lose a portion of storage, usually between 3 to 4gb.
Samsung are working on a kernel that will likely bypass the bug by not issuing the unsupported erase command but could be a while.
As azzledazzle says, of you're rooted and have cwm installed you can flash a safe kernel (listed in the sticky), but if you're gonna go that far its well worth checking out safe custom true ics roms such as paranoid android/cm9 and various others. The note works wonders in tablet mode which Samsung have kindly not enabled on their touchwizz ruined and buggy roms. You get a lot more bang foe your buck with true ics and tablet mode.
Read the sticky on the issue, its all explained there.
Sent from my Paranoid Android GT-N7000. It doesn't get much better than this!
SpyderTracks said:
There is no fix for the brick bug except getting your emmc chip replaced and as its embedded in the mobo they usually replace the whole mobo.
There is a work around to repartition effectively bypassing the damaged portion, but you will obviously lose a portion of storage, usually between 3 to 4gb.
Samsung are working on a kernel that will likely bypass the bug by not issuing the unsupported erase command but could be a while.
As azzledazzle says, of you're rooted and have cwm installed you can flash a safe kernel (listed in the sticky), but if you're gonna go that far its well worth checking out safe custom true ics roms such as paranoid android/cm9 and various others. The note works wonders in tablet mode which Samsung have kindly not enabled on their touchwizz ruined and buggy roms. You get a lot more bang foe your buck with true ics and tablet mode.
Read the sticky on the issue, its all explained there.
Sent from my Paranoid Android GT-N7000. It doesn't get much better than this!
Click to expand...
Click to collapse
Thanks, but I think I'll stick to the stock ROM and kernel as if it brick bugs it should logically be covered under warranty. Plus, I don't plan on hard resetting or flashing my phone, so logically not enough data should ever be deleted for this bug to cause me an issue.
Brad387 said:
Thanks, but I think I'll stick to the stock ROM and kernel as if it brick bugs it should logically be covered under warranty. Plus, I don't plan on hard resetting or flashing my phone, so logically not enough data should ever be deleted for this bug to cause me an issue.
Click to expand...
Click to collapse
So long as you don't hard reset you'll be fine. For future info, don't flash another ics rom from ics kernel, downgrade to a safe gb kernel before upgrading.
All the best.
Sent from my GT-N7000 using xda premium
I originally planned to switch to the Paranoid Android ROM, which would allow me to run tablet-oriented apps on my Galaxy Note, and whilst that would be absolutely fantastic the process seems beyond my technological abilities. Not only that, but I'd lose the S-Pen applications that I actually use quite a bit, so I decided in the end against switching ROMs. But, I still have a brick-bug infected kernel, so how difficult is changing kernels (not ROMs) and will I lose any data if change kernels? Also, are there any other benefits to changing Android kernels and will it still allow me to update my stock ROM via Kies or OTA like normal?
Switching kernels is easy. Is usually flash zip via CWM and that's it. If you want to make 100% that you got rid of all the remains of your old kernel you can flash jbroid script right before you flash (no reboot in between). Some kernels are only availale via Mobile Odin flash, but that's minority. Even then it's install Mobile Odin and flash kernel -> the end. Swithching kernels shouldn't affect anything unless it's some special kernel with unusual features. Just read the instrucitions carefully and make sure you flash TouchWiz kernels for stock and stock-based ROMs and AOSP/CM9 kernels for AOSP/CM9 based ROMs.
I would recommend trying Paranoidandroid anyways. The process is not much more complicated. Flash Abyssnote Kernel 4.2, reboot recovery (in Clockwork Recovery advanced options), wipe device (factory reset, format data, format dalvik cache), flash ROM and flash google apps. Reboot - done. You will lose S Pen partially but there are apps in the market working with S Pen and even recognizing button press (Papyrus Beta for instance). So the only thing that I've lost is double tap for instant note - I can live with that. Paranoidandroid features and performance make it up for me.
Good luck!
P.S. You will lose KIES and other Samsung apps if you flash PA. It's a CM9 based ROM, all the fancy stuff from Samsung is gone. Not that I miss it, since I've learned how to flash I never used all this crap anyways.
pjm77 said:
Switching kernels is easy. Is usually flash zip via CWM and that's it. If you want to make 100% that you got rid of all the remains of your old kernel you can flash jbroid script right before you flash (no reboot in between). Some kernels are only availale via Mobile Odin flash, but that's minority. Even then it's install Mobile Odin and flash kernel -> the end. Swithching kernels shouldn't affect anything unless it's some special kernel with unusual features. Just read the instrucitions carefully and make sure you flash TouchWiz kernels for stock and stock-based ROMs and AOSP/CM9 kernels for AOSP/CM9 based ROMs.
I would recommend trying Paranoidandroid anyways. The process is not much more complicated. Flash Abyssnote Kernel 4.2, reboot recovery (in Clockwork Recovery advanced options), wipe device (factory reset, format data, format dalvik cache), flash ROM and flash google apps. Reboot - done. You will lose S Pen partially but there are apps in the market working with S Pen and even recognizing button press (Papyrus Beta for instance). So the only thing that I've lost is double tap for instant note - I can live with that. Paranoidandroid features and performance make it up for me.
Good luck!
P.S. You will lose KIES and other Samsung apps if you flash PA. It's a CM9 based ROM, all the fancy stuff from Samsung is gone. Not that I miss it, since I've learned how to flash I never used all this crap anyways.
Click to expand...
Click to collapse
I can't wipe data though because of the brick bug and, as awesome as Paranoid Android is, I need the S-Pen apps (not so much Kies).
Brad387 said:
I can't wipe data though because of the brick bug and, as awesome as Paranoid Android is, I need the S-Pen apps (not so much Kies).
Click to expand...
Click to collapse
That is precisely why you flash Abyssnote Kernel just before flashing the ROM. It has no brickbug so wiping is safe. What other S Pen apps do you need apart from S Memo?
Anyways, you know best what you need so good luck
pjm77 said:
That is precisely why you flash Abyssnote Kernel just before flashing the ROM. It has no brickbug so wiping is safe. What other S Pen apps do you need apart from S Memo?
Anyways, you know best what you need so good luck
Click to expand...
Click to collapse
I use S-Memo to leave myself memos for homework tasks and other simple reminders. I enjoy cooking quite a bit, so when I find a recipe I like I compile it into S Note. S Planner I use frequently to set due dates for homework tasks, remind myself of friends' birthdays, and other important events. The S-Pen apps have ben a life saver when it comes to helping me organise my life.
I understand. In my own experience S Memo can be replaced by Papyrus, but my notes are rather simple so I don't know if it would work for you. I do use S Plannar A LOT (my work depends on it) and I don't see much difference if I'm using just plain stock calendar. Remember that S Pen still works on AOSP/CM9 ROMs like Paranoidandroid, just some things like gestures combined with button (which in all honesty I don't use at all) that don't work.
Warning. Flash paranoid while running on gb. If you flash it while in ics it will hardbrick your device.
If i flash the kernel , i need to flash the modem too ?
karlodav said:
If i flash the kernel , i need to flash the modem too ?
Click to expand...
Click to collapse
If you flash a kernel you dont need a modem to go with it. You can flash modem separately it depends what will the best that works in your country. Flash ics kernel for ics rom and to gingerbread also the same.