Unfortunately the kernel src code for the ICS build of our device contains the MMC_CAP_ERASE problem (as I have found it from the src code), I highly recommend everyone stop using the ICS leaked build right now since it has the potential problem to hard brick your device. You can continue to use the device / ICS after the kernel is rebuilt.
To revert back to GB, please do the following things :
1. Boot into download mode / CWM (actually CWM is pretty safe to use if it is using 2.x kernel, and if you don't reboot into the system after wiping /data or done a factory reset, read below)
2. Install any GB kernel (or even the whole package)
3. After installing GB kernel, you are safe to install any files in CWM
btw, if someone has bricked device and have recorded the emmc chip ID as well as the firmware version, please report here. It is important for us to get emmc brickbug test / GotBrickBug to support our device, so that we can blacklist those firmware version.
Until the ICS kernel src is successfully rebuilt, I recommend everyone stop using ICS or just turning off your device.
If you want to continue using ICS, please stop deleting any files from the system. Thank you.
For devs : http://forum.xda-developers.com/show....php?t=1847859 (The line to be removed from the kernel src code in order to suppress MMC_CAP_ERASE bug)
Update 1 : The reason of hard bricking in CWM
For the reason of hard bricking in CWM, there are 2 common possible reasons.
1. After you have wiped the /data partition in CWM, the android system will spawned a lot of files in /data which may trigger the MMC_CAP_ERASE problem if you have rebooted the phone in normal mode (which is using the malfunctioning 3.x kernel). This is because files may get erased (and then the firmware borked the whole partition) after the reset process.
2. The CWM is using a 3.x kernel which has MMC_CAP_ERASE enabled. But for now, all the CWM release for I9103 are based on 2.x kernel only. This is because the recovery partition has got a different kernel when compared to the normal one (which is stored in boot.img).
Those things are confirmed with one of the CWM devs, utkanos (so credit goes to him as well). And I am going to copy and paste the IRC log just to clarify things up (this is not meant to cause any privacy issue, just to clarify things up).
<utkanos> not the standard boot <UnknownzD> weird then <UnknownzD> then how those guys say that the EMMC_CAP_ERASE hard brick is related to CWN> <UnknownzD> CWM?* <utkanos> its not <UnknownzD> ah k then <utkanos> its after you flash the 'bad' kernel <utkanos> and boot once <utkanos> it derps the emmc <utkanos> permanently <UnknownzD> ah I totally get what you mean now <utkanos> ok <UnknownzD> people uses factory reset / delete data files <UnknownzD> data files respawned after rebooting in normal situtation <utkanos> yep <UnknownzD> = the system hardbricked <UnknownzD> btw utkanos, do you mind if I copy / paste the above lines to clarify the things in forum? <UnknownzD> I want people to know that CWM is no unsafe @ all <UnknownzD> not* <utkanos> well <utkanos> its a combination of things <utkanos> but yes its the kernel bug that is the problem <utkanos> if the recovery binary attempts to erase before formatting <utkanos> it triggers the bug <utkanos> and ICS/JB based recovery code does this <utkanos> http://forum.xda-developers.com/showpost.php?p=27074278&postcount=69 <utkanos> link them to this thread^ <utkanos> instead of my words <utkanos> :P <utkanos> read those top 3 conditions <utkanos> the real issue is that the emmc doesnt support the command properly <UnknownzD> yea I know that, but it does not tells that part that <UnknownzD> people can revert to GB <UnknownzD> using CWM <utkanos> recovery attempts to erase emmc <utkanos> kernel can block it if the code for it is missing <utkanos> but if code is in the kernel <utkanos> and recovery requests an erase <utkanos> and the emmc doesnt know how to handle said command <utkanos> = bug <UnknownzD> but as far as I know, all the current CWM release are based on 2.x kernel <UnknownzD> for I9103 <utkanos> gotcha <UnknownzD> so I guess it is safe? <utkanos> then its unlikely the recovery binary will try an erase <utkanos> but I can't say for certain at all <utkanos> the best way to secure yourself is to make sure the kernel thats in the recovery does NOT have that erase code