Database Users

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.

Acer A200 - BRICKED, cannot mount /data /sdcard

I did something stupid. Got an A200 that could not get OTA 4.0.3, so I managed to get it updated manually. However, I then proceeded to try to root it using the "SimpleRoot" scripts on Acertabletforum, and at this point, the thing is bricked. In Recovery, I cannot get anything to mount. /SDCard, /data, etc
Bootloader is Unlocked
I tried with some different Recoveries with slightly different results:
1) Hbwelch CWM v5.5.0.4 (the one that comes with SimpleTool) - All mounting attempts fail
2) nics-TWRP_stable (twrp v 2.1.4) - Seems to be able to mount System and Cache, but not DATA or SDCARD (Internal or External)
3) thor v 5.5.0x (thor2002ro rev1.7) - errors mounting data, sdcard and /mnt/sdcard. Is able to mount system, cache, flexrom and flex.
Any idea how to fix it? I am afraid that if I try to return the tablet where I bought it as it is now, it will get rejected. (even though the damn thing was supposed to be ICS upgradable in the first place, but wasn't... long story)
Thanks
Jerry

I finally got the tablet working again. Was very close to sending it back. Got bits and pieces of info from various other posts on this forum and on acertabletforum. For the sake of anyone else that may find this thread, here are a few things that were wrong, and how to fix them
(I cannot post outside links, so just google the file names when relevant)
1) /SDCard would not mount. Solution - PARTITION the SD card. NOTE: The card worked on a PC, and even on that tablet when Android was fully booted. However it would NOT mount in recovery until I explicitly partitioned it. Doing a FORMAT on the PC does NOT count. I had to partition it within Recovery.
NOTE: This may also be why people are unable to get the update.zip thing working.
2) /Data would not mount - I have no idea how this got screwed up, but the solution was:
* Connect the tablet to the PC in RECOVERY. At this point, ADB should work. If not, check the drivers on the PC - I had to manually specify the Acer ADB Composite driver.
* Open a Command prompt window
* Start ADB shell by typing:
ADB SHELL
* Now execute the following:
mke2fs -j -b 4096 /dev/block/mmcblk0p8
tune2fs -O extents,uninit_bg,dir_index -C 1 /dev/block/mmcblk0p8
e2fsck -fy /dev/block/mmcblk0p8
After this is done your file system on /data will be fixed. (solution posted by spoupard on XDA-Developers.com)
3) Putting it all together:
* Flashed the BOOT partition with Honeycomb 3.2.1_boot.img
* Flashed the RECOVERY partition with nics-TWRP_stable.img
* At this point, I noticed that the Bootloader was once again LOCKED. So, start into FASTBOOT mode and execute the following from the command prompt again:
fastboot oem unlock
* Re-Start in Recovery and select MOUNT and make sure that everything is mounted. If /SDCARD or /DATA refuse to mount, fix that issue first (step 2 above)
* Now I select to INSTALL Acer_AV041_A200_1.037.00_PA_CUS1.zip
Upon reboot, I noticed that it said "Updating Bootloader", then got the Acer screen and locked up. I restarted again into Recovery and again selected the option to install INSTALL Acer_AV041_A200_1.037.00_PA_CUS1.zip and reboot. This time it restarted, indicated that it has a new version of bootloader (previously was 3.1.3) and proceeded to boot up into Android 4.0.3. At that point, I think my neighbors heard me scream YES!, considering I spent 2 days on this
I hope I got all the steps. Most of it is from memory and some notes, since I did not want to experiment and go through this hell again.
Jerry

Great info but you might want to add fixed to the title. For the time being doesn't look like I will be rooting till these issues are sorted out. I am see too many people saying they are bricking with this root method.

FIXED - Acer A200 - BRICKED, cannot mount /data /sdcard
agapecs said:
Great info but you might want to add fixed to the title. For the time being doesn't look like I will be rooting till these issues are sorted out. I am see too many people saying they are bricking with this root method.
Click to expand...
Click to collapse
Didn't see a way to edit the title. As for rooting, note that after all was said and done, I am still not rooted. I just managed to get updated to 4.0.3, which should have been done OTA anyway. I may try again now that I am a bit more confident that I can get it back to working state, but will do a full backup in ADB first. Too much of a pain in the *** to have to reconfigure everything again once the OS is installed.

I cannot get the device to connect to my PC at all, or get the correct driver selected. Any tips?

crazyjimbo said:
I cannot get the device to connect to my PC at all, or get the correct driver selected. Any tips?
Click to expand...
Click to collapse
what state is the tablet in when you try to connect? Fastboot, Recovery, or fully booted up and operating?
What do you see in the device manager when the tablet is connected?

ext3 oder ext4?
1) /SDCard would not mount. Solution - PARTITION the SD card. NOTE: The card worked on a PC, and even on that tablet when Android was fully booted. However it would NOT mount in recovery until I explicitly partitioned it. Doing a FORMAT on the PC does NOT count. I had to partition it within Recovery.
Try to do this with twrp v.2.1.4: do I use ext3 or ext4 for the Partition? And which size needs the ext Partition?
Thanx
teacherHH

teacherhh said:
Try to do this with twrp v.2.1.4: do I use ext3 or ext4 for the Partition? And which size needs the ext Partition?
Click to expand...
Click to collapse
Don't think it matters. I picked the defaults.

mke2fs -j -b 4096 /dev/block/mmcblk0p8
Thanx j_medved for yor reply!
So I did and just faced the next problem: I can conect my Tablet to the PC and can finde it with adb devices and can start the shell with adb shell.
But then when I start: mke2fs -j -b 4096 /dev/block/mmcblk0p8
nothing seems to happen....waited about 30 minutes....
in the next turn I get the reply, that mmcblk0p8 is allready in use....next turn again: nothing seems to happen....
any ideas? .-(
teacherhh

teacherhh,
If I remember correctly, that command should finish pretty quick. You may want to try leaving it for a bit longer, but it seems that you may have something else wrong. I am not that familiar with this area. Haven't dealt with Linux much. Sorry.

Okay. Thanx anyway!
Sent from my GT-I9300 using xda app-developers app

again mke2fs
Once again j_medved...
did it look likes this, wenn you run mke2fs ?
Regards,
teacherhh

teacherhh said:
Once again j_medved...
did it look likes this, wenn you run mke2fs ?
Regards,
teacherhh
Click to expand...
Click to collapse
Don't remember what it was for me (was a month ago ) , but another couple users that ran it had the following:
Code:
~ # mke2fs -j -b 4096 /dev/block/mmcblk0p8
mke2fs -j -b 4096 /dev/block/mmcblk0p8
mke2fs 1.40.8 (13-Mar-2008)
Warning: 256-byte inodes not usable on older systems
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
1831424 inodes, 7311872 blocks
365593 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=0
224 block groups
32768 blocks per group, 32768 fragments per group
8176 inodes per group
Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
4096000
Writing inode tables: 52/224
Couple users that were hosed, were stuck at this point. Did not see any indication of resolution for those users

Driver Problems
Hi Guys,
I've the same problem. I can't wipe the Data, so I've found this instruction. unfortunenately will my PC not found my Tab. I've installed the drivers many times, but it will not work. Can anybody help, how to install? btw. fastboot is working, but not adb.
I'm using an Samsung Netbook with Win 7. THe PC's trying to install drivers, altough they are already installed, but can'T find any drivers.
If you need more informations, just let me know.

@Benninator,
If you look in Windows 7 Device Manager, does the device show up there OK? Or does it show up as unrecognized device, or as some device code with a yellow triangle and exclamation on it? Or not at all?

Yes, their is a yellow triangle. I've tried to install the driver manually, but with no success. In my driverlist were the Acer driver not listed. furthermore I've tried to configure the usb-adb.ini with also no success. I have absolutly no idea what I can do.

In device manager, and does it show up as a200 or unknown device?
Is the device I am recovery at the time?
And also, and which recovery?

Tab is missing recovery and won't boot in to android
FASTBOOT WORKS BUT I GET THIS MESSAGE EVERY TIME I TRY TO FLASH RECOVERY.IMG says unknown partiton 'C:\James\Downloads\recovery.img'
error: cannot determine image filename for 'C:\James\Downloads\recovery.img'
Please help me

jram0421 said:
FASTBOOT WORKS BUT I GET THIS MESSAGE EVERY TIME I TRY TO FLASH RECOVERY.IMG says unknown partiton 'C:\James\Downloads\recovery.img'
error: cannot determine image filename for 'C:\James\Downloads\recovery.img'
Please help me
Click to expand...
Click to collapse
I think you may be mistyping the command. What is the exact command that you are typing in that gets you this error?

cant get adb drivers installed in my pc
adb driver seems not to work at all when i try to boot my tablet on cwd when i boon on fastboot only fastboot recognice my device and when i let my acer a200 try to boot itself it gets stuck on acer screen whit this on top ( bootloader version 0.03.06-ics ) but windows recognice it but fails when installing the mtp usb drivers.
what can i do to get adb working so i can fix my mount issues so i can install my room again ?
hope you can help me tnks

[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....

[HELP] mmcblk0p7 flashed with recovery.img

Hello, I think I have did a big mistake.
I was trying to install CWM via Terminal Emulator with this command:
dd if=/sdcard/cwm.img of=/dev/block/mmcblk0p7
Then I know what mmcblk0p7 was not the recovery partition, but it is a PER partition.
Until now, my device is still on because I didn't reboot/turn-off it. I'm afraid if I reboot it, then it will die because mmcblk0p7 was flashed with wrong image.
Does anybody know how to fix it, or is it safe if I reboot my device? It has been 4 days of no reboot until I'm sure it's ok for reboot.
Thanks in advance!

What exactly lies in the mmcblk0p7 partition?

MOVZX said:
Hello, I think I have did a big mistake.
I was trying to install CWM via Terminal Emulator with this command:
dd if=/sdcard/cwm.img of=/dev/block/mmcblk0p7
Then I know what mmcblk0p7 was not the recovery partition, but it is a PER partition.
Until now, my device is still on because I didn't reboot/turn-off it. I'm afraid if I reboot it, then it will die because mmcblk0p7 was flashed with wrong image.
Does anybody know how to fix it, or is it safe if I reboot my device? It has been 4 days of no reboot until I'm sure it's ok for reboot.
Thanks in advance!
Click to expand...
Click to collapse
PER - Per device provisioned data or per device calibration.
A cursory scout around XDA suggests this contains sensor calibration and such like.
http://forum.xda-developers.com/showthread.php?t=1739119
(edit: checkout the last posts by osm0sis - this guy knows his stuff when it comes to partitions).
I'm pretty sure it isn't the BOOTLOADER partition...
I would tentatively suggest you're OK for a reboot. I can't think of what else you can do, to be honest.
-----------
If you must flash a recovery using the dd command use the by-name syntax...
su
dd if=/sdcard/recovery.img of=/dev/block/platform/sdhci-tegra.3/by-name/SOS
Rgrds,
Ged.

@GedBlake
Thanks for the info. I was asking, because if it didn't vary from device to device I could probably dd up a backup of the partition and upload it here for the user to dd into his partition in his tablet.
That being said, I'll keep an eye on this thread for further consequences or the like.

@MOVZX
Please state whether you have a Grouper or Tilapia device, and the approximate manufacturing date, if known.
The PER partition is formatted as a FAT filesystem**. It seems to contain measurement data created during factory testing procedures. See here.
Note that there seem to be differences from device to device (compare the two posts in the above link). Here are the two critical questions:
1) What is the exact FAT format? (There are a couple of different FAT variants)
2) Does the bootloader read this partition during hardware initialization?
I seem to remember a thread here in the Nexus 7 forums where someone was claiming to adjust the ambient light sensor by altering a file in the PER partition. If that is correct, then indeed this partition *could* be critical to correct operation of the device.
I think you are being prudent about not rebooting. I also think that you should find someone to volunteer to give you a raw image dump (dd) from a device that is as close to yours as possible. Note that like many other devices, the N7 has hardware variants, and the PER partition seems to reflect that.
The calibration data for your device is now permanently lost, and you are the unfortunate experimenter who will find out the consequences of that.
**If you can not get someone to help you, the issue of the filesystem formatting can be solved by one of us by:
- raw dumping our PER partition, loopback mounting it, removing all files, unmounting it, and then giving that to you.
At least you would then have the correct filesystem formatting, but empty.
Also, please do a
dd bs=1024 of=/dev/null if=/dev/block/platform/sdhci-tegra.3/by-name/PER
to let us know what size your partition is.

@MOVZX
I did a little more poking around. What I had recalled about the lightsensor thing was users reporting mods to a setting in
/data/lightsensor/AL3010_Config.ini
not the file of the same name in the PER partition.
The file in PER (of this same name) appears to have the same value (1382) on my tablet in both the above location as well as the file in PER. I don't know if that really means anything though.
I looked through the ASCII strings in the bootloader image (v 4.18) to see if there was any evidence of the bootloader using the file names in the (intact) PER partition. There was no evidence of this happening whatsoever. Does that mean that the bootloader does not read the PER partition? No, but at least there is no direct evidence of that nature that it does. That is certainly hopeful for you.
I dumped my own PER partition to have a look at it. It is definitely FAT32, but probably was not created with a variant of 'mkdosfs' - more likely a BSD tool, as it has a "BSD 4.4" OEM name. I tried to erase/remove files from a copy of my PER image; unfortunately the linux "shred" utility doesn't really do it's job correctly. I failed trying to create an identical (blank) image using 'mkfs.vfat' - I couldn't get the FAT header data identical to the FAT32 headers in the from-the-factory image in the PER partition on my device.
None of this might be important, though. It is possible that the only reason that there is manufacturing data on the tablet is if Asus wanted to look at aging effects for units returned for RMA (or subjected to shake-n-bake testing).
good luck with your tablet - let us know how everything turns out.

bftb0 said:
@MOVZX
I did a little more poking around. What I had recalled about the lightsensor thing was users reporting mods to a setting in
/data/lightsensor/AL3010_Config.ini
not the file of the same name in the PER partition.
The file in PER (of this same name) appears to have the same value (1382) on my tablet in both the above location as well as the file in PER. I don't know if that really means anything though.
I looked through the ASCII strings in the bootloader image (v 4.18) to see if there was any evidence of the bootloader using the file names in the (intact) PER partition. There was no evidence of this happening whatsoever. Does that mean that the bootloader does not read the PER partition? No, but at least there is no direct evidence of that nature that it does. That is certainly hopeful for you.
I dumped my own PER partition to have a look at it. It is definitely FAT32, but probably was not created with a variant of 'mkdosfs' - more likely a BSD tool, as it has a "BSD 4.4" OEM name. I tried to erase/remove files from a copy of my PER image; unfortunately the linux "shred" utility doesn't really do it's job correctly. I failed trying to create an identical (blank) image using 'mkfs.vfat' - I couldn't get the FAT header data identical to the FAT32 headers in the from-the-factory image in the PER partition on my device.
None of this might be important, though. It is possible that the only reason that there is manufacturing data on the tablet is if Asus wanted to look at aging effects for units returned for RMA (or subjected to shake-n-bake testing).
good luck with your tablet - let us know how everything turns out.
Click to expand...
Click to collapse
Interesting stuff, bftb0, as always...
So what, in your opinion, is the worst case scenario?
If the bootloader is still accessible, couldn't the OP just fastboot flash back to stock?
(Assuming a simple reboot doesn't fix it).
Or does this not touch the PER partition? I would have thought that running the flash-all.* script would reset all partitions back to their default values.
I'm probably missing something here, so apologies - just a suggestion.
Rgrds,
Ged.

@GedBlake
The factory install procedure doesn't touch anything but the "usual suspects".
We sort of already know what the worst case is. As to whether to bootloader "needs" the PER partition or not, I don't really know. At this point my bet is that it does not, but that is purely an educated guess.
@MOVZX
I am attaching a "PER-empty.zip" file to this post. It is tiny because it is an almost empty FAT32 filesystem image (PER.img), so it compressed by nearly 100%. (When you unzip it, the "PER.img" image file should be 5,242,880 bytes, or 5120 kB) If you want to, feel free to un-zip it, and then flash the extracted "PER.img" file to the PER partition on your device.
Assuming you are using adb from your PC with the custom recovery still running:
Unzip PER-empty.zip, then
Code:
adb push PER.img /sdcard/PER.img
adb shell dd if=/sdcard/PER.img bs=1024 of=/dev/block/platform/sdhci-tegra.3/by-name/PER
What this will do is install an almost empty FAT32 filesystem which was created with the exact parameters used on my device. (I assume that your device also has a 5120 kB PER partition, but you have not replied.) The almost part is that I truncated every file in my image to zero length.
That's not much, but at least you will have a valid filesystem and most files of the correct name, even if they are zero length.
Note that once you have a filesystem in the PER partition, you are free to mount it using the custom recovery, and do whatever you please, e.g.:
Code:
adb shell mkdir /data/local/tmp/permount
adb shell mount -t vfat /dev/block/mmcblk0p7 /data/local/tmp/permount
adb shell
$ cd /data/local/tmp/permount
... do whatever you want in here...
$ sync
$ exit
adb shell umount /data/local/tmp/permount
adb shell rmdir /data/local/tmp/permount
good luck with your tablet - let us know how everything turns out.
.

I'm using Nexus 7 WiFi 16GB.
I almost have all the required files. The sensors and lightsensor directories were found mounted at /data/sensors and /data/lightsensor, so I copied it.
Here is the content of my sensors & lightsensore files:
lightsensor/AL3010_Config.ini
1476
Click to expand...
Click to collapse
sensors/AMI304_Config.ini
921368
2048 2048 2048
0 0 0
600 600 600
210 42 -256
0 0 0
0 0 0
103 100 101
0
Click to expand...
Click to collapse
sensors/KXTF9_Calibration.ini
1071 -1035 1034 -1030 -1097 1213
Click to expand...
Click to collapse
The FAT partitions is now Ok.
Now, I'm missing these files:
adc-rawdata.csv
ISN
KXTF9_Calibration.ini
prom-filter-rawdata.txt
rawdata.csv
rek-prom-rawdata.txt
SSN
Click to expand...
Click to collapse
I'm having no confidence to reboot this device yet

[Q] Nexus 7 reboots constantly every 2 mins or so

My stock/unlocked nexus 7 2012 updated to android 4.4.0 KRT16S after being idle about 12 hours, i picked it up and just a couple minutes into browsing it started rebooting on it's own.
The weird things don't end here, since after every reboot it goes back to the exact same state it was before: if it were done updating an app, or I enabled ADB or turned off the wifi or whatever, and then suddenly reboots, all these things would go to the state they were before (WIFI on, ADB off, changes in apks, even files sideloaded).
I tried to clear the cache through recovery, but it didn't work, I also tried sideloading the ota update to 4.4.2, but it won't find the file in the root folder, as it just disappears. When i went to the nexus tool kit i was not able to unlock the bootloader, or to factory reset( not even from the device itself) or do anything to get out of this situation.
The only thing i can do for now is turn the tablet off and do nothing with it.
Has anyone an idea i can try?

Can really nobody help?
Sent from my Nexus 4 using Tapatalk

You have to create a hypothesis and then perform an experiment that tests that hypothesis. (There's a ferociously complicated processor and millions of lines of code involved; nobody is going to put their finger on the exact cause of a vaguely described problem from across the internet)
For instance:
Hypothesis A: There is a significant hardware problem which causes spontaneous reboots, and it doesn't matter what software is running for the fault to appear.
Test A: Plug the tablet in to the charger and boot it in to the recovery. Let it sit a while. Does it spontaneously reboot?
Hypotheses B: There is a software problem with the ROM I am using that causes sponateous reboots.
Test B: Back up your data, wipe the tablet, install a brand new ROM, and use it for a while. Does it still reboot?
Hypotheses C: The userdata partition got corrupted somehow which causes it to remount automatically in read-only mode. (Changes are not persistent and the ROM reboots all the time as a result)
Test C: Similar to test B, but destroy the userdata partition and reformat it using fastboot. Put a new ROM on a USB memory stick and use the OTG mounting features of the recovery to deliver a new ROM to the tablet. Is it still rebooting?
See how that goes?
Not trying to be mean or anything, but the lack of responses are probably due to several things; the leading candidate of which is that you mentioned using a toolkit - a sure sign of lack of understanding of how most of this stuff actually works.
It's OK to not understand everything - all of us are learning all the time, and everybody has to start at the beginning. Toolkits surely make some jobs faster - at the cost of hiding the details of how things actually work - and making their users helpless when something goes wrong. Try to avoid them if you can.
good luck

Thank you for the long and elaborate response! I will be the first to admit that I have limited knowledge about these things but the main reason that I used the toolkit was that everything else I tried failed. Of course, as you said there are plenty of things I could have tried, and I tried to explain everything I did to make the job easier for someone to help me out, surely not to let my questions unanswered!
So thank you for the answer, and i'll try everything as soon as possible and keep it posted up
Sent from my Nexus 4 using Tapatalk

Ok after a series of tests, and by the looks of it I think that the right hypothesis is number C, every time it boots back up it loses every change in the system. In the few minutes the tablet stays on, I managed to download the ota update to 4.4.2 but once it rebooted itself into recovery it said no command, hence the files it downloaded were erased and this was also the reason why I couldn't install the update via recovery myself, every time I put the update into the root folder and rebooted into recovery, it told me no command available. And the files would just disappear. The only option i'm left with is to destroy the user data partition using fastboot ( a method i'm not familiar with, but that i'm willing to try) I'll look for a guide, or if you be so kind to recommend one i'd be extremely thankful!
Sent from my Nexus 4 using Tapatalk

Googsx said:
Ok after a series of tests, and by the looks of it I think that the right hypothesis is number C, every time it boots back up it loses every change in the system. In the few minutes the tablet stays on, I managed to download the ota update to 4.4.2 but once it rebooted itself into recovery it said no command, hence the files it downloaded were erased and this was also the reason why I couldn't install the update via recovery myself, every time I put the update into the root folder and rebooted into recovery, it told me no command available. And the files would just disappear. The only option i'm left with is to destroy the user data partition using fastboot ( a method i'm not familiar with, but that i'm willing to try) I'll look for a guide, or if you be so kind to recommend one i'd be extremely thankful!
Sent from my Nexus 4 using Tapatalk
Click to expand...
Click to collapse
Normally user-level changes would be recorded in the /data partition, so if it got corrupted some way AND the OS mounts that filesystem with a errors=remount-ro then that would explain lack of persistence.
However, not every OS or recovery boot uses the same mount options. I'm looking at a CM boot right now and I don't see that
Code:
/dev/block/platform/sdhci-tegra.3/by-name/UDA /data ext4 rw,seclabel,nosuid,nodev,noatime,errors=panic,user_xattr,acl,barrier=1,nomblk_io_submit,data=ordered 0 0
But anyway, if you are going to reformat your "userdata" partition, try and rescue everything off of the tablet.
Is the recovery boot stable? If so, you might want to use "adb pull" to recursively pull everything off of the /sdcard. If it doesn't reboot every couple minutes, that could be of some use for backing up the /sdcard. Otherwise it will be impossible if your ROM reboots every 2 minutes.
Yes you can use fastboot to format the userdata partition. You can also use "mke2fs" as a shell command (that is, with adb) when the recovery is running.
TWRP 2.6.3.1
Code:
mke2fs
Usage: mke2fs [-c|-l filename] [-b block-size] [-f fragment-size]
[-i bytes-per-inode] [-I inode-size] [-J journal-options]
[-G meta group size] [-N number-of-inodes]
[-m reserved-blocks-percentage] [-o creator-os]
[-g blocks-per-group] [-L volume-label] [-M last-mounted-directory]
[-O feature[,...]] [-r fs-revision] [-E extended-option[,...]]
[-T fs-type] [-U UUID] [-jnqvFKSV] device [blocks-count]
.
If you use an ext2/3/4 filesystem formatter (e.g. mke2fs) running under the recovery, you need to be very very careful about specifying the exact partition name (e.g. /dev/block/mmcblk0p9 for GROUPER - data might be at a different partition number on a Tilapia device).
You can check by doing a
Code:
adb shell ls -l /dev/block/platform/sdhci-tegra.3/by-name/*
the userdata partition is "UDA".
BTW, before you go nuking your data partition, it might be useful to check to see if it is actually corrupted. For instance, with TWRP you can unmount all partitions, and then check using the program "e2fsck" :
Code:
C:\> adb shell
# e2fsck -f -n /dev/block/mmcblk0p9
the above command will perform a check (p9 = grouper /data partition) without attempting to make any repairs. You'll know if there are any problems: you will get page after page of error messages. If the filesytem is free of errors, you will only see 8-10 summary lines.

bftb0 said:
Normally user-level changes would be recorded in the /data partition, so if it got corrupted some way AND the OS mounts that filesystem with a errors=remount-ro then that would explain lack of persistence.
However, not every OS or recovery boot uses the same mount options. I'm looking at a CM boot right now and I don't see that
Code:
/dev/block/platform/sdhci-tegra.3/by-name/UDA /data ext4 rw,seclabel,nosuid,nodev,noatime,errors=panic,user_xattr,acl,barrier=1,nomblk_io_submit,data=ordered 0 0
But anyway, if you are going to reformat your "userdata" partition, try and rescue everything off of the tablet.
Is the recovery boot stable? If so, you might want to use "adb pull" to recursively pull everything off of the /sdcard. If it doesn't reboot every couple minutes, that could be of some use for backing up the /sdcard. Otherwise it will be impossible if your ROM reboots every 2 minutes.
Yes you can use fastboot to format the userdata partition. You can also use "mke2fs" as a shell command (that is, with adb) when the recovery is running.
TWRP 2.6.3.1
Code:
mke2fs
Usage: mke2fs [-c|-l filename] [-b block-size] [-f fragment-size]
[-i bytes-per-inode] [-I inode-size] [-J journal-options]
[-G meta group size] [-N number-of-inodes]
[-m reserved-blocks-percentage] [-o creator-os]
[-g blocks-per-group] [-L volume-label] [-M last-mounted-directory]
[-O feature[,...]] [-r fs-revision] [-E extended-option[,...]]
[-T fs-type] [-U UUID] [-jnqvFKSV] device [blocks-count]
.
If you use an ext2/3/4 filesystem formatter (e.g. mke2fs) running under the recovery, you need to be very very careful about specifying the exact partition name (e.g. /dev/block/mmcblk0p9 for GROUPER - data might be at a different partition number on a Tilapia device).
You can check by doing a
Code:
adb shell ls -l /dev/block/platform/sdhci-tegra.3/by-name/*
the userdata partition is "UDA".
BTW, before you go nuking your data partition, it might be useful to check to see if it is actually corrupted. For instance, with TWRP you can unmount all partitions, and then check using the program "e2fsck" :
Code:
C:\> adb shell
# e2fsck -f -n /dev/block/mmcblk0p9
the above command will perform a check (p9 = grouper /data partition) without attempting to make any repairs. You'll know if there are any problems: you will get page after page of error messages. If the filesytem is free of errors, you will only see 8-10 summary lines.
Click to expand...
Click to collapse
Ok before I start with all this i have to say a few things! The tablet now started rebooting even in recovery! and also since the first time it started rebooting I tried enabling usb debugging, but as I explained earlier after every reboot every change disappears, meaning usb debugging is not enabled when i enter the recovery! Will I be able to do anything at all with fastboot if the usb debugging is not enabled? If not do I have any other option?

Googsx said:
Ok before I start with all this i have to say a few things! The tablet now started rebooting even in recovery! and also since the first time it started rebooting I tried enabling usb debugging, but as I explained earlier after every reboot every change disappears, meaning usb debugging is not enabled when i enter the recovery! Will I be able to do anything at all with fastboot if the usb debugging is not enabled? If not do I have any other option?
Click to expand...
Click to collapse
The settings you (try to) apply when the ROM is running (eg the USB debugging toggle) do not affect the recovery. The entire point of a recovery is to have a standalone boot that doesn't depend on other partitions.
Having said that, the use of a "pseudo" SD card that is actually part of the userdata filesystem sometimes does cause problems for the recovery - it tries to mount /data to get you access to ROM files, nandroid backups, etc. I recall getting my N7 into a condition where TWRP's touch interface wouldn't come up because of problems with the userdata partition. But, adb was still available as was fastboot (in the bootloader mode). Also, I was not having spontaneous reboots.
The fact that you are observing spontaneous reboots in the recovery indicates that you might have Hypothesis A going on - flaky hardware. At a minimum however, it means you will not be able to run any long duration backups... for instance, trying to make a rescue backup of your SD card.
You could try and do
Code:
fastboot erase userdata
fastboot format userdata
with the tablet in bootloader mode. Obviously this step will destroy all of your data.
If your tablet is still spontaneously rebooting after that (in the recovery) then your only option will be to return it for repair (motherboard replacement).