Database Users

[Guide]How to revive your bricked Gnote

I was on Offical leaked Taiwan version of ICS, then i decided to move to XXLPY version of ICS. I went to CMW to full wipe data, but for some reason, my note froze during data wiping...
I have waited long enough, but it was froze. With no choice, I removed the battery then tried to boot, but it was stuck on the first screen.
From then on, I have tried to recover my note using various Offical ROMs, the taiwan leak, German leak and even old GB ROMs, but I am stuck at Factoryfs...
I am pretty sure Ive tried everything, add PIT and not add PIT, Kernel, etc...
For some reason, Kernel can be flashed just fine, but when it comes to ROMs, it stucks at this screen.
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
Please, any help is appreciated
--------------------------------------------------------------------------
That was my situation 3 days ago, but i managed to get it back to life from this post by Forest1971:
http://forum.xda-developers.com/showpost.php?p=26285877&postcount=12
Thank you Forest1971 for this great guide

And the bricks resumes......
Send it back to samsung service center. Hope you have warranty.
Zapped through server hops to XDA forums

WTF!!!! who told you to wipe on LPF??? who told you not to read the PSA??

One more. We could actually make a movie about it now. :/
My commiserations man. Take it to Samsung.
Sent from my GT-N7000 using XDA

But I can't help saying that you are actually very brave. You could read about how to flash all this (assuming you did it yourself) but couldn't read about the possible risks. Every forum these days is about "bricked due to wipe" or "avoid wiping to avoid brick". I am not trying to give you a lecture or something and I really hope Samsung fixes it for free but please, next time search before you do anything potentially dangerous.
Sent from my GT-N7000 using XDA

musashiro said:
WTF!!!! who told you to wipe on LPF??? who told you not to read the PSA??
Click to expand...
Click to collapse
... ****
this one tole me to wipe so I did it ............ FML
Guess ill have to visit samsung store then
Glad I got the warrenty

sujal said:
But I can't help saying that you are actually very brave. You could read about how to flash all this (assuming you did it yourself) but couldn't read about the possible risks. Every forum these days is about "bricked due to wipe" or "avoid wiping to avoid brick". I am not trying to give you a lecture or something and I really hope Samsung fixes it for free but please, next time search before you do anything potentially dangerous.
Sent from my GT-N7000 using XDA
Click to expand...
Click to collapse
Thanks anyway, I am just glad that I still got the warrenty

uggies said:
Thanks anyway, I am just glad that I still got the warrenty
Click to expand...
Click to collapse
keep us updated!
Sent from my GT-N7000 using XDA

uggies said:
... ****
this one tole me to wipe so I did it ............ FML
Guess ill have to visit samsung store then
Glad I got the warrenty
View attachment 1069893
Click to expand...
Click to collapse
Albany didn't say you should full wipe in LPF. Read in between the lines of and sorry for the brick
Sent from my GT-N7000 using xda premium

So there is no way to recover once you wipe data?

currently the best way is to get it replaced by samsung

Guide for repartition workaround to fix super-brick Note
uggies said:
I was on Offical leaked Taiwan version of ICS, then i decided to move to XXLPY version of ICS. I went to CMW to full wipe data, but for some reason, my note froze during wiping data...
I have waited long enough, but it was stuck. With no choice, I removed the battery then tried to boot, but it was stuck on the first screen.
From then on, I have tried to recover my note using various Offical ROMs, the taiwan leak, German leak and even old GB ROM, but I am stuck at Factoryfs...
I am pretty sure Ive tried everything, put PIT and not put PIT, Kernel, etc...
For some reason, Kernel can be installed just fine, but when it comes to ROMs, it stucks at this screen.
View attachment 1069879
Please, any help is appreciated
Click to expand...
Click to collapse
There has been confirmation that In many cases it is the faulty system partitions (caused by wipe using the buggy ICS stock kernel or other reasons). In that case re-partition workaround will help revive your brick phone. The first one who has applied the method successfully is "Drnull" for another similar device (epic4g).
So for those who would like to use this solution follow the guide below which I developed based on the hints from Drnull and a re-partition guide for Kindle Fire by Eldarerathis and Soundwire.
Credits and thanks to them.
Big thanks to: Prabhu1980, Matiasg85, Uggies, Bodivas, As i9000, Alekhkhanna, Travis82 and others who have provided precious tools, troubleshoot solutions, advice and support for making this guide more complete and easy to use! Also Special thanks to Lyriquidperfection for his great PIT Magic and Hg42 for his custom PIT method!
------------------
I. Case Classification and solution when there is no recovery mode:
1. Case A. If you can enter recovery: then use scanning tool to find where the damage is. Should use hg42 scanners or use the procedures described in the manual method below (Go until steps 4 to find the answers). The scanning can guide you to find the most suitable strategy for re-partition. After scanning you can use the most suitable custom pit files from the set of custom pit files in hg42's thread or use the method in this guide or a combination of both in an intuitive way to revive your brick Note. .
2. Case B. If you only have download mod, no recovery: if you flash using odin and it gets stuck at factoryfs or datafs repeatedly and you have made wipe/factory reset using ICS stock kernel, then you certainly have emmc brick. You can try to flash some kernel attached in this guide to see if can enter recovery. IF yes, then go back to Case A. If not you can use a blind method using the custom pit files below. Try one by one. The one from 2.0 should work for you. If not then from 2.1 to 2.5, one of those should work.
2.0. Custom pit that works for most cases of emmc brick
2.1. Custom pit option 1
2.2. Custom pit option 2
2.3. Custom pit option 3
2.4. Custom pit option 4
2.5. Custom pit option 5
-----------------------------------
II. Manual re-partition
Notes for using Manual repartition:
1. For those who can get SS warranty service to fix it for free then you should go there, and do not need to try repartition.
2. know how to run command prompt (MS-DOS) from window.
3. Partitions can be delete and recreate like in a computer hdd and it is reversible: you can do and redo again and again and can also go back to original scheme by flashing original PIT file.
4. If you like to recover data from your internal sdcard (photos, music, books...) you should look at Item 9 near the end of the guide.
5. And do not try to hold me responsible if you mess things up further than your current state in your phone.
1. The tools:
- Download the screen shot of the Note’s partitions for your reference information
- Install USB driver: You should be able to have adb driver for Note. If not, then download Note usb driver from here.
- Prepare adb folder: download adb folder from Here and extract adb folder to c: driver of your computer, you will have the tools folder which has adb.exe in it. You should now have adb working for your Note.
- Install custom recovery so that you can get into recovery and connect adb.
+ if you have installed GB rom (as part of the unbrick process) then download and install the attached 4pda_kernel.tar from Here.
It will raise flash counter but you can reset later using Triangleaway by Chainfire.
+ If you were ICS rom: then download and flash Speemod kernel for ICS Here., using odin.
+ If you were on JB rom then download and flash Speedmod kernel for JB from Here.
2. Set up the tools:
- after flashing one of the suitable kernel from above you should now be able to enter recovery.
- Then restart the phone to recovery (Using three buttons).
- Then connect to computer using usb cable.
3. Then run cmd from your computer and cd (change directory) to the folder that has adb.exe in your computer.
Then run,
Code:
adb devices
it should give you some number then it means your device is connect in adb
then:
Code:
adb shell
it should give you the sign like this: ~ #
-------
Note: In case adb shell it only gives this sign $ (after you have installed the 4pda_kernel) then it showed there is a mismatch of that kernel with the rom that is sitting on your (semi-brick) Note and it does not give full root. In that case you should download and install this CM9 based safe kernel from this links which should help you to get full adb root access with this sign ~ #. It is a zip file and need to be install from CWM (not odin) by copy it to external sdcard or internal sdcard (by mount usb storage to PC or adb push.
-------
Then run (noted that umount is without N):
Code:
~ # umount /cache
~ # umount /system
~ # umount /data
If one of those "umount /" commands return "invalid argument" just ignore it and continue with next steps.
This is to unmount cache, systemfs and datafs partitions.
Note: it is easier to copy and paste (right click mouse) the code to CMD windown to save time and avoid typing error.
Then run the parted.
Code:
~ # parted /dev/block/mmcblk0
if it aska you to fix something just choose yes. It should give you bellow:
parted /dev/block/mmcblk0
GNU Parted 1.8.8.1.179-aef3
Using /dev/block/mmcblk0
Welcome to GNU Parted! Type 'help' to view a list of commands.
(parted)
Then run:
Code:
(parted) print
It will give you a picture of your Note’s partitions as in the screen shots I have attached. (text version is below):
print
print
Model: MMC VYL00M (sd/mmc)
Disk /dev/block/mmcblk0: 15.8GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Number Start End Size File system Name Flags
1 4194kB 25.2MB 21.0MB ext4 EFS
2 25.2MB 26.5MB 1311kB SBL1
3 27.3MB 28.6MB 1311kB SBL2
4 29.4MB 37.7MB 8389kB PARAM
5 37.7MB 46.1MB 8389kB KERNEL
6 46.1MB 54.5MB 8389kB RECOVERY
7 54.5MB 264MB 210MB ext4 CACHE
8 264MB 281MB 16.8MB MODEM
9 281MB 1174MB 893MB ext4 FACTORYFS
10 1174MB 3322MB 2147MB ext4 DATAFS
11 3322MB 15.2GB 11.9GB fat32 UMS
12 15.2GB 15.8GB 537MB ext4 HIDDEN
--------------------
4. Scanning for Partition errors:
4.1. Use DD:
Do to a thorough scan of partitions (block damage) you can use DD command below one by one (it only read partition block by block and no write, so it is totally safe).
Damage is mostly found in partition 7, 9, 10, 11. You can use dd to check other partition from 1 to 6 as well.
Code:
(parted) quit
~ # dd if=/dev/block/mmcblk0p7 of=/dev/null
~ # dd if=/dev/block/mmcblk0p9 of=/dev/null
~ # dd if=/dev/block/mmcblk0p10 of=/dev/null
~ # dd if=/dev/block/mmcblk0p11 of=/dev/null
Scan partition 7 and 9 will be quick (less than a minute) partition 10 take about 3 minutes and 11 about 5-7 minutes.
- If it return in and outs and partition size then they are fine (no faulty blocks)
- If it freezes (or run too long more than 10 minutes), or return something like "read/write I/O error" then it means you have some damage in that respective partition and read command failed. In this case should restart CMD/adb and run the test again for the partition that give I/O error to make sure the error is permanent and result of test is reliable.
4.2. There is also anther scan tool to double check if there are partitions faults: that is e2fsck. It comes with 4_pda and CM9 kernel given. The added benefit is that it can also repair minor memory block damage.
This tool can only be used for ext4 partition (7, 9,10) and it need to be used after "umount /cache"... steps in point 3. It is suggested that before attempting with re-partition you should first try to use this tool to scan and fix the damaged block. The command is below:
Code:
~ # e2fsck -f -c –y /dev/block/mmcblk0p7
~ # e2fsck -f -c –y /dev/block/mmcblk0p9
~ # e2fsck -f -c –y /dev/block/mmcblk0p10
The results of e2fsck scanning can be as below:
- If there is no faulty block e2fsck will report: "no bad block found". then good!
- If it freezes then it has encountered emmc bug damaged and cannot fix: In this case will definitely need re-partition.
- If it report encountered some damaged block and has fixed the damage: In this case you can try to go back to install rom. If it work, that is great. If still get stuck as before then you will need to do re-partition.
Guide for the most suitable re-partition scheme after scanning partitions (read carefully for the best result):
1. In case you do not find bad blocks in the above 4 partitions, the problem is certainly not related to partitions fault. Then you should explore other unbrick methods, using Heimdall to flash instead of odin for example.
2. In case there are fault in both partition 9 and 10 then follow steps in point from 5.1 to 5.3 below. applying this scheme of re-partition should work in most cases!.
3. In case there are faulty in partition 9 only, then can follow steps in point 7 to save some more space.
4. In case there are faulty in partition 10 only, then can follow steps in point 7 to save some more space.
5. In case there are faulty blocks in Cache partition, then follow point 5.4
6. In case there are faulty in partition 11: go to point 8 .
---------------------
5. Re-partition workaround for case of faulty in partitions 9 and 10::
5.1 remove partitions to get rid of the faulty ones and make space available for new ones:
Code:
~ # parted /dev/block/mmcblk0
(parted) print
(parted) rm 9
(parted) rm 10
(parted) rm 11
That will remove three partitions factoryfs (9), datafs (10) and UMS (11) so as to make rooms for new partitions
5.2. To create three new partitions from the good area:
Code:
(parted) mkpart primary 3322.881536 4216.268288
(parted) mkpart primary 4217 6364
(parted) mkpartfs primary fat32 6364 15200
(parted) name 9 FACTORYFS
(parted) name 10 DATAFS
(parted) name 11 UMS
Notes: You can also use custom pit provided in 2.0 to re-partition in this case.
-------------
5.3. Convert format for 9 and 10: The above steps have created three new partitions. However, for 9 and 10 the format is ext2 and now need to be converted to ext4.
The easiest way is to go back to CWM in your phone. Then, go into mounts and storage menu and choose format /system and format /data. It will convert file system of partition 9 and 10 to ext4 automatically for you.
If the above steps are successful then check:
Code:
~ # parted /dev/block/mmcblk0
(parted) print
Note: after printed partition and they look fine, then should check again the partition using dd command to scan partitions 9, 10, 11 as in the step 4 to make sure that newly created partition are fault-free. If they continue to report faulty block then you will need to do re-partition again and create new partitions in the new range (by changing start and end number of partitions).
------------
Dealing with Cache partition:
5.4. It is very, very unlikely that Cache is also faulty but in case there is you can follow steps below to deal with it.
First should remove and recreate with same size and location:
Code:
(parted) rm 7
Then recreate it:
Code:
(parted) mkpartfs primary ext2 54.5 264
(parted) name 7 CACHE
Then you can go into CWM and format /cache, it will convert file system to ext4.
In case parted give I/O error then you can try to reduce the size of cache to 128MB, choose the start and end number somewhere in the space from 54.5MB to 264MB.
6. Suggestions for rom installations:
It is recommend to use a custom GB rom (Darky GB, CheckRom GB, and Rocket GB...)they are old but very good roms. Dowload links and instructions for installation can be found in this link. Custom ICS roms (such as Rocket ICS, CleaNote ICS...) are also good. They can be found from the same link for GB rom provided or from the Note development sections. Using CM9 ICS such as Nightlies is recommended since it is safe and very lightweight (less than 140 MB) so it is quick to download.
Note: Flash custom rom by CWM (load rom.zip from computer to internal or external sdcard and flash) seem to be a better way than using odin and is recommended but you can try both.
7. Guide for some cases of only one partition have faulty blocks:
7.1. In case you scan partition and identify that there are damage only in partition 9 (factoryfs) then you can remove 9, 10, and 11 and then start making partition from 1174 MB:
Code:
(parted) rm 9
(parted) rm 10
(parted) rm 11
(parted) mkpart primary 1174.405120 2067.791872
(parted) mkpart primary 2068 4215
(parted) mkpartfs primary fat32 4215 15200
(parted) name 9 FACTORYFS
(parted) name 10 DATAFS
(parted) name 11 UMS
Then go into CWM to format system and data. Then you can install rom.
7.2. In case you identify that there is faulty blocks in partition 10 only (datafs) then you can remove 10 and 11 only (leave 9 alone) and start making partition 10 from 3322 mb:
Code:
(parted) rm 10
(parted) rm 11
(parted) mkpart primary 3322 5469
(parted) mkpartfs primary fat32 5469 15200
(parted) name 10 DATAFS
(parted) name 11 UMS
Then go into CWM and format data. and you can install rom.
It is also known that the hidden partition (partition 12) is not needed for normal use and install of roms. So you can delete it and enlarge the UMS partition (to 15800mb) and you will have a larger sdcard to use.
It is also noted that the size of datafs partition does not need to be exact 2147 mb so you can create it with the size of 2000 mb or smaller or bigger as you wish.
Still the size of factoryfs partition has to be correct so that odin will accept it when flash.
8. In the case of damage in partition 11 (UMS) this often also go with damage in partition 9 and 10. In this case I have worked out 5 options of partition scheme. You need to try from one to 5. One of those should work for you.
You can also use one of the custom Pit files provided at 2.1 to 2.5 above.
Option 1:
Code:
~ # parted /dev/block/mmcblk0
(parted) print
(parted) rm 9
(parted) rm 10
(parted) rm 11
(parted) mkpart primary 4608 5501.386752
(parted) mkpart primary 5501.386752 7648.8704
(parted) mkpartfs primary fat32 7648.8704 15200
(parted) name 9 FACTORYFS
(parted) name 10 DATAFS
(parted) name 11 UMS
After done, reboot into recovery format system, format data. Then you can proceed with install stock or custom rom.
If it get errors when create partition or CWM get stuck during format then you need to try the next option of partition scheme as below.
Option 2:
Code:
(parted) mkpart primary 6400 7293.386752
(parted) mkpart primary 7293.386752 9440.8704
(parted) mkpartfs primary fat32 9440.8704 15200
Option 3:
Code:
(parted) mkpart primary 7936 8829.386752
(parted) mkpart primary 8829.386752 10976.8704
(parted) mkpartfs primary fat32 10976.8704 15200
Option 4:
Code:
(parted) mkpart primary 9216 10109.386752
(parted) mkpart primary 10109.386752 12256.8704
(parted) mkpartfs primary fat32 12256.8704 15200
Option 5:
Code:
(parted) mkpart primary 11,008 11901.386752
(parted) mkpart primary 11901.386752 14048.8704
(parted) mkpartfs primary fat32 14048.8704 15200
9. Notes on recovering files from brick phone: For recovering data from internal sdcard, there are few ways below:
- You can try to install aroma file manager under CWM recovery using file from here. It works under recovery environment and allow you to copy files from internal sdcard to external sdcard.
- If that does not work, you can follow the guide until step 4, then in step 5 remove only partition 9 and 10 and leave partition 11 alone. Then try to create a full size partition 9 (factoryfs) with about 800MB and a very small size (100mb) partition 10 (datafs) and fit these two partitions within the remaining good area in the range from 281mb to 3322mb. Then you can install a custom rom and get it working to copy files to your PC. After that you can remove partition 11 to make full size partition 9 and 10 with steps as in the guide.
- Also you can adb shell, then list directory and files in internal sdcard (~ # ls /sdcard ...etc) and then adb pull files from internal sdcard to your PC one by one.
If you like to know more about using parted, go to the documentation page here:
http://www.gnu.org/software/parted/manual/html_mono/parted.html
Update of progress: As rough figures, more than 100 users have reported successfully revised their Notes after fixing partitions problems using either manual/adb methods or custom PIT file method from Hg42 or combined both. Re-partition have revised many super-bricks Notes! .
If you can revive your Note please share your success with us so that we can share your good feeling !
And press thanks if you find this guide useful. Thanks.

forest1971 said:
There has been confirmation that relocating the corrupted partition to the good areas works. Read the posts by "drnull" from post 331 in the thread under epic4g group.
http://forum.xda-developers.com/show...504808&page=34
So for those who would like to use this solution follow the guide below which I developed based on the guide for another android device by eldarerathis and soundwire.
http://forum.xda-developers.com/showthread.php?t=1388996
All credits go to them
1. The tools:
- Download the screen shot of the Note’s partitions for your reference information
- Download the zip file attached (it has parted partition manager and other format conversion tool), extract it and copy all files) to adb folder
2. Get into recovery (CMW)
3. connect to computer using usb cable.
4. Then run cmd and cd to the adb folder of your computer
Then run following commands.
adb devices
it should give you some number then it means your device is connect in adb
then run:
.
.
.
.
For documentation of parted go here:
http://www.gnu.org/software/parted/manual/html_mono/parted.html
Let me know if you have difficulties doing the procedures.
And press thanks if it helps.
Click to expand...
Click to collapse
Thank you very much for your help, but is there anyway to install CWM on a bricked device?

You need to flash a custome gb kernel that has cwm via odin

forest1971 said:
You need to flash a custome gb kernel that has cwm via odin
Click to expand...
Click to collapse
Alrighty Thanks mate. Will have a go tomorrow and report back
Sent from my HTC Incredible S using XDA

Abyssnote kernel seems to be a good one and it has cwm included. Good luck!
and please remember to post also screen shots of the results. Thanks

uggies said:
I was on Offical leaked Taiwan version of ICS, then i decided to move to XXLPY version of ICS. I went to CMW to full wipe data, but for some reason, my note froze during wiping data...
I have waited long enough, but it was stuck. With no choice, I removed the battery then tried to boot, but it was stuck on the first screen.
From then on, I have tried to recover my note using various Offical ROMs, the taiwan leak, German leak and even old GB ROM, but I am stuck at Factoryfs...
I am pretty sure Ive tried everything, put PIT and not put PIT, Kernel, etc...
For some reason, Kernel can be installed just fine, but when it comes to ROMs, it stucks at this screen.
View attachment 1069879
Please, any help is appreciated
Click to expand...
Click to collapse
wait if you can still flash a kernel then flash a GB cf root kernel then boot into CWM recovery and try to flash a nandroid restore (you have one right) ? if you don't have one then just flash any safe ROM (GB ,CM9) from CWM.
I had the same problem when LPY first hit the scene (first day ,even before it was deemed dangerous) ,and also bricked my note but could enter download and recovery just fine (only couldn't boot or flash anything else) I kept rebooting and trying to flash again again till it worked after some dozen reboots .
hopefully you can do the same.

And what do if you can't get into recovery, or CWM?
Just first boot screen stuck, or Download mode, but factoryfs stuck also?

Shadow69 said:
And what do if you can't get into recovery, or CWM?
Just first boot screen stuck, or Download mode, but factoryfs stuck also?
Click to expand...
Click to collapse
Yeah I am stuck at the first screen too..
When I unzipped AbyssNote kernel 4.2 Final CW Touch Custom Logo, it was zlmage, not .tar file extension. Tried putting .tar at the end, still no luck.
I also tried CF-ROOT 5.3V, it was successfully flashed but again I was stuck at the first screen with yellow triangle at the bottom.
Am I trying out wrong kernels?
EDIT: I managed to find .tar file of Abyss kernel and flashing was successful, still cannot get into recovery ... seems pretty hopeless now

Shadow69 said:
And what do if you can't get into recovery, or CWM?
Just first boot screen stuck, or Download mode, but factoryfs stuck also?
Click to expand...
Click to collapse
Go to the nearest service center.

PIT file method to revive your phone from a MMC_CAP_ERASE brick

Summary: in many cases this allows to revive (not really repair!) your N7000 (and some other samsung devices) after an emmc brick and should be relatively easy to follow. The method uses PIT files.
Note: This thread is rather old now (2012).
Please note that the emmc brick bug should be triggered only by a combination of a few conditions:
an old samsung ics kernel (from Ice Cream Sandwich versions 4.0–4.0.4, see wikipedia)
wiping or formatting by custom software, usually an old cwm of that time (especially an often used file called CWM.ZIP)
most important: an older emmc chip (or firmware).
All affected devices should be covered by the thread, some got patched PIT files, some could not be supported (see below).
Some insights here (as part of this thread)
after the problem had been analyzed by the community and Samsung, all those parts got fixed to prevent the problem for the future.
In case only one of the conditions is not true, the brick should not happen.
So if you have more current hardware (somewhat newer than note1) or current software (newer than ics), the bug will not happen.
So, as an example, S3 or Note 3 should be safe because both hardware and software are fixed.
Especially, all current roms or recoveries should be safe.
If you have a brick nowadays, it's very very unlikely it's an emmc brick. Instead you probably have some other problem.
So in most cases, don't look here, unless you are using rather old devices and rather old software.
Note: this is a living post, it will change while progressing. If you want to refer to it, please make a reference to the whole thread (this link).
Don't directly link to the attached files, as they will go away, when I update the files or their names from time to time.
Note: You should generally post in the correct thread (please look in my signature)
Note: I will answer PMs which are of general interest relating to one of my topics (please look in my signature) publicly in the thread (quoting your interesting paragraphs).
It's sad the following has to be said in such big letters, but there are still people not reading anything and therefore failing seriously:
Please, please, please:
Read this multiple times and try to understand all aspects before using anything of this thread.
If you have questions, read it again!
If you have questions, read it again!
...
If you have questions, read it again!
If you have questions, read it again!
If you don't know exactly what you are doing, you may HARM your device seriously or even DAMAGE it for all times (e.g. meaning motherboard has to be changed with >150EUR).
If you are a noob, then please ask someone with more knowledge to assist you, but ignore those blowhards/bigmouths which will probably do more harm to your phone than you would.
If you have questions, read first post again and again and also read the whole thread!
Most questions are asked several in this thread and are already answered in this first post. Others are answered later in the thread. You should also use the search function before asking something a second time.
Please don't waste my time with superfluous questions already answered in the thread only because you are too lazy to search for it!
It took much much time to write this down and describe most aspects. So, please take a similar amount of YOUR time to read it carefully.
Certainly, my descriptions will not be perfect, so if you are SURE your question is NOT answered HERE, then you are welcome to ask in the thread. But don't expect a quick answer. I am usually very busy with other things and I am doing this only to help other people. I definitely don't generate any profit from this...
Please don't quote this post (in it's entirety), because it's very long and will disturbe all other readers. Instead post without a quote or extract some of the text you are referring to. I think this should be common sense...
You can find the former first post of this thread at post #9...I switched it with this continuously updated post, which I hope is more understandable for the users of this method.
-------------------- manual method and tools for using adb
I think forest1971's thread is better for the description of and questions about the manual method which I used first to revive my own phone. Looks like we developed the same thing at the same time. I started this thread before I read his (I also wasn't an active user of xda before).
Along the way our threads started to be companions to each other.
forest1971's thread has some useful tools for using in adb. Some of these will be useful for procedures described here.
But please read on, because I think the PIT file method is easier for most users with kind of standard emmc bricks.
It's less error prone, because you don't have to calculate the numbers yourself (my pit generator script did it already).
However, the manual method can do more, especially if you have special cases.
-------------------- find begin and end of bricked area
You can do this with my emmc partition scanner, which is flashed via recovery (this doesn't really flash, it only uses the scripting of the updater mechanism of the recovery, also called edify script).
You should write down two numbers:
* where emmc_find_brick_start.zip freezes -> BRICK_START
* where emmc_find_brick_end.zip freezes -> BRICK_END
I have reports, that the stock recovery doesn't show the output of the scanners, so you should probably install a custom recovery first (see forrest1971 's thread).
-------------------- patched pit files
I finally hacked a perl script, which generates a set of PIT files for me.
But because I cannot test the PITs on my phone (because I need it):
==> NO GUARANTY <==
Say you have a situation like this:
Code:
before: ...-|-FAC?OR??S-|??ATAFS-|-UMS------------------------------------|...
^ ^
| |
BRICK_START BRICK_END
(? = bad blocks)
The repartitioning should leave a hole in the partition table around the bricked area.
Therefore the bricked area will lie fallow (i.e. not accessed) after the repartitioning.
Code:
before: ...-|-FAC?OR??S-|??ATAFS-|-UMS------------------------------------|...
after: ...-| ? ?? ??|-FACTORYFS-|-DATAFS-|-UMS---------------------|...
\ /
------+-----
|
HOLE
(? = bad blocks)
The calculation is done like the following (Example: N7000_16GB) with X being the size of the HOLE:
Code:
16GB original (Q1_20110914_16GB.pit)
FACTORYFS 548864 ->Fo 1744896 ->Fs
DATAFS 2293760 ->Do 4194304 ->Ds
UMS 6488064 ->Uo 23232512 ->Us
HIDDEN 29720576 ->Ho 1048576 ->Hs
16GB MMC_CAP_ERASE patched
FACTORYFS FoX = Fo+X unchanged
DATAFS DoX = Do+X unchanged
UMS UoX = Uo+X UsX = Us-X
HIDDEN unchanged unchanged
The PITs are named like that:
N7000_16GB_Q1_20110914--patched--brick-between-281-and-2428-MB--FACTORYFS-moved-by-2048-MiB
This PIT is for the N7000 with 16GB and derived from the file Q1_20110914.pit.
Here, the HOLE is from 281 MB up to 2428 MB (MB = 1000000 bytes) which is 2147 MB or 2048 MiB (MiB = 1024*1024 bytes) in size.
So the following relations have to match: BRICK_START >= 281 MB and BRICK_END <= 2428 MB
Note that these numbers are rounded, so if your brick lies exactly on this border, it is possible that your aprtitions are not brick free after the repartitioning.
So to be sure this would be safer: BRICK_START > 281 MB and BRICK_END < 2428 MB
In the example all partitions from FACTORYFS up to the "big" partition (here UMS) have their beginning moved by 2048 MiB.
The "big" partition is shrinked by the same amount, so it ends at the same block as before the repartitioning.
Therefore the following partitions (only HIDDEN in this case) remain unchanged.
All partitions before the first moved partition (FACTORYFS) remain also unchanged.
I recently added more starting partitions for the brick (XXX-moved-by-...).
As a rule, all partitions from this starting partition up to the "big" partition are moved by the size of the HOLE.
All partitions in front of the starting partition and all partitions after the "big" partitions remain unchanged.
Code:
case FACTORYFS-moved-by-...
before: ...-|-FAC?OR??S-|??ATAFS-|-UMS------------------------------------|...
after: ...-| ? ?? ??|-FACTORYFS-|-DATAFS-|-UMS---------------------|...
\ /
------+-----
|
HOLE
case DATAFS-moved-by-...
before: ...-|-FACTORYFS-|D??T?FS-|-UMS------------------------------------|...
after: ...-|-FACTORYFS-| ?? ?|-DATAFS-|-UMS------------------------------|...
\ /
-+-
|
HOLE
(? = bad blocks)
The PIT file will repartition the phone automatically when flashed using Odin, but the moved partitions will not be formatted after that.
If you flash a partition in Odin, you will also put a valid file system on this partition(because the partition image also contains the file system).
For all other partitions, you have to format those partitions, before you can use them.
At least the data partition should be formatted
The revived phone does in nearly no user noticeable way differ from a stock phone afterwards.
You just have a smaller internal sd (called "big" partition above) and you cannot flash a stock pit file again (this would revert the phone to the bricked state).
ATTENTION: different recoveries and ROMs mount external and internal sdcard on varying directories.
I also had the following problem:
I couldn't format my internal sdcard with the cm9 recovery. I think it's too big for the mkfs.vfat tool of current cm9. So I installed another recovery, formatted the internal sd (I thought).
This erased all my current backups and downloads, because in reality it was my external sd. Fortunately I had a backup of the external sdcard from before rescuing my phone.
So, you may want to create a backup of your external sdcard first.
Then double check which is your internal sdcard (the UMS partition) and which is your external sdcard.
Or you could remove the external sd completely. But think about when to remove it, because you might need it for some files (e.g. to use the emmc partition scanner).
-------------------- backup
before messing with the partition table, everyone should make backups of all partitions that can be accessed.
-------------------- efs backup
The most important backup is the efs partition, which very crucial, it includes your IMEI number, bluetooth MAC etc., and without this individual information, your phone cannot be used as a phone again.
For most supported phones, you can do this via adb:
Code:
dd if=/dev/block/mmcblk0p1 of=/mnt/sdcard/efs.img
please look at forrest1971's thread for details about using adb.
If your phone uses another partition number for efs, then use this instead of the "1" in mmcblk0p1.
Perhaps you have to mount your sdcard first, to be able to save it there.
Then you should copy the backup to your PC (the recovery should have the option to mount usb).
-------------------- backup files from internal sd before repartitioning
the repartitioning will clear all data in the affected partitions, so all data in your big partition (internal sd etc.) will be lost.
You can try to backup your data, if the partition is accessible. The different methods below may have different success, depending which parts of your phone are usable.
* you can use aroma file manager, which is a full fledged gui file manager which starts standalone by being flashed in CWM. So it should be completely independent (sorry, I could not test it for this kind of backup myself).
For the following possibilities you should first ensure, you have a working recovery with working adb support.
Mount your external sd in recovery (which might be /emmc or /sdcard, please check), to be able to copy files.
* you can use QtAdb to copy files to your PC:
* you can use adb pull to copy any files or directory tree to your PC, e.g.:
adb pull /emmc/. emmc
* you can use tar from adb to archive files to a file on sdcard:
adb shell tar cvjf /sdcard/emmc.tar.bz2 /emmc/.
* you can use a copy command in adb shell to copy files to a folder in sdcard:
adb shell cp -ra /emmc/. /sdcard/emmc.backup
Note: you will loose file attributes and owner information if emmc is formatted with ext2/ext3/ext4, because vfat cannot handle these.
This may matter for system and some app related files.
-------------------- recommended procedures for "standard" cases
"standard" in this sense are pits that only affect FACTORYFS, DATA, CACHE or internal SD (UMS/USERDATA etc.).
All other partitions need special considerations and are not handled in this section!
Note these are from theory only. My phone is running now and I don't want to brick it again, only for testing the procedure.
Therefore the procedure is *NOT* tested (by me) and may contain problems which I didn't expect!
So be "careful with that axe, Eugene!"
Note, there are always multiple ways to reinstall the phone.
phase "find brick"
* reboot into recovery (hold Vol-Up + Home + Power until you arrive there [20-30 seconds])
* flash emmc_find_brick_start.zip, note where it freezes -> BRICK_START
* flash emmc_find_brick_end.zip, note where it freezes -> BRICK_END
phase "flash pit and ROM"
* (re)boot to download mode (hold Vol-Down + Home + Power until you arrive there [20-30 seconds], then Vol-Up)
* flash a patched PIT in Odin
* flash a known good ROM via Odin (especially not a faulty stock ICS ROMs)
phase "check partitions"
* reboot into recovery (hold Vol-Up + Home + Power until you arrive there [20-30 seconds])
* check the partitions (see section "checking all partitions" below)
phase "restore partitions"
* switch off the phone (something like "power off" in recovery)
* remove external sdcard (to be sure not to format it afterwards)
* boot recovery (hold Vol-Up + Home + Power until you arrive there [20-30 seconds])
* format cache
* format data
* format internal SD (if it fails read below)
phase "start ROM"
...
After formatting or wiping data you can probably also boot into the ROM and format the internal sd from there (again: keep the external sd removed, to not format the external sd instead of the internal sd unintentionally).
You should be able to flash any stock ROM from samfirmware (click on n7000 under "models"), I would recommend the one you had before the brick and and before any stock ICS, else you risk a brick again!.
I would recommend a cyanogen ROM though, if you can live with some features missing from stock ROM.
Note: I think the standard recovery doesn't give you enough format options (a guess, I am running cm9).
It may be easier to take a custom ROM with a better custom recovery, but it has to be flashable via Odin (tar file).
A second method is via recovery using a custom kernel:
phase "find brick" like above
phase "flash pit and kernel"
* (re)boot to download mode (hold Vol-Down + Home + Power until you arrive there [20-30 seconds], then Vol-Up)
* flash a patched PIT in Odin
* flash a custom kernel with a good recovery (e.g. cm9 safe kernel) via Odin (which will increment the flash counter! -> yellow triangle -> warranty lost until you reset the counter)
phase "check partitions" like above
phase "restore partitions"
* switch off the phone (something like "power off" in recovery)
* remove external sdcard (to be sure not to format it afterwards)
* boot into recovery (hold Vol-Up + Home + Power until you arrive there [20-30 seconds])
* format system
* format cache
* format data
* format internal SD
phase "install ROM"
* install the zip of the ROM
phase "start ROM"
...
So you generally install the ROM like usual, the only difference is to restore all the partitions moved by the repartitioning with the patched PIT.
This is neccessary because all changed/moved partitions don't have a valid file system or content after the repartitioning.
For some partitions this can be done by a simple format (cache, data, internal sd).
Others need true contents (e.g. system, kernel, recovery can be restored by installing a rom/kernel/recovery).
In other cases (non-standard situations) you need to restore a backup (efs, if you have one) or some generic contents (param, sbl1/2).
EFS is the most critical one, because it contains information unique to your own phone. Also see the efs section in this post.
I assume SBL1/2 are needed by the boot process (secondary boot loader), but I never tested this. I don't even know where to get these boot loaders (which probably have to be installed with the PIT via odin, because they are involved in the boot process).
You may find other important information in the thread, please read it completely before asking the same things over and over again.
There may also be useful information and experiences from users.
I try to incorporate useful information in the thread starter, but my time is often very limited.
Also, some information may not look valuable enough for me to integrate it, but it may be valuable for you.
...suggestions or corrections welcome!...
-------------------- checking all partitions for bricked blocks
After repartitioning some partitions may still have bricked blocks inside (because of moving brick or choosing a wrong pit etc.).
Bricked blocks in any partition will lead to random freezes when these blocks are accessed in any way.
So you should check all your partitions after repartitioning to be sure.
With both methods below, you can check the partitions even before formatting any of them.
You can do this with my emmc partition scanner, which is flashed via recovery (this doesn't really flash, it only uses the scripting of the updater mechanism of the recovery, also called edify script).
You can also do it manual via dd commands in adb, but this is much slower.
Use commands like this, using the partition block device in the if=... argument:
adb shell dd if=/dev/block/mmcblk0p1 of=/dev/null
adb shell dd if=/dev/block/mmcblk0p2 of=/dev/null
adb shell dd if=/dev/block/mmcblk0p3 of=/dev/null
...
adb shell dd if=/dev/block/mmcblk0p9 of=/dev/null
adb shell dd if=/dev/block/mmcblk0p10 of=/dev/null
adb shell dd if=/dev/block/mmcblk0p11 of=/dev/null
etc.
If any of these freeze the phone (or reboots the phone or doesn't come to an end even after an hour), you probably (still) have bricked blocks inside the according partition.
-------------------- pit.str for DataWorkshop
For those who want to edit their own patched pit file, I made a structure definition file (pit.str) for an open source multi-platform tool (java) called DataWorkshop, which allows looking at binary data in structured form.
The tool is not very comfortable when it comes to copy/paste etc. but you can edit the values (just put the cursor at the correct digit before typing the number).
Please ask (PM), if you are interested in this.
-------------------- PITs for other devices
Because Samsung doesn't fix their kernels (thinking their software doesn't have the problem) there is a growing number of affected devices.
Look at the attached files, which devices are currently available.
If pits for your device aren't available yet, please send me a stock PIT and tell me which partitions are bricked (or BRICK_START and BRICK_END, and if you know, which partitions are usually bricked for your device).
I'll look what I can do...
I will add comments for special cases below.
-------------------- device i9250 - experimental PITs
I added i9250 PITs which are very experimental, because I don't know how some details of it's stock PIT affect the result. May be it breaks everything, so beware.
I added this especially for Shanava, who said to be able to recover even from a hard brick.
His brick is in userdata.
So this will probably revive the internal sd (is it userdata?) and reinstalling a ROM shouldn't be necessary, only formatting userdata.
But I also added system and cache as possible starting partition for the brick, then you have to install a ROM and format cache accordingly.
-------------------- devices not supported/supportable
i9000, i9300 (and similar):
These devices have a different PIT structure.
The structure for each partition entry doesn't include an offset, so I don't know a way to define a gap for skipping the bricked blocks.
Inserting an unused partition changes the partition numbers after it, which shouldn't work.
-------------------- FOR-EXPERTS-ONLY packages
DO NOT USE one of the packages with "FOR-EXPERTS-ONLY" in it's name unless you are REALLY REALLY sure how to handle/restore/initialize all the affected partitions, often meaning you were involved in the discussion leading to these files or you read this VERY carefully.
These packages contain files to be used by those who have special problems and want to take the risk to try them.
They are only documented by the corresponding discussion (somewhere in this thread).
note: this is a living post, it changes while progressing. If you want to refer to it, please make a reference to the whole thread, beginning at the first post.
Don't directly link to the attached files, as they will go away, when I update the files and their names from time to time.

Let's hear it....

ok I wait. ..

Forgive me for being skeptical but, Join date Feb 2011, and this is only your second and very open ended post?...... Hmmmm :S

RavenY2K3 said:
Forgive me for being skeptical but, Join date Feb 2011, and this is only your second and very open ended post?...... Hmmmm :S
Click to expand...
Click to collapse
That's why I said "Let's hear it....". Like, I am very curious because I noticed the same thing you did. I hate doubting people, but sometimes you have to.

hg42 said:
go straight ahead to the final solution (see next post)...
Click to expand...
Click to collapse
andreww88 said:
Let's hear it....
Click to expand...
Click to collapse
errr

I very much doubt it. But lets hear your version of "The curious case of Benjamin eMMC bug"

panyan said:
errr
Click to expand...
Click to collapse
Why did you quote me?

Repartitioning around the bad blocks
This is the former first post of this thread...I switched it with a continuously updated version, which is more understandable for ths users of my pit method.
-----------------------snip -------------------------------------
Hi everyone, especially those with an ICS brick,
last week I jumped straight into a MMC_CAP_ERASE brick.
Sadly, I knew very well what not to do with a LPY kernel on my phone (wiping etc.).
But one weak moment (touching "wipe data/factory reset" in CWM), and then a moment later a flash (pun!) going through my brain, telling me "wow, now the phone will be bricked, right?".
Well I rebooted the phone and thought to be a lucky man, because the system booted correctly.
But after about a minute the SGN started to get FCs in android.*.acore and Google Play etc. I looked with a root file manager and found that the /data partition wasn't mounted.
So I got the BRICK!
After some days of analysing and thinking about the situation, I found a way out of the dilemma. I think, I will not bother you with all the details of these days, but go straight ahead to the final solution...
(this was planned as the second post in the thread, but the dynamic community inserted many post in between, so I added it here sorry, my fault)
---- cut ----
This is a rewrite in english of my report at a german forum:
ICS Brick, Samsung Galaxy Note N7000, Erfahrungsbericht
www.handy-faq.de/.../249283-ics_brick_samsung_galaxy_note_n7000_erfahrungsbericht.html
My brick created bad blocks in the phone's flash memory.
I got I/O-Errors when attempting to read or write those blocks.
My SGN was still able to boot into recovery and all kinds of kernels/recovery.
Odin was able to flash boot loaders, kernels, modems and CSCs.
But flashing a factory_fs stopped at the very beginning.
I found, that any access to some blocks inside /system and also ANY access to /data left an inaccessible phone and I had to restart it.
For all of the following I needed access to some tools (mainly e2fsck and parted).
As I had completely deleted my system partition before (formatting it), I had no single useful tool around, so the recovery had to provide any of those.
The stock recovery e.g. of KL8 engineering kernel doesn't provide such tools, so I had to find a better one first.
I found all this packed in the Thor kernel, but would not recommend it, because it's closed source.
You may use the tools from forrest1971, see below under "manual method".
One of my attempts to get around those bad blocks, was to create a bad blocks list which can be used by the ext4 file system, I tried this command:
e2fsck -c /dev/block/mmcblk0p9 (which is the /system partition)
Click to expand...
Click to collapse
This failed, because to find out which blocks are bad, e2fsck tries to read them and gets stuck by doing so.
I could have created a list manually, but because the data partition was corrupted starting at it's first block, this bad blocks list wouldn't work here anyway.
At the end, my solution was to recreate the partition scheme, leaving a big hole at the space where /system (893MB) and /data (2147MB) resided before:
Code:
before: - ...-|-FAC?ORYFS-|??ATAFS-|-UMS------------------------------------|...
after: + ...-| ? ?? |-FACTORYFS-|-DATAFS-|-UMS---------------|...
(? = bad blocks, + working, - = not working still bad blocks inside)
In order to not access those bad blocks, I could not move these partitions, but instead I had to delete them first and recreate them at another place afterwards.
So I needed a backup of them first (fortunately I always have 7 Titanium backup levels around).
Here is a log of my steps (but see below in the blue sections for other probably easier procedures):
Code:
I managed to access the device via [I]adb shell[/I]...which is another story for itself...
Then I started [I]parted[/I] with the flash device:
~ # parted /dev/block/mmcblk0
parted /dev/block/mmcblk0
GNU Parted 1.8.8.1.179-aef3
Using /dev/block/mmcblk0
Welcome to GNU Parted! Type 'help' to view a list of commands.
(parted) print
print
print
As a greeting I got some error messages about the GPT layout, which parted wanted to fix:
[QUOTE]Error: The backup GPT table is not at the end of the disk, as it should be.
This might mean that another operating system believes the disk is smaller.
Fix, by moving the backup to the end (and removing the old backup)?
Fix/Ignore/Cancel? f
f
f
Warning: Not all of the space available to /dev/block/mmcblk0 appears to be
used, you can fix the GPT to use all of the space (an extra 2048 blocks) or
continue with the current setting?
Fix/Ignore? f
f
f
this was the partition scheme before implementing the workaround:
Model: MMC VYL00M (sd/mmc)
Disk /dev/block/mmcblk0: 15.8GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Number Start End Size File system Name Flags
1 4194kB 25.2MB 21.0MB ext4 EFS
2 25.2MB 26.5MB 1311kB SBL1
3 27.3MB 28.6MB 1311kB SBL2
4 29.4MB 37.7MB 8389kB PARAM
5 37.7MB 46.1MB 8389kB KERNEL
6 46.1MB 54.5MB 8389kB RECOVERY
7 54.5MB 264MB 210MB ext4 CACHE
8 264MB 281MB 16.8MB MODEM
9 281MB 1174MB 893MB FACTORYFS
10 1174MB 3322MB 2147MB ext4 DATAFS
11 3322MB 15.2GB 11.9GB fat32 UMS
12 15.2GB 15.8GB 537MB ext4 HIDDEN
then I deleted the partitions 9=FACTORYFS=/system, 10=DATAFS=/data and 11=UMS=/sdcard(internal) and recreated them starting at the former start of the internal sdcard partition (11) leaving the former space of the /system and /data partitions unused:
(parted) rm 11
(parted) rm 10
(parted) rm 9
(parted) mkpartfs primary ext2 3500 4400
(parted) mkpartfs primary ext2 4400 7000
(parted) mkpartfs primary fat32 7000 15.2G
(parted) name 9 FACTORYFS
(parted) name 10 DATAFS
(parted) name 11 UMS
now I upgraded both new ext2 partitions to ext4:
~ # tune2fs -j /dev/block/mmcblk0p9
tune2fs -j /dev/block/mmcblk0p9
tune2fs 1.41.11 (14-Mar-2010)
Creating journal inode: done
This filesystem will be automatically checked every 30 mounts or
0 days, whichever comes first. Use tune2fs -c or -i to override.
~ # tune2fs -j /dev/block/mmcblk0p10
tune2fs -j /dev/block/mmcblk0p10
tune2fs 1.41.11 (14-Mar-2010)
Creating journal inode: done
This filesystem will be automatically checked every 30 mounts or
0 days, whichever comes first. Use tune2fs -c or -i to override.
~ # e2fsck -fDp /dev/block/mmcblk0p9
e2fsck -fDp /dev/block/mmcblk0p9
/dev/block/mmcblk0p9: 11/439776 files (0.0% non-contiguous), 71701/878907 blocks
~ # e2fsck -fDp /dev/block/mmcblk0p10
e2fsck -fDp /dev/block/mmcblk0p10
/dev/block/mmcblk0p10: 11/317440 files (9.1% non-contiguous), 26386/634765 blocks
and this is the final partition layout:
~ # parted /dev/block/mmcblk0 print
parted /dev/block/mmcblk0 print
Model: MMC VYL00M (sd/mmc)
Disk /dev/block/mmcblk0: 15.8GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Number Start End Size File system Name Flags
1 4194kB 25.2MB 21.0MB ext4 EFS
2 25.2MB 26.5MB 1311kB SBL1
3 27.3MB 28.6MB 1311kB SBL2
4 29.4MB 37.7MB 8389kB PARAM
5 37.7MB 46.1MB 8389kB KERNEL
6 46.1MB 54.5MB 8389kB RECOVERY
7 54.5MB 264MB 210MB ext4 CACHE
8 264MB 281MB 16.8MB MODEM
9 3500MB 4400MB 900MB ext3 FACTORYFS
10 4400MB 7000MB 2600MB ext3 DATAFS
11 7000MB 15.2GB 8217MB fat32 UMS msftres
12 15.2GB 15.8GB 537MB ext4 HIDDEN
This configuration works so far (one complete day now).
I can install firmwares and restore backups via recoveries.
Also flashing via Odin should work (not tried yet).
I currently can only imagine one standard procedure which will not work, that is creating a new partition scheme, e.g. via Odin (PIT file) or may be a CWM script.
I think/hope this will not occur too often...

-- naturally, it's much faster to insert those short messages than rewriting a long german post in english.
Next time I should write the main text prior to posting anything, I think...
sorry...

WoooooooOOOOOOoooooooowwwww!!!!
YeeeeeeEEEEEEaaaaaAAAAAaaaahhhhhh!!!!!!
You are the man, bro.

man has a few posts but are worth a lot. .. thanks for share with us

And... I just wonder it couldn't be possible to recreate the whole partition table with an appropiate tool like GNU/Linux "parted" or so?
Is the damage so serious? Is it physical??

Interesting Read, this should be of a great help to those bricked without warranty.

straycat said:
And... I just wonder it couldn't be possible to recreate the whole partition table with an appropiate tool like GNU/Linux "parted" or so?
Click to expand...
Click to collapse
you *can* indeed try to recreate the standard partition scheme (I did it very early with a PIT file in Odin and also tried formatting those partions etc.), but this doesn't work because *accessing* those blocks in any way is the *real* problem.
Is the damage so serious? Is it physical??
Click to expand...
Click to collapse
yes, you can't even fix the bad blocks with the usual JTAG equipment.
I was told by a technician from a good repair center that a fix could eventually be possible by directly reprogramming the flash chip in some way (JTAG again), but no one tried yet, because this would cause several hours of work...
usually they swap the whole motherboard instead (which is >250EUR)

Thanks, hg42.
I really apreciate your efforts and to share with us.
I'm not a superbriked note owner but I follow with great interest those posts.
Again, thank you, man.

Wow man, that seemed really simple and straight forward. Next week well learn how to copy a file in Android, now that will be much trickier...
Thanks anyway for your efforts!
Sent from my GT-N7000 using Tapatalk 2

Zamboney said:
Wow man, that seemed really simple and straight forward. Next week well learn how to copy a file in Android, now that will be much trickier...
Click to expand...
Click to collapse
LOL, you're right, at the end I also thought, that's really simple
but, at least...I had several problems to solve before getting adb up and running properly with root permissions and having the necessary tools at hand (inside adb).
I think this was mainly because I wiped my /system before.
But, it's easy to be wise after the event.

hmm, I tried to export this partition scheme to a PIT file (using heimdall-frontend), but I got a file that is exactly equal to the one I flashed last via Odin, which was Q1_20110914_16GB.pit.
So I assume the PIT file is one way only?
A PIT file would probably allow even unexperienced users to unbrick their phones.

This is the same method here:
http://forum.xda-developers.com/showpost.php?p=26285877&postcount=12
Although your post I found easier to read.

[Q][HELP]My TAB is BRICKED AFTER FLASH quicksilver 0.8

Firstly have to thank you the rom developer, the ROM is very smooth, I like it so much.
But I am facing a serious problem now, while I flashing the 0.8 version, updating half way, the tab is auto reboot, and now it was stop at "Samsung GALAXY Tab 7.7". It is too bad.
I post here is trying to get help, below is the step that I do before boot looping:
1) Update my tab 7.7 from HC to ICS (Australia firmware with Odin) It run smooth.
2) Download CWM.zip, download QuickSilver 0.5, 0.6, 0.7
3) Boot my tab into recovery mode, too bad I failed to install via the android recovery, so I install CMW to install the QuickSilver, from 0.5 to 0.6, to 0.7
4) I install the ROM without wipe anything, and hooray, it running SMOOTH
5) Today, I check on the same post, and found that there are new version for the ROM, 0.8 & 0.9
6) But this time, 0.8 need a wipe data and wipe cache. So i just follow the instruction.
7) I boot into CWM recovery, and wipe data, wipe cache and wipe Davch.
8) Then I start flashing 0.8, but in the half way, it auto reboot, and now boot looping in "Samsung Galaxy Tab 7.7"

Solution that have been tried:
1) Flash with PIT + MALAYSIA OFFICIAL Firmware (Odin)
2) Flash Malaysia Official Firmware (Odin)
3) Flash PIT + ICS Australia firmware (Odin)
4) Flash ICS Australia firmware (Odin)
All doesn't work, it auto reboot after installation then just boot looping

But after flashing ICS, I able to access into recovery mode, I try to wide data and factory reset.
But it failed, it stop at:
-- Wiping data...
Formatting /data...
Then it will auto reboot, and boot looping in "Samsung GALAXY Tab 7.7"

when you boot into recovery, is Adb working, can you Adb to your device?
check below thread and see if you have the same issue and try the solution provided to fix corrupted data partition. Let us know how it goes and using which OS HC or ICS.
http://forum.xda-developers.com/showthread.php?t=1625675&highlight=bootscreen

zorbakun said:
when you boot into recovery, is Adb working, can you Adb to your device?
check below thread and see if you have the same issue and try the solution provided to fix corrupted data partition. Let us know how it goes and using which OS HC or ICS.
http://forum.xda-developers.com/showthread.php?t=1625675&highlight=bootscreen
Click to expand...
Click to collapse
I can use ADB, I am trying the command that shown in the thread, but no hope:
e2fsck -c /dev/block/mmcblk0p10 (3G)
it show an error message:
/dev/block/mmcblk0p9: Updating bad block inode.
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
/dev/block/mmcblk0p9: ***** FILE SYSTEM WAS MODIFIED *****
/dev/block/mmcblk0p9: 1596/53312 files (0.0% non-contiguous), 189332/212992 bloc
ks
~ #
~ # e2fsck -c /dev/block/mmcblk0p10
e2fsck -c /dev/block/mmcblk0p10
e2fsck 1.41.6 (30-May-2009)
e2fsck: Superblock invalid, trying backup blocks...
e2fsck: Bad magic number in super-block while trying to open /dev/block/mmcblk0p
10
The superblock could not be read or does not describe a correct ext2
filesystem. If the device is valid and it really contains an ext2
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
e2fsck -b 8193 <device>
~ #

I'm not sure what you should do next! did your TAB test positive for the SuperBrick Bug?! May be Entropy512 can help you...Good Luck.

Flash stock rom with odin
Sent from my GT-S5660 using xda premium

Try to get to Download Mode (Not Recovery) > Use ODIN on PC > Flash the PIT > Reboot > Flash the stock ICS > Flash the ROM
I've got the Download Mode bootloop first time I've tried the Quicksilver or Zeta, I solved it the way described above. Hope this helps.

BAD_BOY_KIEV said:
Try to get to Download Mode (Not Recovery) > Use ODIN on PC > Flash the PIT > Reboot > Flash the stock ICS > Flash the ROM
I've got the Download Mode bootloop first time I've tried the Quicksilver or Zeta, I solved it the way described above. Hope this helps.
Click to expand...
Click to collapse
Thanks for everyone help, last night I am trying on flash a PIT (which I found from XDA P6800_ATO_PIT), and then boot into recovery, and use adb shell, e2fsck -c /dev/block/mmcblk0p10
That have been 8 hours, it still keep running on:
.......................................................................
Error reading block 131299 (Attempt to read block from filesystem resulted in sh
ort read) while getting next inode from scan. Ignore error? yes
Force rewrite? yes
Error reading block 131300 (Attempt to read block from filesystem resulted in sh
ort read) while getting next inode from scan. Ignore error? yes
Force rewrite? yes
Error reading block 131301 (Attempt to read block from filesystem resulted in sh
ort read) while getting next inode from scan. Ignore error? yes
Force rewrite? yes
Is that mean it try to recover? Or just checking the memory? Shall I terminate it?

BAD_BOY_KIEV said:
Try to get to Download Mode (Not Recovery) > Use ODIN on PC > Flash the PIT > Reboot > Flash the stock ICS > Flash the ROM
I've got the Download Mode bootloop first time I've tried the Quicksilver or Zeta, I solved it the way described above. Hope this helps.
Click to expand...
Click to collapse
I think I didn't try this, but what I have try is:
Download Mode (Not Recovery) > Use ODIN on PC > Flash the PIT > Reboot > Flash the stock ICS (odin) > reboot
But it still boot looping.
May I know, do you do a wiping after flash ICS and before flash the other ROM?
You flash the rom with Odin? Or CWM?

this is the reason i always try my best to stay away from noob custom roms for me stock ICS is working great i wonder why people are so curious to try buggy roms right now these two custom roms zeta and quciksilver gives nothing advantage over the stock ics

irmani said:
this is the reason i always try my best to stay away from noob custom roms for me stock ICS is working great i wonder why people are so curious to try buggy roms right now these two custom roms zeta and quciksilver gives nothing advantage over the stock ics
Click to expand...
Click to collapse
Because we don't have alot ofnpro devs working on this tab, a few people who obviously know what they're doing are filling in some of the gaps (not gapps)---and they need testers. I applaud everybodys efforts, and its nice to see activity in this forum IMHO. ;-P
Sent from my GT-P6800 using XDA Premium HD app

Same problem!
How we fix the /data/ partition?

update progress:
able to fix /data by
- install parted over recovery mode
follow below step
you must edit start , end position of blk10
parted /dev/block/mmcblk0
Parted 1.8.8.1.179
print
Model: MMC VYL00M (sd/mmc)
Disk /dev/block/mmcblk0: 15.8GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Number Start End Size File system Name Flags
1 4194kB 25.2MB 21.0MB ext4 EFS
2 25.2MB 26.5MB 1311kB SBL1
3 27.3MB 28.6MB 1311kB SBL2
4 29.4MB 37.7MB 8389kB PARAM
5 37.7MB 46.1MB 8389kB KERNEL
6 46.1MB 54.5MB 8389kB RECOVERY
7 54.5MB 264MB 210MB ext4 CACHE
8 264MB 281MB 16.8MB MODEM
9 281MB 1153MB 872MB ext4 FACTORYFS
10 1153MB 15.3GB 14.1GB ext4 DATAFS
11 15.3GB 15.7GB 470MB ext4 HIDDEN
12 15.7GB 15.8GB 8389kB FOTA
rm 10
(parted) mkpartfs primary ext2 4215 6362(parted) name 10 DATAFS
~ # tune2fs -j /dev/block/mmcblk0p10~ # e2fsck -fDp /dev/block/mmcblk0p10
~ # tune2fs -O extents,uninit_bg,dir_index /dev/block/mmcblk0p10
~ # e2fsck -fDp /dev/block/mmcblk0p10
Click to expand...
Click to collapse

zoftdev said:
parted /dev/block/mmcblk0
...
print
...
rm 10
(parted) mkpartfs primary ext2 4215 6362
(parted) name 10 DATAFS
~ # tune2fs -j /dev/block/mmcblk0p10
~ # e2fsck -fDp /dev/block/mmcblk0p10
~ # tune2fs -O extents,uninit_bg,dir_index /dev/block/mmcblk0p10
~ # e2fsck -fDp /dev/block/mmcblk0p10
Click to expand...
Click to collapse
Thank you zoftdev 1.000.000 times !
after a whole week (day & night) I finally solved the problem with your "fix"
Problem: (7.7 6800 Tab, HC Hong Kong stock)
1. HC Hong Kong stock
2. no wipe
3. install ICS Austria stock
4. no wipe !
5. install Zeta 2 via Odin (not Quicksilver, kinda offtopic here...)
all ok, with old HC data, apps settings
and hence there mistakes begins:
6. install ICS Austria stock again, for a new Zeta CLEAN install
8. wipe data/cache/dalvik, from SD running, not installed CWM 5.5.4.0 (that was the REAL mistake, the wipe)
9. install Zeta 2
10. endless boot loop...
for all week tried everything I knew and all I found on this forum
install Pit, install stock HC, reinstall ICS Austria stock, Pit again, HC Romania, Hong Kong, Vodafone,
wipe data/cache/dalvik again and again, install ICS Austria stock again...
hours and hours, again and again... revers order again,
all non working fixes,
madness...
and finally find your post... install SDK Android
very noob on Android, (I'm an old symbian fan,
did not know much about Android, at I learned a lot about this OS in this week)
Thank you again zoftdev !!!

zoftdev said:
update progress:
able to fix /data by
- install parted over recovery mode
follow below step
you must edit start , end position of blk10
Click to expand...
Click to collapse
Hy,
All goes ok and acording to your instructions until i reac the command
"mkpartfs primary ext2 4215 6362" where unfortunatly after 10-15 minutes it gives me this message:
Error: input/output error during write on /dev/block/mmcblk0
Retry/Ignore/Cancel?
I keep giving it ignore an after the second ignore it says:
writing per-group metadata...x% (time left XXXX:xx)
I am now at 4% after 2 hours....and every 30 second i must hit "ignore" to the error that i mentioned here.
Any ideeas?

[GUIDE][Noob-Friendly][adb] How to avoid Superbrick // How to revive your bricked Tab

HOW TO AVOID BRICKING YOUR TAB
The best advice I can give to people who haven't bricked their tab (already?^^) : DO NOT EVER WIPE ANYTHING WHILE RUNNING STOCK 7.7 ROMS
Here is what to do in order to flash a custom rom safely when coming from stock :
- Flash the latest cwm with ODIN
- Do NOT wipe anything
- Flash the custom rom of your choice
- Reboot recovery
- Wipe what you need to wipe
- Re-flash the custom rom
- flash the gapps or whatever
- Reboot, done.
Ok guys, I'm seeing more and more people bricking their 7.7 and, being one of the unlucky owners of a bricked p6810, I understand how stressful and annoying it can be.
I've been reviving my tab like a hundred times using this technique, as you'll most likely have to re-do that whole process everytime you wanna flash something.
There are two ways of reviving from superbrick I know of :
- The first is to flash a PIT file with ODIN that will repartition your tab for you.
I will not cover this method as hg42 already wrote a very detailed tutorial about this. This tutorial is about Galaxy Note but you can appIy it to our 7.7 and you'll find PITs for P6800 there. I will soon make pits for P6810 using the scripts provided in hg42's guide.
- The second way is to repartition your tab manually through adb. This is the method I'll try to teach you here.
Let's first be very clear :
- This won't get your tab back in its former state
- Your internal storage will shrink by a lot
- All your data will be lost
- No guarantee it works for you
- You'll most likely have to do that every time you flash
- Your tab might rebrick itself after some days, so you'll have to do this again, get used to it.
- If you can get Samsung to repair your tab then go ahead
- I'm not responsible for any further damage made to your tab
- You need a computer for this tutorial
Ok, you read the above carefully ? You are ok with it ? then let's begin !
Using the Android Debugging Bridge (adb) to revive your tab
Setting up your environment
Prior to anything, you need to download and install the android sdk, I won't cover the installation here, it's explained on developer.android.com and there are plenty of guides on how to get adb and the sdk on xda.
Make sure you install the platform-tools in the sdk manager.
Ok now I assume you got the sdk installed, so let's move on to the serious things.
1) How to open an adb shell ?
First, you're going to need the latest ClockWorkMod Recovery (a.k.a CWM), download and instructions on locerra's thread here
Then boot your tab in recovery (Maintain power+volume up buttons) and plug it into your computer via usb.
Then do the following :
a- On Windows
Navigate to the directory where you installed the sdk, and open the folder called "platform-tools" (e.g : go to C:\android-sdk\platform-tools if your sdk is installed in C:\android-sdk)
Press shift and do a right clic on an empty space in the folder, then select "open a command prompt here" (or something like that).
b- On Linux
Open a terminal window (ctrl+T)
Let's assume you put the sdk in a folder called "android-sdk", located at the root of your home folder (~/android-sdk).
Then you have to enter this in the terminal :
Code:
cd ~/android-sdk/platform-tools
So now, all the rest of the commands you'll have to enter are the same on windows and linux, as the adb shell will actually be running in your tablet.
2) Meet a new friend, he's called parted.
First, we are going to use parted to take a look at our partitions and their file systems, and eventually replace the corrupt partitions with clean, freshly created ones.
Then, you'll meet your other very good friend with a barbarian name : e2fsck (e2 stands for ext2, and fsck for file system check. Not that barbarian finally is it ?). He will check your filesystems and fix the possible errors they got.
Ok now we've made the presentations, let's go !
First make sure you read the following :
In the code boxes of this tutorial, there are symbols at each line start, DO NOT COPY IT with the rest of the command ! :
-the "$" represents your bash shell or command prompt
-the "#" represents the adb shell
-the"(parted)" represents the (parted) shell
-Each end of line means "press Enter".
-The partitions numbers are not the same on p6810 and p6800 (please report to this reference), so there will be two code boxes in the examples, one for p6810 and one for p6800, it's indicated in bold red but make sure you don't mix it up, that could screw your tab even more.
Ok here we go !
Issue the following in your terminal/command prompt :
Code:
$ adb shell
# parted /dev/block/mmcblk0
(parted) print
The output should look like this :
>>> P6810 <<<
Code:
Number Start End Size File system Name Flags
1 4194kB 25.2MB 21.0MB ext4 EFS
2 25.2MB 26.5MB 1311kB SBL1
3 27.3MB 28.6MB 1311kB SBL2
4 29.4MB 37.7MB 8389kB PARAM
5 37.7MB 46.1MB 8389kB KERNEL
6 46.1MB 54.5MB 8389kB RECOVERY
7 54.5MB 264MB 209MB ext4 CACHE
8 264MB 1137MB 872MB ext4 FACTORYFS
9 1137MB 15.3GB 4163MB ext2 DATAFS
10 15.3GB 15.7GB 470MB ext4 HIDDEN
11 15.7GB 15.8GB 8389kB FOTA
>>> P6800 <<<
The start/end values are wrong, please give me your p6800 output so I can update this.
Code:
Number Start End Size File system Name Flags
1 4194kB 25.2MB 21.0MB ext4 EFS
2 25.2MB 26.5MB 1311kB SBL1
3 27.3MB 28.6MB 1311kB SBL2
4 29.4MB 37.7MB 8389kB PARAM
5 37.7MB 46.1MB 8389kB KERNEL
6 46.1MB 54.5MB 8389kB RECOVERY
7 54.5MB 264MB 209MB ext4 CACHE
8 3054MB 3926MB 872MB ext4 MODEM/RADIO (not sure as I don't own this model)
9 264MB 1137MB 872MB ext4 FACTORYFS
10 1137MB 15.3GB 4163MB ext2 DATAFS
11 15.7GB 15.8GB 8389kB HIDDEN
12 15.8GB 15.9GB 8389kB FOTA
The superbrick MMC_CAP_ERASE bug that affects our tab apparently only corrupts the /system and /data partitions (sometimes, /cache can also get corrupt in the process, I cover this in the last part of this guide, "extra cases").
Your emmc chip on which resides those /data & /system partitions is corrupt at some places.
To give you an example, think of it as a chain of dashes :
Code:
-----------------------------------------------------
This dash chain is divided in two parts (our /system and /data partitions), I'll symbolize their length with "[]" for /system and "()" for /data :
Code:
[----------](-------------------------------------------)
So that's how it was on your tab before brick, but now it's bricked some blocks (the dashes "-" here) are corrupt. I'll symbolize them with "?" :
Code:
[--??--???-](--???-?-----------????-----------??-?--??--)
Now you figure the workaround don't you ? We need to move our /system & /data partitions to places that are clean, at the cost of reducing their sizes :
Code:
--??--???---???-?[-----------]????(-----------)??-?--??--
We will strive to give /system its original size, or something close to it, while we can sacrifice more of the /data partition.
Ok, enough theory, let's move on to practice.
Here, in parted, /system = FACTORYFS and /data = DATAFS
We are going to remove the /data partition first, so we have some space to work on.
Enter the following :
>>> P6810 <<<
Code:
(parted) rm 9
>>> P6800 <<<
Code:
(parted) rm 10
Now please refer to the output of (parted) print you had earlier, just scroll up a little in your terminal window. See those Start/End values ? Well check the end value of your DATAFS partition and remember it.
Here's an example for P6810 :
Code:
9 *START -->*1137MB 15.3GB*<-- END* 4163MB ext2 DATAFS
So now comes the boring part. We are going to try to make a new clean /data partition.
Seems easy but the problem is :
- if you try to make it too big, it'll get stuck and return an I/O error.
- if some blocks are corrupt between the start/end values you'll enter it will get stuck and return an I/O error.
In both cases you'll have to reboot recovery and re-enter this in your terminal :
Code:
# adb shell
# parted /dev/block/mmcblk0
So this is long and boring to find the right place and the right size. Don't be greedy on the size, as long as you get at least 150-200mb it's cool, you'll be able to expand that later.
First you're gonna try to put the original end value (15300 in the p6810 example up there) as the new end value. So for the same example, if you wanna try to make a 500mb /data partition, you're gonna use 14800 as start value and 15300 as end value.
Ok let's go (this is still an example for p6810, for the p6800 owners, use your own (parted) print results) :
Code:
(parted) mkpartfs primary ext2 14800 15300
It will output something like this :
Code:
writing per-group metadata : XX %
Here there are two options :
- You were lucky, it will complete up to 100% and return "(parted)", which case you just have to enter the following :
>>> P6810 <<<
Code:
name 9 DATAFS
>>> P6800 <<<
Code:
name 10 DATAFS
- You were not lucky, it got stuck before reaching 100%, which case you have to reboot your recovery, re-enter parted and try again with a smaller start/end gap, or reducing the end value, you got about 14gb of space to try to make your partition, so it's sure you can find somewhere to put your small partition, just requires some blind testing.
Just remember to try to put your /data partition quite close to the end (original end value), so you still have some space to find somewhere to put your /system partition.
So now we'll assume you managed to have mkpartfs complete till 100%
Type this to see your updated partition table :
Code:
(parted) print
Now we're going to repeat last step with the /system partition.
Issue this :
>>> P6810 <<<
Code:
rm 8
>>> P6800 <<<
Code:
rm 9
The /system partition is much more important than /data, so you want to try to have its size remaining the same (872mb).
At first, you can try to re-make the /system partition with the same start/end values. It's not likely to work but it's worth trying.
Here's an example on P6810:
(again, if you're on P6800, then use your own start/end values for the 9th partition (FACTORYFS), you get them by typing print in parted).
Code:
(parted) mkpartfs primary ext2 264 1137
Same thing here, if it doesn't complete, then reboot recovery, type :
Code:
$ adb shell
# parted/dev/block/mmcblk0
And repeat this step until you find somewhere it works : (where YYY - XXX = 872)
Code:
(parted) mkpartfs primary ext2 XXX YYY
Remember to limit your research between FACTORYFS original start value (264 for P6810) and the new DATAFS start value you made, so you keep the order of the partitions.
Once you found the right place (where "writing per-group metadata" completes till 100%), type this :
>>> P6810 <<<
Code:
name 8 FACTORYFS
>>> P6800 <<<
Code:
name 9 FACTORYFS
The hardest part is done, if you type this you should get a full table of partition, make sure no number is missing or disordered (1,2,3,4,etc...).
Code:
(parted) print
3) Meet another good friend : e2fsck
Now we've done our fresh and clean partitions, you must be thinking we're done, but we're not ^^
In fact the two partitions we made are using ext2 filesystem, but the /system partition's filesystem should be ext4 (like it was at the beginning).
There are two ways of converting an ext2 filesystem to ext4 that I know of :
- Simply formatting /system in cwm recovery will convert the filesystem to ext4. To do this, just head to "mounts & storages" and select "format /system".
If it gets stuck while formatting, reboot your recovery by pressing the power+volume-up buttons for about 15 seconds, and head to the next part, you have to do something before you can try to format it again.
- Or issuing this in terminal :
>>> P6810 <<<
Code:
# tune2fs –O dir_index,uninit_bg,has_journal /dev/block/mmcblk0p8
>>> P6800 <<<
Code:
# tune2fs –O dir_index,uninit_bg,has_journal /dev/block/mmcblk0p9
To make sure either of the two ways worked do this :
Code:
# parted /dev/block/mmcblk0
(parted) print
And look if FACTORYFS shows ext4.
If it does, reboot recovery, then on to next part. If it doesn't, then still reboot recovery and head to next part, after which I'll redirect you here to try again.
Now we are going to use e2fsck to check our new partitions for errors, but not only, it also fixes some erros and it will even for example create lost & found in /data
So let's go, we'll begin with /system. If you're still in the (parted) shell, use ctrl+c and type "adb shell", then issue the following :
>>> P6810 <<<
Code:
e2fsck -yfDC0 /dev/block/mmcblk0p8
>>> P6800 <<<
Code:
e2fsck -yfDC0 /dev/block/mmcblk0p9
This might take long, or not, this might get stuck, or not. Either way reboot recovery if it gets stuck or whatever, but do it again till it finishes properly.
This is what my /system e2fsck final output looks like (p6810) :
Code:
/dev/block/mmcblk0p8: ***** FILE SYSTEM WAS MODIFIED *****
/dev/block/mmcblk0p8: 2636/53312 files (1.2% non-contiguous), 101948/212890 blocks
If you got 0.0% or like less than 5% in "(X.X% non-contiguous)" this is a good sign.
Now reboot recovery and let's do the same for /data :
>>> P6810 <<<
Code:
# e2fsck -yfDC0 /dev/block/mmcblk0p9
>>> P6800 <<<
Code:
# e2fsck -yfDC0 /dev/block/mmcblk0p10
Same thing here, if it gets stuck then reboot recovery and do it again.
Here you should get 0.0% non contiguous. If you don't, in cwm do wipe data/factory reset, then reboot recovery and do this e2fsck again.
Ok now you got both clean e2fsck, (if you still have an ext2 FACTORYFS then now is the time to go back to try converting ext2 to ext4 again)
Make sure the e2fsck still are clean by doing this (it should be quick this time) :
>>> P6810 <<<
Code:
# e2fsck -cy /dev/block/mmcblk0p8
# e2fsck -cy /dev/block/mmcblk0p9
>>> P6800 <<<
Code:
# e2fsck -cy /dev/block/mmcblk0p9
# e2fsck -cy /dev/block/mmcblk0p10
Now you should be nearly good to go ! :laugh:
Download the cm9/cm10-based rom you want, make sure you check known issues and that you like this rom because everytime you'll want to flash a rom it's likely you'll have to do the whole e2fsck part again, or even sometimes the whole guide.
Now reboot in recovery and flash the rom. Two options :
- it flashes, then reboot, pray and be patient, if it takes more than 15 minutes to boot first time, then reboot it again, do this a few times if it doesn't boot, it might eventually do. If it doesn't, then reboot recovery and redo the e2fsck command for both /data and /system, let it fix things if it has to, then reboot again. Anyway it should have booted by now.
- flashing gets stuck : make sure you waited at least 5 minutes then reboot recovery---> wipe data/factory reset---> wipe dalvik cache---> reboot recovery---> adb shell and redo the e2fsck on both /data and /system, then try flashing again.
DO NOT FLASH THE GAPPS NOW, that will screw all you just done ! If you need the gapps then head to the following section of this guide.
4) Installing the gapps
If you flash the gapps after flashing the rom you'll be screwed, you'll have to redo the e2fsck part and maybe even the parted, and I know you don't want to.
So the workaround is to add the gapps to the cm-based rom you downloaded.
It's easy, just follow me :
Open the zipped rom you downloaded with 7zip or WinRar (Windows), or with Archive Manager or else (Ubuntu). Do not extract it, we'll modify the zip directly.
Do the same with the gapps, so you have both archive side to side.
In the rom, you have boot.img, and two folders : "META-INF" and "system". We will modify things in "system" folder ONLY. Open "system" folder.
In the gapps we will only use things from the "system" and "optional" folders.
The rest is pretty easy to figure out. In the gapps's "system" and "optional" folders you have folders which have the same name as some folders in "system" of the rom.
Just copy/replace everything that is in those folders of the gapps to the corresponding folders of the rom. Don't forget to do that with both "system" AND "optional" folders of the gapps.
When it's done just close the freshly modified rom, copy it to your tab's external sdcard and flash it.
If you don't have an external sdcard, then reboot recovery, copy the rom to the "platform-tools" folder of your android-sdk and rename it rom.zip.
Then return to your terminal and do the following :
Code:
$ adb push rom.zip /sdcard
It will now be in your internal sdcard (remember you shrinked it earlier so make sure the rom doesn't take all the space).
5) Expanding your internal storage
I don't recommend you do this the first time you follow this guide.
It might screw your /data partition so you have to do the whole process I describe in this guide again.
Anyway if you wanna try, this allowed me to earn a few extra gigs (never managed to get back more than 4gb and boot).
Here's what to do :
>>> P6810 <<<
Code:
$ adb shell
# parted /dev/block/mmcblk0
(parted) resize 9
>>> P6800 <<<
Code:
$ adb shell
# parted /dev/block/mmcblk0
(parted) resize 10
This will output something like :
Code:
Start ?
End ?
writing per-group metadata : XX %
You can only move the end value in fact, trying to change the start value will return an error. Try doing this to earn like 250mb at a time so it doesn't get stuck. Good luck.
6) Extra cases
If when booting in recovery, the recovery says something like "can't read /cache/recovery/last-log, Read-Only file system" then your /cache partition is corrupt.
Then you'll need to recreate it with parted. /cache is quite small (209mb) so it should be easy to have "writing per-group metadata" finishing.
Here are the commands to remove and recreate /cache with parted (it's the same on both models) :
Code:
$ adb shell
# parted /dev/block/mmcblk0
(parted) print
(parted) rm 7
(parted) mkpartfs primary ext2 XX YY (where YY - XX = 209 and YY < FACTORYFS start value)

Nice guide...dude. Thanks for sharing

i being running e2fsck -yfDC0 /dev/block/mmcblk0p10 on my p6800 since yesterday this time. till now still show error reading block *******<attempt to read block from filesystem resulted in short read> while getting next indoe from scan. ignore error? yes
force rewrite? yes
question now is should i let it keep running or change to e2fsck -fDC0 /dev/block/mmcblk0p10 ?? hmm

Josvaz said:
i being running e2fsck -yfDC0 /dev/block/mmcblk0p10 on my p6800 since yesterday this time. till now still show error reading block *******<attempt to read block from filesystem resulted in short read> while getting next indoe from scan. ignore error? yes
force rewrite? yes
question now is should i let it keep running or change to e2fsck -fDC0 /dev/block/mmcblk0p10 ?? hmm
Click to expand...
Click to collapse
Not sure but this "attempt to read block resulted in short-read" error remembers me of my own brick, I think it's the error you get when you can't mount /data in recovery's mounts & storages.
Try to mount /data and if recovery can't mount it, then u need to recreate your /data partition with parted, like it's explained in this guide.
e2fsck alone won't fix it if it's not mountable.
Just talking from my own experience, but there might be other ways.

two questions:
1) i read something about having to back up the /efs partition? as it contains your bluetooth mac id and your emei number before flashing any alternative pit file
2) when i try to start the android SDK installer it says "Java SE Development Kit (JDK) no found. </br> Error: Failed to find Java version for 'C:\Windows\system32\java.exe,' blah blah blah"--is it because i tried to install the jdk 64-bit?
---EDIT--- solved the installation problem. setting up android SDK now...

aletheus said:
two questions:
1) i read something about having to back up the /efs partition? as it contains your bluetooth mac id and your emei number before flashing any alternative pit file
2) when i try to start the android SDK installer it says "Java SE Development Kit (JDK) no found. </br> Error: Failed to find Java version for 'C:\Windows\system32\java.exe,' blah blah blah"--is it because i tried to install the jdk 64-bit?
---EDIT--- solved the installation problem. setting up android SDK now...
Click to expand...
Click to collapse
Well yeah you can backup your efs but if you follow exactly this guide there's no way you can mess up your efs, as it's the first partition and we only deal with partitons 8 to 10.
Not sure but this "attempt to read block resulted in short-read" error remembers me of my own brick, I think it's the error you get when you can't mount /data in recovery's mounts & storages.
Try to mount /data and if recovery can't mount it, then u need to recreate your /data partition with parted, like it's explained in this guide.
e2fsck alone won't fix it if it's not mountable.
Just talking from my own experience, but there might be other ways.
Click to expand...
Click to collapse
I guess e2fsck won't run if the partition you check isn't mountable.
But you're right that e2fsck can't fix everything, the method I describe is drastic but it works.
So Josvaz, if after running e2fsck - try any options you want, won't harm (but add -y so it answers yes to all and you can go have a coffee) - you see more than 2 or 3% in " XX.XX% non contiguous" then remove your partition and recreate it using parted's mkpartfs, and re-run e2fsck, it should now be clean (0.0% non contiguous) and you can flash on it and boot your tab if your /system is clean (or close to) too.
Good luck.

Androguide.fr said:
- The first is to flash a PIT file with ODIN that will repartition your tab for you.
I will not cover this method as hg42 already wrote a very detailed tutorial about this. This tutorial is about Galaxy Note but you can appIy it to our 7.7 and you'll find PITs for P6800 there. I will soon make pits for P6810 using the scripts provided in hg42's guide.
Click to expand...
Click to collapse
but if i use this method, do i need to back up the /efs partition? i guess, i need the experience with abd, and its certainly not going to hurt anything if i do, and didn't need to. so i'll try that and see if i get a response in the mean time.
hg42 said:
You should be able to flash any stock ROM from samfirmware (click on n7000 under "models"), I would recommend the one you had before the brick and and before any stock ICS, else you risk a brick again!.
Note: I think the standard recovery doesn't give you enough format options (a guess, I am running cm9).
Click to expand...
Click to collapse
is this possibly a way to avoid having to go through this process every few days or so?

aletheus said:
but if i use this method, do i need to back up the /efs partition? i guess, i need the experience with abd, and its certainly not going to hurt anything if i do, and didn't need to. so i'll try that and see if i get a response in the mean time.
Click to expand...
Click to collapse
Yeag for the PIT method, backing up your efs is wise, although the PITs won't mess with it normally. But yeah, can't hurt to back it up.
You don't need no experience with adb to flash a PIT, just know how to use odin, download the pit for your particular model (eg : p6800 16gb) put it in odin's "PIT" slot (the first slot), make sure repartion IS ticked, click start and let it flash.

giving up lol .. any thing i need to do before i send to samsung ? like original pit, rom etc? anyone have original pit file ?

Josvaz said:
giving up lol .. any thing i need to do before i send to samsung ? like original pit, rom etc? anyone have original pit file ?
Click to expand...
Click to collapse
Don't give up, follow the guide step by step, I assure you that you can get your tab finally booting if you do.

Androguide.fr said:
Yeag for the PIT method, backing up your efs is wise, although the PITs won't mess with it normally. But yeah, can't hurt to back it up.
You don't need no experience with adb to flash a PIT, just know how to use odin, download the pit for your particular model (eg : p6800 16gb) put it in odin's "PIT" slot (the first slot), make sure repartion IS ticked, click start and let it flash.
Click to expand...
Click to collapse
okay, but i need adb to back up /efs i think.

aletheus said:
okay, but i need adb to back up /efs i think.
Click to expand...
Click to collapse
Good for you xda recognized developer lyriquidperfection made a tool to backup and restore your efs on samsung devices, head to this thread : http://forum.xda-developers.com/showthread.php?t=1308546

hee i wanna quit cos i cant save more than half the space, manage 3.82GB left~

Androguide.fr said:
Yeag for the PIT method, backing up your efs is wise, although the PITs won't mess with it normally. But yeah, can't hurt to back it up.
You don't need no experience with adb to flash a PIT, just know how to use odin, download the pit for your particular model (eg : p6800 16gb) put it in odin's "PIT" slot (the first slot), make sure repartion IS ticked, click start and let it flash.
Click to expand...
Click to collapse
the efs back up, is that used from within adb, or flashed as part of a recovery or? in other words, how do i use it?

aletheus said:
the efs back up, is that used from within adb, or flashed as part of a recovery or? in other words, how do i use it?
Click to expand...
Click to collapse
It's not done from adb, some apps allow you to backup/restore it (eg : Voodoo Sim Unlock for sgs3), check out the thread I linked earlier.

The best advice I can give to people who haven't bricked their tab (already?^^) : DO NOT EVER WIPE ANYTHING WHILE RUNNING STOCK 7.7 ROMS
Click to expand...
Click to collapse
even on stock honeycomb ?????
am going to get a p6800 3g tomorrow, please don't scare me lol

sos_sifou said:
even on stock honeycomb ?????
am going to get a p6800 3g tomorrow, please don't scare me lol
Click to expand...
Click to collapse
Yeah whether hc or ics, for some reason, samsung devs thought it was a good idea to include mmc_cap erase a.k.a superbrick bug in their kernels.
Anyway I doubt you'd love to stay on y
touchwiz hc, which the most laggy experience I ever had.

sos_sifou said:
even on stock honeycomb ?????
am going to get a p6800 3g tomorrow, please don't scare me lol
Click to expand...
Click to collapse
it wont be a problem in honeycomb...
but its a big problem in ICS

Anyway I doubt you'd love to stay on y
touchwiz hc, which the most laggy experience I ever had.
Click to expand...
Click to collapse
yeah I don't think that i will keep using hc for long, but consider that most isc roms are pipi-caca (wifi issues and battery drain) Ill wait for some stable builds (just like overcome on my beloved "sold" GTP1000).
I think that dedraks made a new kernel which is without the brick bug ? is it safe to use with hc ??
and thanks for the great work you're doing on the new galaxy tab 7.7 (merci beaucoup !)

so i have not figured out how to get a working pit file flashed. there are so many, and i VAGUELY understand his numbering system, so i figured i'd start with the smallest available space first, because that one would be the most likely to account for any bad blocks. i tried nearly ALL of them. now i'm trying to test to see whether adb is able to access ANYTHING-- (tab is booting into recovery and download, and adb detects the device from windows) however, what i'm getting is "/sbin/sh: parted: not found" is that saying that parted cant be found or that parted cant find the reference block? researching this now.
so obviously, i've had to sit down and warm up to your NOOB GUIDE!!! its very clear, i just havent done this level of anything with android, tho what better way to learn than sink or swim? problem is, i'm an artist, and pretty broke.... my computer fried months and months ago, and i just decided i'd rather spend my extra cash on the gTab 7.7 cus is the largest affordable sAMOLED to date, and well, a 30% expansion of the standard color model really appealed to me, so the only thing i have to work on is my super bricked tab!!! a friend of mine is lending me her laptop while she's at work, and i'd like to try to fix it this evening.... ughh....
if anybody can help me figure out my way through this tutorial, i'll be researching why 'parted' isn't working.
THANKS!!!
---UPDATE
okay, so for some reason, i can't seem to push files from adb to the device. from what i've read, i have to manually install parted to sbin, (or there's a flashable kit available also) but i can't figure out how to get it to pick up the file (its in the folder with ADB.exe, so i shouldn't need to reference the path for the copy location, right?)
now i'm looking up general "ADB device navigation and testing"
---ugghhh....

[TESTERS][WIP] Flashable zip to increase SYSTEM partition (Solving Gapps Error 70)

Update 10/26/20:
I didn't worked anymore on this (from january) since there doesn't seem to be much interest on it on Dior's official Telegram Group, but I'm seeing that some people tried to flash the test zip that I had on my bitbucket (altought it wasn 't officially released).
The script works on my device as you can see in the attatched pictures, but needs further testing to solve possible issues it might have with slightly different Dior versions (I don't wanna brick anyone's device).
All that said: I can write some Instructions to flash it if someone is willing to try (at his own risk).
This kind of modifications may potentially brick your device, although risk is reduced to minimum.
Original 1/9/20:
Hi guys,
I'm making a flashable zip for dior to repartition system and give us more space taking it from data partition (this will let us install open_gapps without error 70 on android oreo or pie roms) based on the work by CLAMOR, an Unlegacy Android dev (https://forum.xda-developers.com/nexus-4/orig-development/repartition-nexus-4-repartition-t3844383 ).
I'm gonna need someone with unmodified system partition (if you didn't manually repartitioned it like me, you can help me) and some basic skills: flash a zip in twrp that creates a log file in the root of internal memory (and don't modify anything of your phone), open that log and screenshot or send it to me.
I manually modified the partition table on my dior so mine is no good to check stock partition table.
With that log I can make the flashable zip able to repartition our phones back to stock partition table if anytime is needed.
Download:
- Here's the zip I need you to flash: https://forum.xda-developers.com/devdb/project/dl/?id=30446 (It will not modify or touch anything on your device, only creates a log)
You can see on the pictures that my system partition is bigger and has enough space to install almost any open_gapps package (400mb free after install mokee 9.0 experimental build)
The scripts are almost finished, with your help I will be able to finish it very soon!
Source Code: https://bitbucket.org/endlssprdx/dior-repartition-script/
Credits:
- Unlegacy Android Team
- Clamor (https://forum.xda-developers.com/member.php?u=5424240 )

Hi! Thanks for your work! Is the zip flasheable ready? I'm trying to upgrade the phone but system partition is too small. Any help would be great.
Thank you.
Enviado desde mi LG-H850 mediante Tapatalk

Log System Partition
Hello,
Here information that you requested, I need resize partition system, please you help me!!!
My phone is XIAOMI REDMI NOTE 4G SINGLE SIM DIOR (first generation)
Rom installed Mokee MK71.2-dior-190228-HISTORY.
Gapps: open_gapps-arm-7.1-pico-20200612
status: Works fine, I force installation of gapps but System is insufficient so system is to limited and after days the rom crashes or dropped with failures services play google.
Model: MMC 008GE0 (sd/mmc)
Disk /dev/block/mmcblk0: 7818182656B
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Number Start End Size File system Name Flags
1 17408B 2097151B 2079744B sbl1
2 2097152B 4176895B 2079744B sbl1bak
3 4176896B 5225471B 1048576B rpm
4 5225472B 6274047B 1048576B rpmbak
5 6274048B 7322623B 1048576B tz
6 7322624B 8371199B 1048576B tzbak
7 8371200B 8379391B 8192B ssd
8 8379392B 9427967B 1048576B sdi
9 9427968B 10476543B 1048576B DDR
10 10476544B 14670847B 4194304B aboot
11 14670848B 18865151B 4194304B abootbak
12 18865152B 24108031B 5242880B bk1
13 24108032B 28302335B 4194304B misc
14 28302336B 36690943B 8388608B logo
15 36690944B 67103743B 30412800B bk2
16 67103744B 68676607B 1572864B modemst1
17 68676608B 70249471B 1572864B modemst2
18 70249472B 70250495B 1024B fsc
19 70250496B 134212607B 63962112B bk3
20 134212608B 135785471B 1572864B fsg
21 135785472B 167767039B 31981568B bk4
22 167767040B 201321471B 33554432B bk5
23 201321472B 268430335B 67108864B fat16 modem
24 268430336B 285207551B 16777216B boot
25 285207552B 301984767B 16777216B recovery
26 301984768B 335539199B 33554432B ext4 persist
27 335539200B 1174399999B 838860800B ext4 system
28 1174400000B 1577053183B 402653184B ext4 cache
29 1610612736B 7818165759B 6207553024B ext4 userdata

after flashing your zip (https://bitbucket.org/endlssprdx/dior-repartition-script/downloads/) and writing "modify" in terminal as per instruction, twrp now fails to mount all partition except system and now I can't do anything

abhi21sept said:
after flashing your zip (https://bitbucket.org/endlssprdx/dior-repartition-script/downloads/) and writing "modify" in terminal as per instruction, twrp now fails to mount all partition except system and now I can't do anything
Click to expand...
Click to collapse
Hey, sorry for the delay.
Did you solved or do you still have problems? I didn't worked on this script since january (people didn't showed many interest on it on official Dior's Telegram Group).
The script itself needs a little bit of testing but works on my Dior (I didn't released officialy so that's why there isn't any instructions).
What you're facing it's normal:
After flashing it with the "modify" command, it's mandatory to format everything in your phone. (mount errors will not affect formatting)
- In TWRP: Wipe > Format data
- Type yes
- Once this completes go to: Wipe > Advanced Wipe
- Tick all the boxes and wipe. There should be no further mount errors.
After doing this and maybe rebooting TWRP you should be able to mount every partition and check your new System increased space:
TWRP > Wipe > Advanced Wipe > Tick System > Repair or change filesystem > And then you will be able to check it at "Size:".
If it shows the old size that's normal, do a "Repair File System" and "Resize File System". It should show the increased space now.
From now on, after installing a new rom (before flashing gapps or anything else), you probably need to do this too (repair and/or resize system partition filesystem).
This happens because our TWRP still believes that the system size is the stock one (we need a modified TWRP with increased system partition info to solve this, but I dunno how to do it).
If you want to go back to stock system size all you have to do is reflash the script, now it will promt you to type "stock" instead of "modify" on twrp terminal. (Also need to format everything as I said earlier when back to stock).
I hope you would be able to solve your problem

lusagad01 said:
Hi! Thanks for your work! Is the zip flasheable ready? I'm trying to upgrade the phone but system partition is too small. Any help would be great.
Thank you.
Enviado desde mi LG-H850 mediante Tapatalk
Click to expand...
Click to collapse
herreradimas said:
Hello,
Here information that you requested, I need resize partition system, please you help me!!!
My phone is XIAOMI REDMI NOTE 4G SINGLE SIM DIOR (first generation)
Rom installed Mokee MK71.2-dior-190228-HISTORY.
Gapps: open_gapps-arm-7.1-pico-20200612
status: Works fine, I force installation of gapps but System is insufficient so system is to limited and after days the rom crashes or dropped with failures services play google.
...
Click to expand...
Click to collapse
I didn't worked anymore on this since january, but works fine on my device (it need more testing to solve possible issues, didn't wanna brick anyone's device). There's a flashable zip available on my bitbucket if someone wants to test at his own risk. I can give you instructions on how to flash it and how to flash roms in the future with the extended system partition, but I didn't released it officially and will not make me responsible if something goes wrong. The script may potentially brick your device, although risk is reduced to minimum.
PS: Although I'm not working on this anymore, wanna thank you herreradimas, you are the second person since January that sent me the logs I needed to finish it hahhaha

endlssprdx said:
Hey, sorry for the delay.
Did you solved or do you still have problems? I didn't worked on this script since january (people didn't showed many interest on it on official Dior's Telegram Group).
The script itself needs a little bit of testing but works on my Dior (I didn't released officialy so that's why there isn't any instructions).
What you're facing it's normal:
After flashing it with the "modify" command, it's mandatory to format everything in your phone. (mount errors will not affect formatting)
- In TWRP: Wipe > Format data
- Type yes
- Once this completes go to: Wipe > Advanced Wipe
- Tick all the boxes and wipe. There should be no further mount errors.
After doing this and maybe rebooting TWRP you should be able to mount every partition and check your new System increased space:
TWRP > Wipe > Advanced Wipe > Tick System > Repair or change filesystem > And then you will be able to check it at "Size:".
If it shows the old size that's normal, do a "Repair File System" and "Resize File System". It should show the increased space now.
From now on, after installing a new rom (before flashing gapps or anything else), you probably need to do this too (repair and/or resize system partition filesystem).
This happens because our TWRP still believes that the system size is the stock one (we need a modified TWRP with increased system partition info to solve this, but I dunno how to do it).
If you want to go back to stock system size all you have to do is reflash the script, now it will promt you to type "stock" instead of "modify" on twrp terminal. (Also need to format everything as I said earlier when back to stock).
I hope you would be able to solve your problem
Click to expand...
Click to collapse
After flashing your script when everything became 0mb I formatted every partition but data and cache partitions still failed to mount so I reflashed your script and flashed stock fastboot rom