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.
Related
I was on Offical leaked Taiwan version of ICS, then i decided to move to XXLPY version of ICS. I went to CMW to full wipe data, but for some reason, my note froze during data wiping...
I have waited long enough, but it was froze. With no choice, I removed the battery then tried to boot, but it was stuck on the first screen.
From then on, I have tried to recover my note using various Offical ROMs, the taiwan leak, German leak and even old GB ROMs, but I am stuck at Factoryfs...
I am pretty sure Ive tried everything, add PIT and not add PIT, Kernel, etc...
For some reason, Kernel can be flashed just fine, but when it comes to ROMs, it stucks at this screen.
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
Please, any help is appreciated
--------------------------------------------------------------------------
That was my situation 3 days ago, but i managed to get it back to life from this post by Forest1971:
http://forum.xda-developers.com/showpost.php?p=26285877&postcount=12
Thank you Forest1971 for this great guide
And the bricks resumes......
Send it back to samsung service center. Hope you have warranty.
Zapped through server hops to XDA forums
WTF!!!! who told you to wipe on LPF??? who told you not to read the PSA??
One more. We could actually make a movie about it now. :/
My commiserations man. Take it to Samsung.
Sent from my GT-N7000 using XDA
But I can't help saying that you are actually very brave. You could read about how to flash all this (assuming you did it yourself) but couldn't read about the possible risks. Every forum these days is about "bricked due to wipe" or "avoid wiping to avoid brick". I am not trying to give you a lecture or something and I really hope Samsung fixes it for free but please, next time search before you do anything potentially dangerous.
Sent from my GT-N7000 using XDA
musashiro said:
WTF!!!! who told you to wipe on LPF??? who told you not to read the PSA??
Click to expand...
Click to collapse
... ****
this one tole me to wipe so I did it ............ FML
Guess ill have to visit samsung store then
Glad I got the warrenty
sujal said:
But I can't help saying that you are actually very brave. You could read about how to flash all this (assuming you did it yourself) but couldn't read about the possible risks. Every forum these days is about "bricked due to wipe" or "avoid wiping to avoid brick". I am not trying to give you a lecture or something and I really hope Samsung fixes it for free but please, next time search before you do anything potentially dangerous.
Sent from my GT-N7000 using XDA
Click to expand...
Click to collapse
Thanks anyway, I am just glad that I still got the warrenty
uggies said:
Thanks anyway, I am just glad that I still got the warrenty
Click to expand...
Click to collapse
keep us updated!
Sent from my GT-N7000 using XDA
uggies said:
... ****
this one tole me to wipe so I did it ............ FML
Guess ill have to visit samsung store then
Glad I got the warrenty
View attachment 1069893
Click to expand...
Click to collapse
Albany didn't say you should full wipe in LPF. Read in between the lines of and sorry for the brick
Sent from my GT-N7000 using xda premium
So there is no way to recover once you wipe data?
currently the best way is to get it replaced by samsung
Guide for repartition workaround to fix super-brick Note
uggies said:
I was on Offical leaked Taiwan version of ICS, then i decided to move to XXLPY version of ICS. I went to CMW to full wipe data, but for some reason, my note froze during wiping data...
I have waited long enough, but it was stuck. With no choice, I removed the battery then tried to boot, but it was stuck on the first screen.
From then on, I have tried to recover my note using various Offical ROMs, the taiwan leak, German leak and even old GB ROM, but I am stuck at Factoryfs...
I am pretty sure Ive tried everything, put PIT and not put PIT, Kernel, etc...
For some reason, Kernel can be installed just fine, but when it comes to ROMs, it stucks at this screen.
View attachment 1069879
Please, any help is appreciated
Click to expand...
Click to collapse
There has been confirmation that In many cases it is the faulty system partitions (caused by wipe using the buggy ICS stock kernel or other reasons). In that case re-partition workaround will help revive your brick phone. The first one who has applied the method successfully is "Drnull" for another similar device (epic4g).
So for those who would like to use this solution follow the guide below which I developed based on the hints from Drnull and a re-partition guide for Kindle Fire by Eldarerathis and Soundwire.
Credits and thanks to them.
Big thanks to: Prabhu1980, Matiasg85, Uggies, Bodivas, As i9000, Alekhkhanna, Travis82 and others who have provided precious tools, troubleshoot solutions, advice and support for making this guide more complete and easy to use! Also Special thanks to Lyriquidperfection for his great PIT Magic and Hg42 for his custom PIT method!
------------------
I. Case Classification and solution when there is no recovery mode:
1. Case A. If you can enter recovery: then use scanning tool to find where the damage is. Should use hg42 scanners or use the procedures described in the manual method below (Go until steps 4 to find the answers). The scanning can guide you to find the most suitable strategy for re-partition. After scanning you can use the most suitable custom pit files from the set of custom pit files in hg42's thread or use the method in this guide or a combination of both in an intuitive way to revive your brick Note. .
2. Case B. If you only have download mod, no recovery: if you flash using odin and it gets stuck at factoryfs or datafs repeatedly and you have made wipe/factory reset using ICS stock kernel, then you certainly have emmc brick. You can try to flash some kernel attached in this guide to see if can enter recovery. IF yes, then go back to Case A. If not you can use a blind method using the custom pit files below. Try one by one. The one from 2.0 should work for you. If not then from 2.1 to 2.5, one of those should work.
2.0. Custom pit that works for most cases of emmc brick
2.1. Custom pit option 1
2.2. Custom pit option 2
2.3. Custom pit option 3
2.4. Custom pit option 4
2.5. Custom pit option 5
-----------------------------------
II. Manual re-partition
Notes for using Manual repartition:
1. For those who can get SS warranty service to fix it for free then you should go there, and do not need to try repartition.
2. know how to run command prompt (MS-DOS) from window.
3. Partitions can be delete and recreate like in a computer hdd and it is reversible: you can do and redo again and again and can also go back to original scheme by flashing original PIT file.
4. If you like to recover data from your internal sdcard (photos, music, books...) you should look at Item 9 near the end of the guide.
5. And do not try to hold me responsible if you mess things up further than your current state in your phone.
1. The tools:
- Download the screen shot of the Note’s partitions for your reference information
- Install USB driver: You should be able to have adb driver for Note. If not, then download Note usb driver from here.
- Prepare adb folder: download adb folder from Here and extract adb folder to c: driver of your computer, you will have the tools folder which has adb.exe in it. You should now have adb working for your Note.
- Install custom recovery so that you can get into recovery and connect adb.
+ if you have installed GB rom (as part of the unbrick process) then download and install the attached 4pda_kernel.tar from Here.
It will raise flash counter but you can reset later using Triangleaway by Chainfire.
+ If you were ICS rom: then download and flash Speemod kernel for ICS Here., using odin.
+ If you were on JB rom then download and flash Speedmod kernel for JB from Here.
2. Set up the tools:
- after flashing one of the suitable kernel from above you should now be able to enter recovery.
- Then restart the phone to recovery (Using three buttons).
- Then connect to computer using usb cable.
3. Then run cmd from your computer and cd (change directory) to the folder that has adb.exe in your computer.
Then run,
Code:
adb devices
it should give you some number then it means your device is connect in adb
then:
Code:
adb shell
it should give you the sign like this: ~ #
-------
Note: In case adb shell it only gives this sign $ (after you have installed the 4pda_kernel) then it showed there is a mismatch of that kernel with the rom that is sitting on your (semi-brick) Note and it does not give full root. In that case you should download and install this CM9 based safe kernel from this links which should help you to get full adb root access with this sign ~ #. It is a zip file and need to be install from CWM (not odin) by copy it to external sdcard or internal sdcard (by mount usb storage to PC or adb push.
-------
Then run (noted that umount is without N):
Code:
~ # umount /cache
~ # umount /system
~ # umount /data
If one of those "umount /" commands return "invalid argument" just ignore it and continue with next steps.
This is to unmount cache, systemfs and datafs partitions.
Note: it is easier to copy and paste (right click mouse) the code to CMD windown to save time and avoid typing error.
Then run the parted.
Code:
~ # parted /dev/block/mmcblk0
if it aska you to fix something just choose yes. It should give you bellow:
parted /dev/block/mmcblk0
GNU Parted 1.8.8.1.179-aef3
Using /dev/block/mmcblk0
Welcome to GNU Parted! Type 'help' to view a list of commands.
(parted)
Then run:
Code:
(parted) print
It will give you a picture of your Note’s partitions as in the screen shots I have attached. (text version is below):
print
print
Model: MMC VYL00M (sd/mmc)
Disk /dev/block/mmcblk0: 15.8GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Number Start End Size File system Name Flags
1 4194kB 25.2MB 21.0MB ext4 EFS
2 25.2MB 26.5MB 1311kB SBL1
3 27.3MB 28.6MB 1311kB SBL2
4 29.4MB 37.7MB 8389kB PARAM
5 37.7MB 46.1MB 8389kB KERNEL
6 46.1MB 54.5MB 8389kB RECOVERY
7 54.5MB 264MB 210MB ext4 CACHE
8 264MB 281MB 16.8MB MODEM
9 281MB 1174MB 893MB ext4 FACTORYFS
10 1174MB 3322MB 2147MB ext4 DATAFS
11 3322MB 15.2GB 11.9GB fat32 UMS
12 15.2GB 15.8GB 537MB ext4 HIDDEN
--------------------
4. Scanning for Partition errors:
4.1. Use DD:
Do to a thorough scan of partitions (block damage) you can use DD command below one by one (it only read partition block by block and no write, so it is totally safe).
Damage is mostly found in partition 7, 9, 10, 11. You can use dd to check other partition from 1 to 6 as well.
Code:
(parted) quit
~ # dd if=/dev/block/mmcblk0p7 of=/dev/null
~ # dd if=/dev/block/mmcblk0p9 of=/dev/null
~ # dd if=/dev/block/mmcblk0p10 of=/dev/null
~ # dd if=/dev/block/mmcblk0p11 of=/dev/null
Scan partition 7 and 9 will be quick (less than a minute) partition 10 take about 3 minutes and 11 about 5-7 minutes.
- If it return in and outs and partition size then they are fine (no faulty blocks)
- If it freezes (or run too long more than 10 minutes), or return something like "read/write I/O error" then it means you have some damage in that respective partition and read command failed. In this case should restart CMD/adb and run the test again for the partition that give I/O error to make sure the error is permanent and result of test is reliable.
4.2. There is also anther scan tool to double check if there are partitions faults: that is e2fsck. It comes with 4_pda and CM9 kernel given. The added benefit is that it can also repair minor memory block damage.
This tool can only be used for ext4 partition (7, 9,10) and it need to be used after "umount /cache"... steps in point 3. It is suggested that before attempting with re-partition you should first try to use this tool to scan and fix the damaged block. The command is below:
Code:
~ # e2fsck -f -c –y /dev/block/mmcblk0p7
~ # e2fsck -f -c –y /dev/block/mmcblk0p9
~ # e2fsck -f -c –y /dev/block/mmcblk0p10
The results of e2fsck scanning can be as below:
- If there is no faulty block e2fsck will report: "no bad block found". then good!
- If it freezes then it has encountered emmc bug damaged and cannot fix: In this case will definitely need re-partition.
- If it report encountered some damaged block and has fixed the damage: In this case you can try to go back to install rom. If it work, that is great. If still get stuck as before then you will need to do re-partition.
Guide for the most suitable re-partition scheme after scanning partitions (read carefully for the best result):
1. In case you do not find bad blocks in the above 4 partitions, the problem is certainly not related to partitions fault. Then you should explore other unbrick methods, using Heimdall to flash instead of odin for example.
2. In case there are fault in both partition 9 and 10 then follow steps in point from 5.1 to 5.3 below. applying this scheme of re-partition should work in most cases!.
3. In case there are faulty in partition 9 only, then can follow steps in point 7 to save some more space.
4. In case there are faulty in partition 10 only, then can follow steps in point 7 to save some more space.
5. In case there are faulty blocks in Cache partition, then follow point 5.4
6. In case there are faulty in partition 11: go to point 8 .
---------------------
5. Re-partition workaround for case of faulty in partitions 9 and 10::
5.1 remove partitions to get rid of the faulty ones and make space available for new ones:
Code:
~ # parted /dev/block/mmcblk0
(parted) print
(parted) rm 9
(parted) rm 10
(parted) rm 11
That will remove three partitions factoryfs (9), datafs (10) and UMS (11) so as to make rooms for new partitions
5.2. To create three new partitions from the good area:
Code:
(parted) mkpart primary 3322.881536 4216.268288
(parted) mkpart primary 4217 6364
(parted) mkpartfs primary fat32 6364 15200
(parted) name 9 FACTORYFS
(parted) name 10 DATAFS
(parted) name 11 UMS
Notes: You can also use custom pit provided in 2.0 to re-partition in this case.
-------------
5.3. Convert format for 9 and 10: The above steps have created three new partitions. However, for 9 and 10 the format is ext2 and now need to be converted to ext4.
The easiest way is to go back to CWM in your phone. Then, go into mounts and storage menu and choose format /system and format /data. It will convert file system of partition 9 and 10 to ext4 automatically for you.
If the above steps are successful then check:
Code:
~ # parted /dev/block/mmcblk0
(parted) print
Note: after printed partition and they look fine, then should check again the partition using dd command to scan partitions 9, 10, 11 as in the step 4 to make sure that newly created partition are fault-free. If they continue to report faulty block then you will need to do re-partition again and create new partitions in the new range (by changing start and end number of partitions).
------------
Dealing with Cache partition:
5.4. It is very, very unlikely that Cache is also faulty but in case there is you can follow steps below to deal with it.
First should remove and recreate with same size and location:
Code:
(parted) rm 7
Then recreate it:
Code:
(parted) mkpartfs primary ext2 54.5 264
(parted) name 7 CACHE
Then you can go into CWM and format /cache, it will convert file system to ext4.
In case parted give I/O error then you can try to reduce the size of cache to 128MB, choose the start and end number somewhere in the space from 54.5MB to 264MB.
6. Suggestions for rom installations:
It is recommend to use a custom GB rom (Darky GB, CheckRom GB, and Rocket GB...)they are old but very good roms. Dowload links and instructions for installation can be found in this link. Custom ICS roms (such as Rocket ICS, CleaNote ICS...) are also good. They can be found from the same link for GB rom provided or from the Note development sections. Using CM9 ICS such as Nightlies is recommended since it is safe and very lightweight (less than 140 MB) so it is quick to download.
Note: Flash custom rom by CWM (load rom.zip from computer to internal or external sdcard and flash) seem to be a better way than using odin and is recommended but you can try both.
7. Guide for some cases of only one partition have faulty blocks:
7.1. In case you scan partition and identify that there are damage only in partition 9 (factoryfs) then you can remove 9, 10, and 11 and then start making partition from 1174 MB:
Code:
(parted) rm 9
(parted) rm 10
(parted) rm 11
(parted) mkpart primary 1174.405120 2067.791872
(parted) mkpart primary 2068 4215
(parted) mkpartfs primary fat32 4215 15200
(parted) name 9 FACTORYFS
(parted) name 10 DATAFS
(parted) name 11 UMS
Then go into CWM to format system and data. Then you can install rom.
7.2. In case you identify that there is faulty blocks in partition 10 only (datafs) then you can remove 10 and 11 only (leave 9 alone) and start making partition 10 from 3322 mb:
Code:
(parted) rm 10
(parted) rm 11
(parted) mkpart primary 3322 5469
(parted) mkpartfs primary fat32 5469 15200
(parted) name 10 DATAFS
(parted) name 11 UMS
Then go into CWM and format data. and you can install rom.
It is also known that the hidden partition (partition 12) is not needed for normal use and install of roms. So you can delete it and enlarge the UMS partition (to 15800mb) and you will have a larger sdcard to use.
It is also noted that the size of datafs partition does not need to be exact 2147 mb so you can create it with the size of 2000 mb or smaller or bigger as you wish.
Still the size of factoryfs partition has to be correct so that odin will accept it when flash.
8. In the case of damage in partition 11 (UMS) this often also go with damage in partition 9 and 10. In this case I have worked out 5 options of partition scheme. You need to try from one to 5. One of those should work for you.
You can also use one of the custom Pit files provided at 2.1 to 2.5 above.
Option 1:
Code:
~ # parted /dev/block/mmcblk0
(parted) print
(parted) rm 9
(parted) rm 10
(parted) rm 11
(parted) mkpart primary 4608 5501.386752
(parted) mkpart primary 5501.386752 7648.8704
(parted) mkpartfs primary fat32 7648.8704 15200
(parted) name 9 FACTORYFS
(parted) name 10 DATAFS
(parted) name 11 UMS
After done, reboot into recovery format system, format data. Then you can proceed with install stock or custom rom.
If it get errors when create partition or CWM get stuck during format then you need to try the next option of partition scheme as below.
Option 2:
Code:
(parted) mkpart primary 6400 7293.386752
(parted) mkpart primary 7293.386752 9440.8704
(parted) mkpartfs primary fat32 9440.8704 15200
Option 3:
Code:
(parted) mkpart primary 7936 8829.386752
(parted) mkpart primary 8829.386752 10976.8704
(parted) mkpartfs primary fat32 10976.8704 15200
Option 4:
Code:
(parted) mkpart primary 9216 10109.386752
(parted) mkpart primary 10109.386752 12256.8704
(parted) mkpartfs primary fat32 12256.8704 15200
Option 5:
Code:
(parted) mkpart primary 11,008 11901.386752
(parted) mkpart primary 11901.386752 14048.8704
(parted) mkpartfs primary fat32 14048.8704 15200
9. Notes on recovering files from brick phone: For recovering data from internal sdcard, there are few ways below:
- You can try to install aroma file manager under CWM recovery using file from here. It works under recovery environment and allow you to copy files from internal sdcard to external sdcard.
- If that does not work, you can follow the guide until step 4, then in step 5 remove only partition 9 and 10 and leave partition 11 alone. Then try to create a full size partition 9 (factoryfs) with about 800MB and a very small size (100mb) partition 10 (datafs) and fit these two partitions within the remaining good area in the range from 281mb to 3322mb. Then you can install a custom rom and get it working to copy files to your PC. After that you can remove partition 11 to make full size partition 9 and 10 with steps as in the guide.
- Also you can adb shell, then list directory and files in internal sdcard (~ # ls /sdcard ...etc) and then adb pull files from internal sdcard to your PC one by one.
If you like to know more about using parted, go to the documentation page here:
http://www.gnu.org/software/parted/manual/html_mono/parted.html
Update of progress: As rough figures, more than 100 users have reported successfully revised their Notes after fixing partitions problems using either manual/adb methods or custom PIT file method from Hg42 or combined both. Re-partition have revised many super-bricks Notes! .
If you can revive your Note please share your success with us so that we can share your good feeling !
And press thanks if you find this guide useful. Thanks.
forest1971 said:
There has been confirmation that relocating the corrupted partition to the good areas works. Read the posts by "drnull" from post 331 in the thread under epic4g group.
http://forum.xda-developers.com/show...504808&page=34
So for those who would like to use this solution follow the guide below which I developed based on the guide for another android device by eldarerathis and soundwire.
http://forum.xda-developers.com/showthread.php?t=1388996
All credits go to them
1. The tools:
- Download the screen shot of the Note’s partitions for your reference information
- Download the zip file attached (it has parted partition manager and other format conversion tool), extract it and copy all files) to adb folder
2. Get into recovery (CMW)
3. connect to computer using usb cable.
4. Then run cmd and cd to the adb folder of your computer
Then run following commands.
adb devices
it should give you some number then it means your device is connect in adb
then run:
.
.
.
.
For documentation of parted go here:
http://www.gnu.org/software/parted/manual/html_mono/parted.html
Let me know if you have difficulties doing the procedures.
And press thanks if it helps.
Click to expand...
Click to collapse
Thank you very much for your help, but is there anyway to install CWM on a bricked device?
You need to flash a custome gb kernel that has cwm via odin
forest1971 said:
You need to flash a custome gb kernel that has cwm via odin
Click to expand...
Click to collapse
Alrighty Thanks mate. Will have a go tomorrow and report back
Sent from my HTC Incredible S using XDA
Abyssnote kernel seems to be a good one and it has cwm included. Good luck!
and please remember to post also screen shots of the results. Thanks
uggies said:
I was on Offical leaked Taiwan version of ICS, then i decided to move to XXLPY version of ICS. I went to CMW to full wipe data, but for some reason, my note froze during wiping data...
I have waited long enough, but it was stuck. With no choice, I removed the battery then tried to boot, but it was stuck on the first screen.
From then on, I have tried to recover my note using various Offical ROMs, the taiwan leak, German leak and even old GB ROM, but I am stuck at Factoryfs...
I am pretty sure Ive tried everything, put PIT and not put PIT, Kernel, etc...
For some reason, Kernel can be installed just fine, but when it comes to ROMs, it stucks at this screen.
View attachment 1069879
Please, any help is appreciated
Click to expand...
Click to collapse
wait if you can still flash a kernel then flash a GB cf root kernel then boot into CWM recovery and try to flash a nandroid restore (you have one right) ? if you don't have one then just flash any safe ROM (GB ,CM9) from CWM.
I had the same problem when LPY first hit the scene (first day ,even before it was deemed dangerous) ,and also bricked my note but could enter download and recovery just fine (only couldn't boot or flash anything else) I kept rebooting and trying to flash again again till it worked after some dozen reboots .
hopefully you can do the same.
And what do if you can't get into recovery, or CWM?
Just first boot screen stuck, or Download mode, but factoryfs stuck also?
Shadow69 said:
And what do if you can't get into recovery, or CWM?
Just first boot screen stuck, or Download mode, but factoryfs stuck also?
Click to expand...
Click to collapse
Yeah I am stuck at the first screen too..
When I unzipped AbyssNote kernel 4.2 Final CW Touch Custom Logo, it was zlmage, not .tar file extension. Tried putting .tar at the end, still no luck.
I also tried CF-ROOT 5.3V, it was successfully flashed but again I was stuck at the first screen with yellow triangle at the bottom.
Am I trying out wrong kernels?
EDIT: I managed to find .tar file of Abyss kernel and flashing was successful, still cannot get into recovery ... seems pretty hopeless now
Shadow69 said:
And what do if you can't get into recovery, or CWM?
Just first boot screen stuck, or Download mode, but factoryfs stuck also?
Click to expand...
Click to collapse
Go to the nearest service center.
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....
I have a complete setup for the Nexus 7, part of a product we are working on, that I need to easily clone on "virgin" tablets for production. The app requires a rooted OS.
I want to write an installation script using fastboot to unlock the bootloader, erase partitions, then flash them with .img files for each partition (kernel, system, cache, etc.).
How do I extract .img files from my "master" tablet? I have an understanding from some where that these are simple byte-for-byte dumps of the partition -- is this true? As such can I create a .img file by simple doing 'cat blkfile >file.img' where "blkfile" is the appropriate block device for the partition in question?
Or do I need to use 'dd'? Or something else?
I have searched and searched, and can't find an anwer. I've found other answers using some tools to create these files from a build on a PC, but nothing about creating them from an existing tablet.
Thanks in advance!
Use the dd command. You can use it both to dump and write a partition. It's how I install recovery programs like TWRP
Sent from my Nexus 7
You can use dd for the boot partition and recovery partition - they are raw binary blobs. (Don't use dd on other Android devices, esp. those that have MTD flash devices, though - it only works most of the time there)
If you want to use the same fastboot-based scenario that Google uses for factory image sets, then for the system & userdata image files you will need to find out about "sparse ext4 filesystem images"
If you took a raw block-device based dump of any of your tablet ext4 partitions, you could actually take those image files and mount them on any other linux machine (using a loopback mount procedure).
But you will find that if you attempt to do that with the Google factory ".img" files (for system & userdata partitions), they will not mount. It's not a simple matter of a offset superblock, either.
Since these are the formats that the stock recovery expects, I suppose you ought to use those formats if you want to do the "all at once all partitions" fastboot flashing if you plan on using the stock recovery.
Note that there is absolutely nothing that prevents you from unpacking whatever you want from whatever archive format you want - so long as the recovery's busybox supports the archive format correctly - you could use cpio or pax or tar archives for that matter. (The stock recovery's "toolbox" has very little functionality, so this comment applies to custom recoveries, which typically have more robust functionality in their busybox) You will be writing your own scripts to do those things though, typically either in one of two ways:
1.A mount target filesystem partition
1.B do a deep recursive remove at that mountpoint ( rm -rf * )
1.C unpack your archive into same mount point ( tar xf archive.tar, etc)
1.D unmount the mount point
OR
2.A unmount target partition and zero it out (dd if=/dev/zero, flash_erase, etc)
2.B recreate filesystem in partition (mke2fs -t ext4 etc)
2.C mount target filesystem
2.D unpack your archive into the same mount point (tar xf archive, pax, cpio, unyaffs2, etc)
2.E unmount that mountpoint
Even though this post is for the Samsung Galaxy S II, the same thing applies to the factory Nexus 7 images from Google:
http://forum.xda-developers.com/showthread.php?t=1081239
As that thread mentions, the simg2img and mkuserimg.sh programs are part of the Android project.
Here's a Nexus 7 thread where the contributor built the tools for both x86 linux and arm linux
Finally, I should note that because /system is typically mounted read-only, imaging /system from the live OS is no big deal. Trying to do the same thing with /data is an extremely dopey idea, however. Accurate backups are rarely made from live read-write filesystems.
cheers
Thank you so much for all the great information! I hit thanks for both of you.
The link to the nexus 7 thread is what I need... This is for my company, and I need a simple cloning solution that can be performed by a non-technical assembly person. The fastboot install procedure is about as simple as it gets.
Thanks again!
Hi everyone, this is my first thread
I recently rooted my 16gb WiFi only nexus 7. After installing 3 different roms (touchwiz, cyanogenmod 10, and xenon HD) I didn't like touch wiz or cyanogenmod, and I'm currently running xenon HD. However, when I opened my storage today, of said I had 3.6gb remaining. I thought it may have been all the apps, so I factory reset it, reset the partition, and deleted all data via recovery mode. That gave me about 1 more gigabyte. I opened ES file explorer and deleted everything there. I still have only 4.6 gigabytes usable. Anyone else have this issue?
Thanks
Sent from my Nexus 7 using xda app-developers app
Well, I deleted some old backups and now I have 7.5 gb of storage, which should do for now. But I still have that 6 GB leftover, anyone know whats wrong?
Thanks
Sent from my Nexus 7 using xda app-developers app
OK. Now I mucked around in the mounting/unmounting stuff, and now it won't boot. It's stuck at the Google screen. Someone help please???
Sent from my Nexus 7 using xda app-developers app[/QUOTE]
You are not the only person who has experienced this.
Bottom line is you need to rebuild the /data filesystem, which necessitates getting everything off of it including any nandroid backups plus anything worth saving in /sdcard
Either the "format data" option in TWRP, or using fastboot.
Code:
fastboot erase userdata
fastboot format userdata
I've had the latter create short file systems - and also not create short file systems.
Whatever causes this it seems to depend on prior state in the filesystem, even though I don't think things should behave this way. I've also had TWRP's "Format data" menu option create new, empty, & corrupted ext4 file systems. Ugh - I hope your luck is better than mine.
Note that you can run "df -k /data" in the recovery (after you have created the new filesystem by either method) to find out how big it is; better to check things are OK right away, rather than after you've put effort into restoring things or flashing ROMs.
Long boring thread, but related.
http://forum.xda-developers.com/showthread.php?t=2184486
good luck
Edit: no point in restoring the wedged /data backup. I hope you have earlier backups.
bftb0 said:
You are not the only person who has experienced this.
Bottom line is you need to rebuild the /data filesystem, which necessitates getting everything off of it including any nandroid backups plus anything worth saving in /sdcard
Either the "format data" option in TWRP, or using fastboot.
Code:
fastboot erase userdata
fastboot format userdata
I've had the latter create short file systems - and also not create short file systems.
Whatever causes this it seems to depend on prior state in the filesystem, even though I don't think things should behave this way. I've also had TWRP's "Format data" menu option create new, empty, & corrupted ext4 file systems. Ugh - I hope your luck is better than mine.
Note that you can run "df -k /data" in the recovery (after you have created the new filesystem by either method) to find out how big it is; better to check things are OK right away, rather than after you've put effort into restoring things or flashing ROMs.
Long boring thread, but related.
http://forum.xda-developers.com/showthread.php?t=2184486
good luck
Edit: no point in restoring the wedged /data backup. I hope you have earlier backups.
Click to expand...
Click to collapse
I basically have nothing I need on my tablet, so I'm fine deleting everything on it, if that's what you mean. I'll try, but thanks:good:
nicetaco said:
I basically have nothing I need on my tablet, so I'm fine deleting everything on it, if that's what you mean. I'll try, but thanks:good:
Click to expand...
Click to collapse
Wait, is that for getting back the storage or actually letting it boot up? Because right now the storage is the least of my concerns.
What I described is for getting back lost space (by recreating from scratch the ext4 filesystem in the userdata partition).
As it doesn't touch either the boot partition or the system partition, your tablet should certainly be able to boot. If you don't do a restore of /data from a backup, the result will be like a factory reset of whatever rom you had on the tablet.
Just make sure to check the size of the data partition before you start re-customizing or restoring data from backups to make sure that you got the full size of the partition.
bftb0 said:
What I described is for getting back lost space (by recreating from scratch the ext4 filesystem in the userdata partition).
As it doesn't touch either the boot partition or the system partition, your tablet should certainly be able to boot. If you don't do a restore of /data from a backup, the result will be like a factory reset of whatever rom you had on the tablet.
Just make sure to check the size of the data partition before you start re-customizing or restoring data from backups to make sure that you got the full size of the partition.
Click to expand...
Click to collapse
Ughhh its still not turning on...
nicetaco said:
Ughhh its still not turning on...
Click to expand...
Click to collapse
Please re-read this quote from your 2nd thread in this fiasco.
Nico_60 said:
How do you want to know what's happening to your device if don't tell us which commands you have done exactly with fastboot and why ?
Click to expand...
Click to collapse
If you screwed around with your system partition and it wouldn't boot before, then with a freshly formated and empty /data filesystem, of course it still will not boot. The instructions I provided in this thread only involved the userdata partition!
But you didn't say "I did such and such and it still hangs during the initial boot phase where the X logo is flashing on the screen"; instead you said:
"Ughhh its still not turning on".
WTF? Has your problem now morphed into a dead battery problem, or is the language you are using just incredibly imprecise?
Anyway, Flash a new ROM using the custom recovery. Any ROM - you pick. Maybe not that Xenon ROM or whatever it is called. See if the new ROM boots. And then immediately after it boots, check to see what size the /data partition is.
And if you come back into this thread anymore please be specific about what you are attempting and exactly what symptoms you are observing.
good luck
bftb0 said:
Please re-read this quote from your 2nd thread in this fiasco.
If you screwed around with your system partition and it wouldn't boot before, then with a freshly formated and empty /data filesystem, of course it still will not boot. The instructions I provided in this thread only involved the userdata partition!
But you didn't say "I did such and such and it still hangs during the initial boot phase where the X logo is flashing on the screen"; instead you said:
"Ughhh its still not turning on".
WTF? Has your problem now morphed into a dead battery problem, or is the language you are using just incredibly imprecise?
Anyway, Flash a new ROM using the custom recovery. Any ROM - you pick. Maybe not that Xenon ROM or whatever it is called. See if the new ROM boots. And then immediately after it boots, check to see what size the /data partition is.
And if you come back into this thread anymore please be specific about what you are attempting and exactly what symptoms you are observing.
good luck
Click to expand...
Click to collapse
OK. I tried to install a new rom, but I can't because I have USB debugging off, which I can't turn on
bftb0 said:
You are not the only person who has experienced this.
Bottom line is you need to rebuild the /data filesystem, which necessitates getting everything off of it including any nandroid backups plus anything worth saving in /sdcard
Either the "format data" option in TWRP, or using fastboot.
Code:
fastboot erase userdata
fastboot format userdata
I've had the latter create short file systems - and also not create short file systems.
Whatever causes this it seems to depend on prior state in the filesystem, even though I don't think things should behave this way. I've also had TWRP's "Format data" menu option create new, empty, & corrupted ext4 file systems. Ugh - I hope your luck is better than mine.
Note that you can run "df -k /data" in the recovery (after you have created the new filesystem by either method) to find out how big it is; better to check things are OK right away, rather than after you've put effort into restoring things or flashing ROMs.
Long boring thread, but related.
http://forum.xda-developers.com/showthread.php?t=2184486
good luck
Edit: no point in restoring the wedged /data backup. I hope you have earlier backups.
Click to expand...
Click to collapse
Thank you, bftb0!
I was looking around for this after I discovered my lack of space. I read about it before, but couldn't dig up the post. Thanks for informing us! Enjoy the thanks!
nicetaco said:
OK. I tried to install a new rom, but I can't because I have USB debugging off, which I can't turn on
Click to expand...
Click to collapse
ADB is available in the custom recovery... so long as you have the right drivers installed on your PC. And that is NOT controlled by some setting in the most recent ROM that you flashed - it is always running in the custom recovery.
One of the quirks about ADB in the recovery with the Nexus7 is that it claims a different USB address than "ADB Composite Interface" that the regular OS does. This might mean that ADB works correctly with the regular OS booted, but not when the custom recovery is booted, depending on what drivers you have installed. Yes, you need yet another driver installed even though they are both "ADB" connections. But that is a Windows driver issue, not a problem with the N7.
You can also use an OTG cable and a USB drive with TWRP if that is easier. Put your ROM on the memory stick and then use TWRP's "external memory". To be most compatible, make sure the USB stick is formatted in a FAT format. (I don't know if TWRP can handle NTFS).
upichie said:
Thank you, bftb0!
I was looking around for this after I discovered my lack of space. I read about it before, but couldn't dig up the post. Thanks for informing us! Enjoy the thanks!
Click to expand...
Click to collapse
I wonder if I can I trade them in for some coupons or something
@bftb0, I was not able to use adb while in TWRP but i found THIS and it was the solution, what do you think about this "fix"?
bftb0 said:
ADB is available in the custom recovery... so long as you have the right drivers installed on your PC. And that is NOT controlled by some setting in the most recent ROM that you flashed - it is always running in the custom recovery.
One of the quirks about ADB in the recovery with the Nexus7 is that it claims a different USB address than "ADB Composite Interface" that the regular OS does. This might mean that ADB works correctly with the regular OS booted, but not when the custom recovery is booted, depending on what drivers you have installed. Yes, you need yet another driver installed even though they are both "ADB" connections. But that is a Windows driver issue, not a problem with the N7.
You can also use an OTG cable and a USB drive with TWRP if that is easier. Put your ROM on the memory stick and then use TWRP's "external memory". To be most compatible, make sure the USB stick is formatted in a FAT format. (I don't know if TWRP can handle NTFS).
I wonder if I can I trade them in for some coupons or something
Click to expand...
Click to collapse
Holy crap I forgot about the OTG cables. Thanks, I'll try it!
nicetaco said:
Holy crap I forgot about the OTG cables. Thanks, I'll try it!
Click to expand...
Click to collapse
Thank you so much. That did it.
First problem fixed through XDA developers
Enjoy my thanks
Nico_60 said:
@bftb0, I was not able to use adb while in TWRP but i found THIS and it was the solution, what do you think about this "fix"?
Click to expand...
Click to collapse
The ADB daemon - "adbd" is definitely sitting there running inside the custom recovery. Even if you can't communicate with it because of a lack of a driver, you should nevertheless be able to see it as an unknown device in the PC's device manager.
I have done the same hack - hand editing the .INF file - with both the Google SDK drivers and the Asus drivers, and in both cases it worked fine (one driver for everything: ADB in the OS, ADB in TWRP/CWM, and fastboot with the bootloader).
I have also used the Google SDK driver without modification plus the XDA Universal Naked driver. That means using the Google driver for fastboot and ADB when the OS is booted, and the XUN driver for custom recoveries only.
At the present time the ONLY driver I have installed is a hacked version of the Asus drivers.
Win 7 complains about signing when doing this (for the Asus drivers for sure, I can't remember if the Google driver is signed or not).
As I mentioned, Win 7 Pro x64. I suppose the whole "violated signing" might make life even more difficult with Win 8 though.
bftb0, did you personally experience the problem of losing space on the internal memory? I tried your advice, but it didn't work. I'm on PAC(man) ROM. I booted into TWRP, did the data wipe (not factory reset, the full wipe that wipes the everything) but I still only have 13 gb available (on my 32 gb Nexus 7). I rebooted into TWRP and did a factory reset AND wipe data, but I am still missing half of my internal memory.
Do you need to do this on the stock ROM for it to work? Any other tips would be greatly appreciated.
upichie said:
bftb0, did you personally experience the problem of losing space on the internal memory? I tried your advice, but it didn't work. I'm on PAC(man) ROM. I booted into TWRP, did the data wipe (not factory reset, the full wipe that wipes the everything) but I still only have 13 gb available (on my 32 gb Nexus 7). I rebooted into TWRP and did a factory reset AND wipe data, but I am still missing half of my internal memory.
Do you need to do this on the stock ROM for it to work? Any other tips would be greatly appreciated.
Click to expand...
Click to collapse
Yes, it really did happen to me.
After it happened I took the trouble to download 4 different versions of TWRP (2.4.1.0-2.4.4.0), and I re-created the ext4 filesystem with:
- each of the different versions of TWRP and
- fastboot format userdata
after each, I did a "e2fsck -f -n <block-device>" on the (unmounted) userdata partition to see that they were clean, and I also dumped the output of "tune2fs -l <block-device>" to a file for comparison. Other than things that I would expect to be different (e.g. partition UUID identifier strings and timestamps), I noticed no differences. And also, I couldn't reproduce the problem for the life of me.
Above you mention full "data wipe". In TWRP (v2.4.1.0), this is presented as a separate button in the "Wipe" sub-menu where it (the last button in the first column) is labeled "Format Data". I suppose this is what you mean, but thought I would be explicit to avoid any confusion. (The "factory reset" procedure in the two custom recoveries - both CWM and TWRP - can not possibly re-create the ext4 filesystem in /data, as the /data/media/0 SD card files are in there. But the "Format Data" button does destroy & recreate the whole filesystem).
If you press on this button and at the same time capture the output of the "ps" command, you will see that TWRP recovery invokes the /sbin/make_ext4fs in the following way
Code:
make_ext4fs -l -32768 /dev/block/mmcblk0p<PARTNUM>
(CWM probably uses a different external command as it does not seem to have a "make_ext4fs" command in it's ramdisk. Probably mke2fs with ext4 options on the command line)
Anyways, I can't say I have my finger on exactly how to resolve the problem as I can not re-created it. But it did happen to me.
One thing you can try rather than using TWRP's "make_ext4fs" command (underneath that button "Format Data") is to reboot into the bootloader from TWRP, and do the file system formatting in fastboot instead of TWRP, as in:
Code:
fastboot format userdata
(noobs: caution, this is a full userdata wipe)
and then bop back into the recovery and check things with "tune2fs" report
Code:
tune2fs -l /dev/block/mmcblk0p<PARTNUM>
My 32G N7 shows a total block count of 7503608 (x 4k/block = 29.3 GiB) doing this.
As I mentioned before, it's a good idea to check to see you have the right size before you start restoring stuff to avoid wasting time. You can do it above with "tune2fs -l", or because TWRP seems to want to mount /data and /sdcard when it boots, just run
adb shell df -k /data
to get a report of total and used size.
Sorry this isn't more definiitve. I would have spent more time looking at this, but it is tedious as you need to unload the whole d*mn SD card in order to experiment. Thank goodness my 30GB partition only has about 10Gigs of stuff on it.
good luck
bftb0 said:
Yes, it really did happen to me.
After it happened I took the trouble to download 4 different versions of TWRP (2.4.1.0-2.4.4.0), and I re-created the ext4 filesystem with:
- each of the different versions of TWRP and
- fastboot format userdata
after each, I did a "e2fsck -f -n <block-device>" on the (unmounted) userdata partition to see that they were clean, and I also dumped the output of "tune2fs -l <block-device>" to a file for comparison. Other than things that I would expect to be different (e.g. partition UUID identifier strings and timestamps), I noticed no differences. And also, I couldn't reproduce the problem for the life of me.
Above you mention full "data wipe". In TWRP (v2.4.1.0), this is presented as a separate button in the "Wipe" sub-menu where it (the last button in the first column) is labeled "Format Data". I suppose this is what you mean, but thought I would be explicit to avoid any confusion. (The "factory reset" procedure in the two custom recoveries - both CWM and TWRP - can not possibly re-create the ext4 filesystem in /data, as the /data/media/0 SD card files are in there. But the "Format Data" button does destroy & recreate the whole filesystem).
If you press on this button and at the same time capture the output of the "ps" command, you will see that TWRP recovery invokes the /sbin/make_ext4fs in the following way
Code:
make_ext4fs -l -32768 /dev/block/mmcblk0p<PARTNUM>
(CWM probably uses a different external command as it does not seem to have a "make_ext4fs" command in it's ramdisk. Probably mke2fs with ext4 options on the command line)
Anyways, I can't say I have my finger on exactly how to resolve the problem as I can not re-created it. But it did happen to me.
One thing you can try rather than using TWRP's "make_ext4fs" command (underneath that button "Format Data") is to reboot into the bootloader from TWRP, and do the file system formatting in fastboot instead of TWRP, as in:
Code:
fastboot format userdata
(noobs: caution, this is a full userdata wipe)
and then bop back into the recovery and check things with "tune2fs" report
Code:
tune2fs -l /dev/block/mmcblk0p<PARTNUM>
My 32G N7 shows a total block count of 7503608 (x 4k/block = 29.3 GiB) doing this.
As I mentioned before, it's a good idea to check to see you have the right size before you start restoring stuff to avoid wasting time. You can do it above with "tune2fs -l", or because TWRP seems to want to mount /data and /sdcard when it boots, just run
adb shell df -k /data
to get a report of total and used size.
Sorry this isn't more definiitve. I would have spent more time looking at this, but it is tedious as you need to unload the whole d*mn SD card in order to experiment. Thank goodness my 30GB partition only has about 10Gigs of stuff on it.
good luck
Click to expand...
Click to collapse
.
I'm a total command prompt beginner here, so could you explain where I'm doing the fastboot format command? In a terminal on the device? Using adb on my windows machine? I tried all that I could think of, but none of it worked. No form of wiping the device (yes, via "format data" in TWRP) seems to work. I'm still missing half of my storage.
EDIT: Okay, so I ran the command--I had to have the device in the bootloader, duh. Unfortunately, it still did not work. When recreating the file system, it said there was a total of ~3.5 million blocks--half what I saw reported in the other thread. Not surprising, since I'm missing half of my storage. How come this is working for other people but not me? I tried doing both at the same time, but to no avail. This is getting stupid.
upichie said:
EDIT: Okay, so I ran the command--I had to have the device in the bootloader, duh. Unfortunately, it still did not work. When recreating the file system, it said there was a total of ~3.5 million blocks--half what I saw reported in the other thread. Not surprising, since I'm missing half of my storage. How come this is working for other people but not me? I tried doing both at the same time, but to no avail. This is getting stupid.
Click to expand...
Click to collapse
Arrgh. Did you do the "fastboot erase userdata" first?
Here's what the fastboot format looked like on my device when I did this last (3/13):
Code:
$ fastboot erase userdata
******** Did you mean to fastboot format this partition?
erasing 'userdata'...
OKAY [ 4.974s]
finished. total time: 4.979s
$ fastboot format userdata
erasing 'userdata'...
OKAY [ 4.454s]
formatting 'userdata' partition...
Creating filesystem with parameters:
Size: 30734811136
Block size: 4096
Blocks per group: 32768
Inodes per group: 8192
Inode size: 256
Journal blocks: 32768
Label:
Blocks: 7503616
Block groups: 229
Reserved block group size: 1024
Created filesystem with 11/1875968 inodes and 161774/7503616 blocks
sending 'userdata' (139197 KB)...
writing 'userdata'...
OKAY [ 33.733s]
finished. total time: 38.194s
As I said, I was unable to reproduce the problem even though I tried. But it almost seems like the creation of the new filesystem is inferring something from somewhere (but where?) about the userdata partition size which is incorrect. Almost like it happens because of something it sees in the prior filesystem (which is being destroyed). So it becomes irreproducible unless you can recreate the same starting condition.
There's other mysterious crap going on here too. See the output above? The part where it says "sending 'userdata' (139197 KB)" ? It will say this no matter where you run the command from, and there is no 139 MB "userdata.img" file in the folder it runs from!!! 139 MB? For a filesystem which is empty when you mount it?
I don't know. Here's one more thing to try, though. In addition to doing the "erase" & "format" commands, perhaps you could actually flash the userdata image from the stock ROM
Code:
fastboot erase userdata
fastboot format userdata
fastboot flash userdata userdata.img
and then when you boot to the custom recovery, perform a "factory reset" - or try doing the "Format Data" thing in TWRP after (or before?) the above steps.
If none of this works, I suppose you could try the equivalent sorts of things with CWM and see if you get a different result.
You don't need to permanently install CWM with a hard flash - you can just soft-boot it for a single session:
Code:
fastboot boot recovery-clockwork-touch-6.0.2.3-grouper.img
Sorry this is so vague, but you know how it goes - you stumble into a problem, start fooling around until it gets fixed - and because you weren't really expecting the problem in the first place, you haven't written down the exact conditions and steps. Like I said, I tried to re-create the problem a variety of ways - but failed at that effort.
good luck
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