PIT file method to revive your phone from a MMC_CAP_ERASE brick

[Mogi]

Thks hg42. Your post is detail and thks for sharing the workaround for ICS brick.

Sent from my GT-N7000 using xda premium

 

[hg42]

This is the same method here:
http://forum.xda-developers.com/showpost.php?p=26285877&postcount=12

thanks for the link.

I searched for similar kinds of solutions and didn't find one, but probably searched in a slightly different direction. So again, your always wiser after the event...

That post has some better discussion of backgrounds and reasons about what to move where. Also the conversion from ext2 to ext4 has more details, also different options to e2fsck. And finally, there are two packages attached, which could be useful for the fix.
Generally it is worth reading. Thanks neos...

 

[hg42]

Your post is detail

well, it could be much more detailed.
But most people don't like my generally really long posts.
So I cropped it in many ways.

If someone wants to discuss some points, please just ask!

 

[hg42]

btw. should I move the real content of my thread from my second post into the first?
What do you think? That wouldn't make the real content more visible, but would make all those funny small comments look like nonsense (which is nice, ha ha)

 

[stephencwl]

Great to hear it actually works. Pretty straight forward for those linux versatile guru.

It's fun to read your attempt. Thanks.

 

[Narada2XK]

~ # e2fsck -c /dev/block/mmcblk0p9
e2fsck 1.41.12 (17-May-2010)
/dev/block/mmcblk0p9: Updating bad block inode.
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Directory inode 46753, block #0, offset 0: directory corrupted
Salvage<y>?

Is this supposed to happen or do I indeed have a corrupted directory?

 

[ukicar]

btw. should I move the real content of my thread from my second post into the first?
What do you think? That wouldn't make the real content more visible, but would make all those funny small comments look like nonsense (which is nice, ha ha)

not necessary but it would be useful

 

[prasad.adam]

Seems a simple to follow process. I am, luckily, not the bricked one but good to know that the fix is now available. Great contribution!

 

[hg42]

~ # e2fsck -c /dev/block/mmcblk0p9
e2fsck 1.41.12 (17-May-2010)
/dev/block/mmcblk0p9: Updating bad block inode.
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Directory inode 46753, block #0, offset 0: directory corrupted
Salvage<y>?

Is this supposed to happen or do I indeed have a corrupted directory?

you have a corrupted directory structure, but you don't know the reason.

This is often repairable, but...
If you have bad blocks from a MMC_CAP_ERASE brick, e2fsck will probably get stuck somewhere.
From what I read, there seem to be people having only blocks overwritten with zeros but not damaged ones.
Also, I don't really know what kind of bad blocks my phone has now, they can't be read nor written to. Each software accessing them seems to get stuck.

In general such an fsck error can only occur when the system is stopped suddenly somewhere in the middle of some kind of writing to disk or the system has a bug somewhere.
Some standard PC scenarios do not apply or should be uncommon:
- power switched off
You can't do that with the power switch. When battery is running out of power you get a warning and if you ignore this the phone finally shuts down itself in an orderly manner.
But you can indeed pull the battery, so beware, don't do this if you don't need to and always wait some minute or two.
- system crash, blue screen etc.
I never saw something like this on android, did you?
Linux is generally very stable and most instabilities have to do with crappy PC hardware or undocumented hardware interfaces etc. Android hardware seems to be designed much cleaner.
But there are also some critical items: overclocking or undervolting if not tested thoroughly, patching and tweaking kernels and root apps accessing hardware or disks may lead to disk failures too.

 

[breckbit]

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

Seems you don´t realize what the thread-opener is writing about... It´s not that simple to repartition the emmc...

 

[hg42]

Seems you don´t realize what the thread-opener is writing about... It´s not that simple to repartition the emmc...

I interpreted Zamboney's post as a little bit kidding, at least I hoped it was?

But whatever, if you know linux, it's not that complicated.
For others this might get difficult.

You need to calculate proper values, to be successful.

But, you can always resolve from failures by restoring the old partition theme.
You can do this with parted, fdisk, etc.
You also have the option to install your standard PIT file via Odin or Heimdall.

At the end, my main problem was to get to the point to be able to use adb as root.

First you need a recovery which starts adbd.
With a cleared system partition, you get some difficulties.
Some recoveries even don't start adb.
Some want to start it, but don't have one included, so they try to start adbd from somewhere inside /system.
Others (like the stock recovery) don't work with adb shell. That is because the standard way to start the shell is to invoke /system/bin/sh.

Then I couldn't use adb push to transfer files to the system partition. I think this also was because of the cleared system partition.

After finding a backup, which installed some important files on the writable part of my system partition, I could do much more. But in my case only the first 15MB could be written until the CWM restore stopped at a bad block. Btw. you can't use the partition image based Odin for this kind of restore, it has to be file wise (recovery or adb pull if that works).

Then you have the problem, that repartitioning also removes all data in the affected partitions. So you have the same empty system partition again.
Therefore I should have made a backup of this reduced system partition before repartitioning, but I didn't.

I had also done an adb pull / before, so I had all files on my PC, which I managed to write back to the /system partition with adb push (if that works!).
The Thor kernel/recovery derived from GB is awesome at least for restoration purposes, as it has all important tools in it's /sbin, which is part of the recovery (remember, /system is not).
So as I remember, you can do all this with the Thor kernel alone.

 

[hg42]

creating a PIT file

After saying all that...

I want to create a PIT file which can simply be flashed by Odin or Heimdall. But Heimdall extracts only the exact PIT file I (or the system) had installed to the phone some times before (that is the original partition scheme).

It doesn't export my current partitioning scheme.

Does anyone know how to patch a PIT file?
I already googled and read some posts about the theme, but I didn't find one, which tells me the exact structure, only vague information...
Does anyone have a better source?

 

[blue_panther9_9]

After saying all that...

I want to create a PIT file which can simply be flashed by Odin or Heimdall. But Heimdall extracts only the exact PIT file I (or the system) had installed to the phone some times before (that is the original partition scheme).

It doesn't export my current partitioning scheme.

Does anyone know how to patch a PIT file?
I already googled and read some posts about the theme, but I didn't find one, which tells me the exact structure, only vague information...
Does anyone have a better source?

Im trying your guide and also forrest1971 at the moment. Since Im a bit curious with this, I ended up rewiping the same partition using parted and created the same partition under the same blocks.


One of them hangs when converting the partition to ext4 which is /datafs. What should I do? is it safe to unplug the phone and redo it again? how to stop it? I can ctrl+c but I dont want to make more silly move


also


Writing inode tables: done
Creating journal (4096 blocks): done
Writing superblocks and filesystem accounting information: done

This filesystem will be automatically checked every 30 mounts or
180 days, whichever comes first. Use tune2fs -c or -i to override.
~ # mke2fs -T ext4 /dev/block/mmcblk0p10
mke2fs -T ext4 /dev/block/mmcblk0p10
mke2fs 1.41.11 (14-Mar-2010)
warning: 126 blocks unused.



Is that mean the system found 126 corrupt blocks?

 

[hg42]

One of them hangs when converting the partition to ext4 which is /datafs. What should I do? is it safe to unplug the phone and redo it again?

as long as nobody is currently writing to the flash, you should be safe to switch off the device (remove battery). This should be the case when it hangs.
When partitioning, there is nearly nothing which could fail.
Creating a partition should be a very short moment.
The longer time is when parted creates the file system inside the partition.
When you recreate the partition anyway, all this data inside the partition doesn't matter any more.

I tried these methods to escape a hang with varying success:

- try to open another adb (second console on PC with adb shell)
from that shell
- you could eventually be able to kill the hanging process
- try kill -9 or kill -HUP etc.
- try to close the adb console and restart another
- the HUP signal could eventually kill the hanging process
- pull the battery

mke2fs 1.41.11 (14-Mar-2010)
warning: 126 blocks unused.

Is that mean the system found 126 corrupt blocks?

no, the partition schemes sometimes leave some blocks unassigned, mostly because of Microsoftisms

According to your bad blocks in /data:

My attempt was to punch out the complete /system and /data in the partition scheme, this should work with all bricks, which have only bad blocks in one or both of these two partitions. Additionally I chose rounded numbers for the partitions just to not calculate them exactly.
This could be optimized, so you could get up to about 2GB more space (not really worth the hassle, right?), but I thought this optimization would be a second step, first I wanted to get my phone back to running state.
Also, as I wanted to post my steps, I could not assume which blocks are bad for different users, so I took the complete /system and /data as possibly damaged.

If other partition would be affected, there might be other schemes to solve this, but you would have to think about it first.

 

[hg42]

I want to create a PIT file
...
Does anyone know how to patch a PIT file?
I already googled and read some posts about the theme, but I didn't find one, which tells me the exact structure, only vague information...
Does anyone have a better source?

Ok, I am dumb, I already had it:

https://github.com/Benjamin-Dobell/Heimdall/blob/master/libpit/Source/libpit.h

so stay tuned...

 

[blue_panther9_9]

as long as nobody is currently writing to the flash, you should be safe to switch off the device (remove battery). This should be the case when it hangs.
When partitioning, there is nearly nothing which could fail.
Creating a partition should be a very short moment.
The longer time is when parted creates the file system inside the partition.
When you recreate the partition anyway, all this data inside the partition doesn't matter any more.

I tried these methods to escape a hang with varying success:

- try to open another adb (second console on PC with adb shell)
from that shell
- you could eventually be able to kill the hanging process
- try kill -9 or kill -HUP etc.
- try to close the adb console and restart another
- the HUP signal could eventually kill the hanging process
- pull the battery



no, the partition schemes sometimes leave some blocks unassigned, mostly because of Microsoftisms

According to your bad blocks in /data:

My attempt was to punch out the complete /system and /data in the partition scheme, this should work with all bricks, which have only bad blocks in one or both of these two partitions. Additionally I chose rounded numbers for the partitions just to not calculate them exactly.
This could be optimized, so you could get up to about 2GB more space (not really worth the hassle, right?), but I thought this optimization would be a second step, first I wanted to get my phone back to running state.
Also, as I wanted to post my steps, I could not assume which blocks are bad for different users, so I took the complete /system and /data as possibly damaged.

If other partition would be affected, there might be other schemes to solve this, but you would have to think about it first.

I waited for a while, it finally stopped and went to (parted)..

After I recreated mmcblk0p10, I ran e2fsck -c /dev/block/mmcblk0

I found that the superblocks are having segmentation fault. <in other word- pretty much dead>

now Im gonna skip the chunk of old mmcblk0p10 to avoid it. for anyone doing this, please make sure you do e2fsck so you know which drive is affected..(im talking about mmcblk0p10 or mmbll0p9

Im repartitioning it again.. fingers cross

 

[XpLoDWilD]

This is not a "full" MMC_CAP_ERASE brick. The OP can still access recovery and Odin, so he can repartition/repair his emmc. However, if you can't access it anymore (if SBL/PBL is broken), this won't be of any use.

 

[blue_panther9_9]

also for anyone else new to this(including me) if something ever happened during this partition process(hangs and stuff) and you cant print anymore in parted no matter how many times you restarted the phone n PC. Reinstall the PIT should fix it.

also make sure to backup the partition numbering, because the default PIT file is no longer works in the future. Just like HG42 mentioned above, prepare to make custom pit file to suits you

 

[Zamboney]

I interpreted Zamboney's post as a little bit kidding, at least I hoped it was?

Yeah, of course it was tongue in cheek. I'm grateful for your efforts, but thought I'd have a little fun with the thought of a newbie doing this.


Sent from my GT-N7000 using Tapatalk 2

 

[hamann]

to hg42:
The .pit file you are creating is all the command to clear the partition and make brick device working again right? I really hope so because I have no idea about adb shell. My device is bricked too. thanks.