Related
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.
EDIT: If you are coming here for the first time, this guide should still work, but @PorygonZRocks has created a flashable zip that should deal with a lot of these issues automatically. You can check out his post here:
https://forum.xda-developers.com/showpost.php?p=75787067&postcount=699
This method will indirectly allow you to root the LG Gpad v410 after it has been upgraded to Lollipop 5.1.1. Yes. Rooting LG v410 Lollipop. It's through a downgrade, but it works.
It took a while to get working, but here's how I did it. The process is straightforward, but the details matter greatly. You will brick your device if you mess up. Please read everything *first* before you do anything. Be sure you understand the process. I'll try to explain what's going on along the way.
An external SD card is extremely helpful for this process. You *could* adb push everything, but that will tedious.
First, you need some files.
The 4.4.2 KDZ which is a TEST OS, but it can be rooted and it downgrades to a Bump'able bootlaoder:
http://forum.xda-developers.com/g-pad-10/general/kdz-lg-g-pad-7-0-v410-t3224867
The LG 2014 Flash Tool:
http://www.mediafire.com/download/fwrcd3pdj0svjtb/LG_Flash_Tool_2014.zip
Android LG Drivers:
https://www.androidfilehost.com/?fid=24052804347802528
Parted for Android. You can probably find it other places, but I found this file:https://dl.dropboxusercontent.com/u/84115590/LG%20G2%2016GB%20Solution/sdparted-recovery-all-files.zip
EDIT: There seems to be a lot of confusion here. My bad. All you need is the file named "parted" from this zip file - nothing else. Just put that one file in the root of your external SD card.
https://dl.dropboxusercontent.com/u/84115590/LG G2 16GB Solution/sdparted-recovery-all-files.zip linked from here: http://www.**********.com/your-32gb-lg-g2-shows-only-16gb-storage-space-heres-the-fix/
EDIT2: The dropbox link is down. I've attached the file directly.
The Candy5 ROM (This will potentially save you some manual steps. Somewhat optional, but highly recommended):
http://forum.xda-developers.com/g-pad-10/development/rom-candy5-g-pad-v410-lollipop-5-1-1-v2-t3111987
Flashify APK:
http://www.apkmirror.com/apk/christian-gollner/flashify/flashify-1-9-1-android-apk-download/
TWRP for the v410:
http://forum.xda-developers.com/g-pad-10/development/recovery-twrp2-8-5-0lgv400-410-t3049568
LG One Click Root:
http://forum.xda-developers.com/lg-g3/general/guide-root-lg-firmwares-kitkat-lollipop-t3056951
(You may use Purple Drake or whatever else you want. They all use the same root script as this does and the GUI is helpful for novices.)
Android SDK (specifically adb.exe. After installing go to SDK Manager and ensure that Android SDK Platform Tools is checked):
http://developer.android.com/sdk/index.html
For clarification below, when I have commands in "quotes" they are Windows commands. When they are in `backticks` they are commands that you run inside of ADB which actually run on your device....as root. Root can screw things up. Please be extra cautious. If you blame me for messing up your device I will laugh at you. But that's not gonna happen, right? Good. Let's go.
Now that you have everything, put it all into a folder where you can access it easily.
Install the LG Drivers.
Install Android SDK (or otherwise get adb.exe).
Extract all of the archives.
Move the KDZ to the LG Flash Tool 2014 folder.
Put the tablet into Download Mode by powering it off, holding VolUp, and plugging in the USB cable. Press VolUP when instructed. You must be in Download mode before continuing.
Run LGFlashTool2014.exe. Select the KDZ file. Click "CSE Flash". Click "Start". Select "English" and click OK. Do not change anything else.
WAIT for the flash to continue. If you really want to brick your device, here's a good opportunity.
The device will reboot into Android 4.4.2. You will only have 4GB of internal storage at this point. DON'T PANIC! We are fixing it.
Enable USB debugging.
Connect the device.
Install and run LG One Click Root. Wait for the device to be rooted before proceeding.
Copy the Flashify apk, TWRP image, and Candy5 ROM to your external SD card.
Install Flashify and flash TWRP to the recovery partition.
Use the Flashify menu to reboot in to recovery.
DON'T PANIC! You will get white vertical lines on the boot screen from now on. They only show up during boot animations. A small price to pay. This may be fixed at a later date. for the time being! Thanks to marcsoup's first post ever, we have a fix! Details below. PLEASE click this link and thank him!
Things get tricky here. Copy parted to your external SD card and then run "adb shell" from Windows to get a shell in TWRP.
In TWRP, unmount /data by tapping Mount > uncheck Data.
`cp /sdcard/parted /sbin/` This copies the parted binary to /sbin so it can be executed in the path. I had trouble running `/sdcard/parted`, but YMMV.
`chmod +x /sbin/parted` Make it executable.
`parted /dev/block/mmcblk0` Run parted against the internal mmc
`p` Prints the partition table.
`rm 34` Deletes partition 34 labeled "grow". This is the root of our problem. The KDZ apparently only creates a 4GB partition, I assume so the test build has maximum compatibility with all sized devices.
`rm 33` Deletes partition 33 "userdata"
`p` Print to verify
`mkpartfs` Create a partition and put a filesystem on it. If we only expand the partition it won't help us because the filesystem is still only 4 GB.
a) name: userdata
b) type: ext2 (the tool only supports ext2. This is ok for now.)
c) start: 3439MB (the end of part 32. IT MAY BE DIFFERENT FOR YOU!) Be sure you do not omit the MB part otherwise the offset will overwrite another critical partition.
d) end: 15.8GB (where "grow" ended above. IT MAY BE DIFFERENT FOR YOU!) Be sure you do not omit the GB part otherwise the offset will overwrite another critical partition.
`p` Verify. For me it did not name the partition properly. Gotta fix that.
(if necessary) `name 33 userdata` This is critical for mount to find it in /dev/block/platform/msm.sdcc.1/by-name/ on some/all ROMS.
`p`. Verify one last time. Compare it to my partition table in the attachments. If you want to brick, delete some random partitions here.
Flash Candy5 with TWRP. It's only 239 MB, so it will flash quickly. I do this because Candy5 will reformat mmcblk0p33 from ext2 to ext4 for you. It does this as part of it's system boot, apparently. If you install a different ROM that does not do this, you can reformat it by running `make_ext4fs /dev/block/mmcblk0p33`. If your ROM does not have make_ext4, it likely has some differnt method to make an EXT4 filesystem. `/system/bin/mke2fs -t ext4 /dev/block/mmcblk0p33` may work better. Just flash Candy5 and be done with it.
Tap Wipe > Swipe to Factory Reset.
Tap Reboot > System.
WAIT!!! It will take a minute for the ROM to start the first time. You will have white lines and and possibly a white screen. WAIT. It's moving the DEX files to cache, formatting a partition, creating default folders on the internal storage, and several other things. WAIT! When the screen goes dim or turns off then it's ready.
Cycle the display or turn it on. You should be at the Candy5 lock screen.
USB debugging is on by default. Run "adb shell".
`mount | grep userdata` Make sure mmcblk0p33 is mounted.
`df` Make sure /data is 11.3 GB (or whatever size it is on non-16GB devices).
HELL YEAH, you downgraded, rooted, and fixed the partition problem. Enjoy your tablet!
Thanks to dopekid313 for finding the KDZ.
Thanks to timmytim for Candy5.
Thanks to the creators of the root script, flashify, TWRP, and XDA for being so awesome.
Thanks to marcsoup for fixing a fix to the white lines.
Thanks to navin56 for the partition dumps. PLEASE thank his post!
White lines fix.
What we are going to do is flash the aboot partition with the stock image provided by navin56. I've removed the extra files from the dump, so simply download aboot.img.7z below. Unzip it using 7zip.
These commands are to be run in TWRP. Reboot to TWRP recovery and connect with "adb shell". All of the following commands will be run in ADB under TWRP. If you cannot figure out how to get here, please post in the thread and someone will help you. Onward:
If you do everything correctly then you don't have to reflash your ROM and you won't lose data. This process can be done any time after flashing the KDZ, even before you follow the steps above to resize the userdata partition. It's a completely separate process.
Unzip aboot.img.7z so you have the file named aboot.img. You should also make sure that aboot.img's MD5 sum is e97431a14d1cee3e9edba513be8e2b52. Do not flash the 7z file. Please.
Copy aboot.img to your external SD card. It should live at /sdcard/aboot.img
Boot to TWRP and run "adb shell"
`ls -al /dev/block/platform/msm_sdcc.1/by-name/` Let's make sure we are flashing the right partition. On my device "aboot" is /dev/block/mmcblk0p6. You should verify this on your device or you WILL brick your tablet.
`dd if=/dev/block/mmcblk0p6 of=/sdcard/aboot-fukt.img` Let's back up our current aboot partition before we go flashing things just in case there are unintended consequences later. Be sure you have the same partition that "aboot" referred to in the 4th step or you have just backed up the wrong partition.
`dd if=/sdcard/aboot.img of=/dev/block/mmcblk0p6` Be sure the file exists, is the correct aboot.img, and you are flashing the right partition. You have been warned!!
Reboot TWRP and enjoy your boot animations again.
If I missed anything, please let me know. As far as I know this is the very first tutorial that details what is necessary to accomplish this. Please hit the Thanks button on every thread that you visit to download files!
FAQ:
Q: Why do I only have 11.3 GB of space when my device is 16GB?
A: The entire internal SD card (eMMC) is 16 GB. Gotta have someplace to install the bootloader, recovery, android, the modem OS, the secondary bootloader, the cache, the resource and power manager, and all of the other partitions necessary for the table to operate. Please look at the second screenshot in the OP. All of those 33 partitions take up room on the internal card. Fortunately ALL of those partitions ONLY take up about 4.4 GB. Hence the 'userdata' partition is ~11.3 GB.
If anyone wants to use my work to create a flashable zip to make it easier for novices, please do so. My problem is solved and I don't have the time to create the zip. Please post any questions and I'll gladly answer them! I'm so stoked that we have a usable downgrade method now!
Thank You, Worked Great
Thanks for making this I was gonna do it but was to lazy lol and thanks for linking my thread and giving cred instead of just linking straight to the kdz thank you
grandamle91 said:
Thank You, Worked Great
Click to expand...
Click to collapse
Glad to be of help!
dopekid313 said:
Thanks for making this I was gonna do it but was to lazy lol and thanks for linking my thread and giving cred instead of just linking straight to the kdz thank you
Click to expand...
Click to collapse
Of course! If you hadn't obtained the firmware then we'd all still be looking for a solution. It pisses me off to no end when people try to take credit for other people's work. We all just need to realize and acknowledge that we are simply standing on the shoulders of those who did the work necessary for each of us to do our work.
I just noticed since we formatted the userdata it screws up TWRP. It won't mount Data and it says the settings are corrupted
grandamle91 said:
I just noticed since we formatted the userdata it screws up TWRP. It won't mount Data and it says the settings are corrupted
Click to expand...
Click to collapse
Is this after you've rebooted into Candy5 and the partition is reformatted as ext4 (or you've done so manually)? TWRP may not be able to mount an ext2 partition.
EDIT: I just tested this. Following my instructions and flashing to Candy5, TWRP sees mmcblk0p33 (userdata) as the full size and mounts it at /emmc.
For clarification, after you run the parted commands, it will mess with the partition table and TWRP will most likely not be able to see it to remount it - at least not until after a reboot. This is why you need an external SD card from which to install ROMs.
/data not mounted
Edit: nevermind. The partition 33 was still ext2. I had to run make_ext4fs /dev/block/mmcblk0p33 and now I am able to mount /data. Thanks.
Thanks for taking the time to help us.
I followed the steps and till 33 I am good. But once I am in Candy5, I am not able to adb shell (adb not recognizing device eventhough usb debugging is on). I rebooted to recovery and adb works there. But my /data partition is not enabled in TWRP. I am not able to check it either under Mount in TWRP.
Code:
mount | grep userdata
is empty
Code:
df
does not show data
I tried this and my tablet bootlooped. I was able to get into fastboot and restore. I would GREATLY appreciate it if someone who has the time, would kindly donate their valuable time to into making an exe zip or something.
gridironbear said:
I tried this and my tablet bootlooped. I was able to get into fastboot and restore. I would GREATLY appreciate it if someone who has the time, would kindly donate their valuable time to into making an exe zip or something.
Click to expand...
Click to collapse
At what point did it bootloop? What was the last step that you took before rebooting?
Zip
I would really appreciate a zip file as I have never been savvy with adb and for whatever reason it doesn't want to work on Windows 10.
drumm3rb0y said:
I would really appreciate a zip file as I have never been savvy with adb and for whatever reason it doesn't want to work on Windows 10.
Click to expand...
Click to collapse
A zip file for what part? The only part that requires ADB directly is to fix the internal storage. You absolutely have to flash the KDZ and then root before you can do anything. If you are on 5.x then you have no possible way to root, much less flash a zip file.
If you tell me what exactly you are having issues with I will try to help.
fatbas202 said:
A zip file for what part? The only part that requires ADB directly is to fix the internal storage. You absolutely have to flash the KDZ and then root before you can do anything. If you are on 5.x then you have no possible way to root, much less flash a zip file.
If you tell me what exactly you are having issues with I will try to help.
Click to expand...
Click to collapse
The adb part is the part im having issue with. Everything else is flashed already. I was wondering if you could make a zip for the adb part so I can just flash it through twrp.
thanks for the great help. it did work perfectly to regain the lost space.
what about white lines ? is there any solution for that problem ?
I have tried flashing back stock recovery extracted from kdz, dd' but didn't help.
Now i am thinking of flashing back the aboot.bin extracted from original kdz or i can dump ".img" from another working device. (i have 4 similar devices)
what is your opinion i m not a developer and i need your advise. should i go ahead and which partition should i dd ? aboot or abootb or boot ?
regards
shahidmianoor said:
thanks for the great help. it did work perfectly to regain the lost space.
what about white lines ? is there any solution for that problem ?
I have tried flashing back stock recovery extracted from kdz, dd' but didn't help.
Now i am thinking of flashing back the aboot.bin extracted from original kdz or i can dump ".img" from another working device. (i have 4 similar devices)
what is your opinion i m not a developer and i need your advise. should i go ahead and which partition should i dd ? aboot or abootb or boot ?
regards
Click to expand...
Click to collapse
I have no solid evidence of this, but I suspect that the white lines are caused by a display driver issue where when the bootloader hands over control of the display to the kernel it doesn't get reinitialized properly. I have no ideas as to how to get rid of that at the moment but if I stumble across something I'll be sure to post here.
While I'm not an Android developer, I've been a Linux admin for 10+ years and have a lot of experience with Android devices. I'd be really hesitant to go flashing things ad hoc. While Download Mode may save you if you flash the wrong thing, I'm not entirely sure what the limitations that you may run in to with a locked bootloader are.
After having this device for months on 5.x and FINALLY being able to downgrade and run custom ROMs with root, not seeing a boot animation is a pittance to pay. But I'll keep looking.
i have same problem entered in TWRP but when ADB sheel thorough DP tools it didn't connect to my device. i m also using windows 10
Do I need to Re-mount Data ? I press format data button at TWRP and mount data. It looks work great.
After all process, it shows 16Gb total at storage, 11.04GB available. it works perfectly.
I need the stock V41010d, so I reflash the stock rom rooted at [ROM][STOCK](V410 ONLY)KOT49I.V4101d | 4.4.2 | Rooted + Busybox
Now, my Gpad is at stock V41010d, but I have a question about the boot screen, is it still with white lines and white screen? Any method to fix it?
Hello,
Thanks for the great work. unfortunately I am facing some difficulty, starting from step# 16 "Things get tricky here", how to run"adb shell in TWRP?
also can I use minimal_adb_fastboot_v1.1.3_setup.exe as mentioned in the link in the OP http://www.droidviews.com/your-32gb-lg-g2-shows-only-16gb-storage-space-heres-the-fix/ ?
also I noticed the path have been used includes 'parted' folder, but the folder I have after unzipping the parted zip called 'sdparted-recovery-all-files', do I rename the folder to 'parted' instead?
please help and excuse my broken English.
I'm also having trouble with the adb shell step. When my device is powered on normally, adb commands work. However, in TWRP mode my computer can't recognize the tablet, mount properly, and copy over parted. All the steps have been identical to this point. Any ideas?
iphone5sf said:
Do I need to Re-mount Data ? I press format data button at TWRP and mount data. It looks work great.
After all process, it shows 16Gb total at storage, 11.04GB available. it works perfectly.
I need the stock V41010d, so I reflash the stock rom rooted at [ROM][STOCK](V410 ONLY)KOT49I.V4101d | 4.4.2 | Rooted + Busybox
Now, my Gpad is at stock V41010d, but I have a question about the boot screen, is it still with white lines and white screen? Any method to fix it?
Click to expand...
Click to collapse
You shouldn't need to remount or format data. The parted command nukes the filesystem and creates a new one formatted as ext2. At this point the running kernel has the old partition table loaded and won't know that the partition has been extended. Simply flash Candy5 and reboot at this point and it will reformat the userdata partition.
See above for the white lines during the boot animation. Known issue, no fix in sight, doesn't really matter.
nmnm4alll said:
Hello,
Thanks for the great work. unfortunately I am facing some difficulty, starting from step# 16 "Things get tricky here", how to run"adb shell in TWRP?
also can I use minimal_adb_fastboot_v1.1.3_setup.exe as mentioned in the link in the OP http://www.droidviews.com/your-32gb-lg-g2-shows-only-16gb-storage-space-heres-the-fix/ ?
also I noticed the path have been used includes 'parted' folder, but the folder I have after unzipping the parted zip called 'sdparted-recovery-all-files', do I rename the folder to 'parted' instead?
please help and excuse my broken English.
Click to expand...
Click to collapse
You only need the sdparted-recover-all-files.zip from that site. "parted" is not a folder, but the binary (without a file extension) inside of that zip file. Copy that file to /sbin and you are in business.
zmali1 said:
i have same problem entered in TWRP but when ADB sheel thorough DP tools it didn't connect to my device. i m also using windows 10
Click to expand...
Click to collapse
summonholmes said:
I'm also having trouble with the adb shell step. When my device is powered on normally, adb commands work. However, in TWRP mode my computer can't recognize the tablet, mount properly, and copy over parted. All the steps have been identical to this point. Any ideas?
Click to expand...
Click to collapse
I'd recommend installing the SDK and pulling the drivers from that. Alternatively, you can try the drivers here: https://github.com/koush/UniversalAdbDriver.
Technically, when I ran the "parted" commands I was actually booted in to rooted 4.4.2 from the KDZ; I wasn't actually in TWRP. It's just not a very recommended way of going about it. I explained how to run all of this from TWRP, but there's no technical reason that you *can't* run this from Android. You just *shouldn't* because you can't cleanly unmount the filesystem and it theoretically could cause filesystem corruption. I just figured that I don't care about that partition getting corrupted since it's getting wiped out.
After trying to install the March security patch and revert to stock, my XT1644 changed from a Moto G4 Plus to a Moto G4 without fingerprints etc.
I learned after the fact that my TWRP backup only backed up 3 partitions of my phone's 48 partitions (only 4 were offered on the first version of TWRP I tried). Reflashing all ROMS, including npjs25-93-14-4 via fastboot does not help. I have since found the solution. The hw partition had become corrupted.
Because of this issue, I wrote a script which dumps all partitions (by default only partitions of 102400 blocks or less). It writes a summary to a file called partitions.txt which includes checksums of all partitions. It also writes the output from getprop to build.prop. It writes everything to a sub directory of wherever the script is uploaded to.
The options are as follows:
Code:
#adb shell /data/media/0/PartitionImages/backupPartitions.sh -h
Usage /data/media/0/PartitionImages/backupPartitions.sh [-z] [-b MaxBlocks] [-n partition1 ] [-n partition2 ]
options:
-z optional to tar.gz the output folder default=false
-b 102400 optional maximum number of blocks of the partition - 0 will dump all partitions default=102400
-n partitionName... optional - one or more partitions to dump
To use do this, all you need is an unlocked bootloader and ADB debugging turned on.
The steps are as follows:
1) Boot into TWRP Recovery
2) Run the following commands via ADB to prepare the backup (note /data/media/0/ can be substituted for /sdcard if you have one)
Code:
adb shell mkdir /data/media/0/PartitionImages
adb push .\backupPartitions.sh /data/media/0/PartitionImages/backupPartitions.sh
adb shell chmod 0755 /data/media/0/PartitionImages/backupPartitions.sh
3) Perform the backup to backup (see options above if you want a full backup or a more limited backup)
Code:
adb shell /data/media/0/PartitionImages/backupPartitions.sh
4) Copy the results back to your computer
Code:
adb pull /data/media/0/PartitionImages .\PartitionImages
Try to flash twrp and clear internal memory as well
And after that flash dec security version of android 7..
dont try to lock the bootloader.
It worked for me ...
Best of luck
Resolved!
As posted on a related thread I just found, I have resolved the issue:
Moto G4 Plus's Model changed to G4,lost one imei and finger print.
Excellent tool, thank you very much.
So, in the unlucky case that i would lose fingerprint scanner, etc. due to bootloader downgrade or whatsoever that causes it. if i flash my previously backuped (with your script) hw.img partition with ' fastboot flash hw hw.img ', my device will be recognized as a Moto G4 plus?
And features like fingerprint, network, will be in working condition again?
I think that your script is a "must have" for every flashaholic that owns a G4 Plus. I did the backup, just in case. Thanks for sharing it.
moonlightdrive said:
Excellent tool, thank you very much.
So, in the unlucky case that i would lose fingerprint scanner, etc. due to bootloader downgrade or whatsoever that causes it. if i flash my previously backuped (with your script) hw.img partition with ' fastboot flash hw hw.img ', my device will be recognized as a Moto G4 plus?
And features like fingerprint, network, will be in working condition again?
I think that your script is a "must have" for every flashaholic that owns a G4 Plus. I did the backup, just in case. Thanks for sharing it.
Click to expand...
Click to collapse
That is the idea yes, but I haven't tested restoring anything - only done a binary patch of the first little bit of that partition - using dd. I wrote it mostly to get the MD5s of each partition from someone with a working phone so I could start looking for differences. There are lots of more professional backup tools out there which are likely all just wrappers around dd - but this will likely do the job with very basic requirements.
Nice work mate :good: @givitago
givitago said:
After trying to install the March security patch and revert to stock, my XT1644 changed from a Moto G4 Plus to a Moto G4 without fingerprints etc.
I learned after the fact that my TWRP backup only backed up 3 partitions of my phone's 48 partitions (only 4 were offered on the first version of TWRP I tried). Reflashing all ROMS, including npjs25-93-14-4 via fastboot does not help. I have since found the solution. The hw partition had become corrupted.
Because of this issue, I wrote a script which dumps all partitions (by default only partitions of 102400 blocks or less). It writes a summary to a file called partitions.txt which includes checksums of all partitions. It also writes the output from getprop to build.prop. It writes everything to a sub directory of wherever the script is uploaded to.
The options are as follows:
Code:
#adb shell /data/media/0/PartitionImages/backupPartitions.sh -h
Usage /data/media/0/PartitionImages/backupPartitions.sh [-z] [-b MaxBlocks] [-n partition1 ] [-n partition2 ]
options:
-z optional to tar.gz the output folder default=false
-b 102400 optional maximum number of blocks of the partition - 0 will dump all partitions default=102400
-n partitionName... optional - one or more partitions to dump
To use do this, all you need is an unlocked bootloader and ADB debugging turned on.
The steps are as follows:
1) Boot into TWRP Recovery
2) Run the following commands via ADB to prepare the backup (note /data/media/0/ can be substituted for /sdcard if you have one)
Code:
adb shell mkdir /data/media/0/PartitionImages
adb push .\backupPartitions.sh /data/media/0/PartitionImages/backupPartitions.sh
adb shell chmod 0755 /data/media/0/PartitionImages/backupPartitions.sh
3) Perform the backup to backup (see options above if you want a full backup or a more limited backup)
Code:
adb shell /data/media/0/PartitionImages/backupPartitions.sh
4) Copy the results back to your computer
Code:
adb pull /data/media/0/PartitionImages .\PartitionImages
Click to expand...
Click to collapse
guys i dont understand what to do my pls help me can u describe in detail what are the steps to get back my moto g4 plus fingerprint can you make a video
or explain this
can anyone can upload their full backup of his moto g4 plus ? it will me really helpful because after 201-1 aka june security patch update totally bricked my phone and from since no bootloader and nothing is in my phone. and the blackflash method is also not working. so if I somehow use tour backup as emmc and bering my phone back to life ?!?! Thanks.....
Hello,
Please help me my moto g4 plus is dead after nougat update only white LED is blinking
i have try blankflash aslo but same issue...
error is.
Motorola qboot utility version 3.40
[ -0.000] Opening device: \\.\COM3
[ 0.001] Detecting device
[ 0.003] ...cpu.id = 2418 (0x972)
[ 0.003] ...cpu.sn = 30871031 (0x1d70df7)
[ 0.004] Opening singleimage
[ 0.012] Loading package
[ 0.016] ...filename = singleimage.pkg.xml
[ 0.018] Loading programmer
[ 0.019] ...filename = programmer.mbn
[ 0.019] Sending programmer
[ 0.240] Handling things over to programmer
[ 0.240] Identifying CPU version
[ 0.246] Waiting for firehose to get ready
[ 60.377] Waiting for firehose to get ready
[120.466] ...MSM8952 unknown
[120.466] Determining target secure state
[120.469] Waiting for firehose to get ready
[180.546] ...secure = no
[180.584] Flashing GPT...
[180.601] Flashing partition:0 with gpt_main0.bin
[180.602] Initializing storage
[180.606] Waiting for firehose to get ready
[240.617] Configuring device...
[240.622] Waiting for firehose to get ready
[300.634] Waiting for firehose to get ready
[360.651] Waiting for firehose to get ready
[420.661] Waiting for firehose to get ready
[480.668] ERROR: do_package()->do_recipe()->do_flash()->gpt_flash()->get_storage
()->init_storage()->firehose_do_fmt()->do_recipe()->do_configure()->buffer_read(
)->device_read()->IO error
[480.668] Check qboot_log.txt for more details
[480.668] Total time: 480.668s
FAILED: qb_flash_singleimage()->do_package()->do_recipe()->do_flash()->gpt_flash
()->get_storage()->init_storage()->firehose_do_fmt()->do_recipe()->do_configure(
)->buffer_read()->device_read()->IO error
please help
Hi, is there is any hardware partition for camera and flashlight???? Bcoz ny device camera hardwares are good but not opening. Camera says "camera is busy" and flashlight option is missing from my device ans it says flashlight not detected in flashlight app. Same issue i had for network and fingerprint. It is solved via hw partition image. Is there is any hardware partition for camera also???? If it is there, plz include in this thread...
Aashakmeeran said:
Hi, is there is any hardware partition for camera and flashlight???? Bcoz ny device camera hardwares are good but not opening. Camera says "camera is busy" and flashlight option is missing from my device ans it says flashlight not detected in flashlight app. Same issue i had for network and fingerprint. It is solved via hw partition image. Is there is any hardware partition for camera also???? If it is there, plz include in this thread...
Click to expand...
Click to collapse
This can be software related or hardware issue.. not any partition related..
For Hardware*
I don't know anything.. you can see fixing videos or go to service center..
For software* (two methods)
1) Try this app, https://f-droid.org/en/packages/info.aario.killcamera/
2) reflash ROM, try different ROM.
3) this is hardware issue.
Do you know if it was working before you flashed ROM and device changed to normal G4..??
____Mdd said:
This can be software related or hardware issue.. not any partition related..
For Hardware*
I don't know anything.. you can see fixing videos or go to service center..
For software* (two methods)
1) Try this app, https://f-droid.org/en/packages/info.aario.killcamera/
2) reflash ROM, try different ROM.
3) this is hardware issue.
Do you know if it was working before you flashed ROM and device changed to normal G4..??
Click to expand...
Click to collapse
Ya it works fine before the name I got g(4) but after doing frp flash it is not getting. Even the flashlight also not works.
Aashakmeeran said:
Ya it works fine before the name I got g(4) but after doing frp flash it is not getting. Even the flashlight also not works.
Click to expand...
Click to collapse
Tried app i mentioned ?
Tried reflashing other/stock rom?
If still not working, it's definitely hardware issue, because others with same issue (g4plus > g4) haven't reported any camera problem.
If you know hardware stuff, then go and check it. Otherwise service centers are best choice..
____Mdd said:
Tried app i mentioned ?
Tried reflashing other/stock rom?
If still not working, it's definitely hardware issue, because others with same issue (g4plus > g4) haven't reported any camera problem.
If you know hardware stuff, then go and check it. Otherwise service centers are best choice..
Click to expand...
Click to collapse
That app need root it seems. So root process is going on. Ill try my best and thank you:good:
By doing this I lost my Imei number plz help:crying: anyone
givitago said:
After trying to install the March security patch and revert to stock, my XT1644 changed from a Moto G4 Plus to a Moto G4 without fingerprints etc.
I learned after the fact that my TWRP backup only backed up 3 partitions of my phone's 48 partitions (only 4 were offered on the first version of TWRP I tried). Reflashing all ROMS, including npjs25-93-14-4 via fastboot does not help. I have since found the solution. The hw partition had become corrupted.
Because of this issue, I wrote a script which dumps all partitions (by default only partitions of 102400 blocks or less). It writes a summary to a file called partitions.txt which includes checksums of all partitions. It also writes the output from getprop to build.prop. It writes everything to a sub directory of wherever the script is uploaded to.
The options are as follows:
Code:
#adb shell /data/media/0/PartitionImages/backupPartitions.sh -h
Usage /data/media/0/PartitionImages/backupPartitions.sh [-z] [-b MaxBlocks] [-n partition1 ] [-n partition2 ]
options:
-z optional to tar.gz the output folder default=false
-b 102400 optional maximum number of blocks of the partition - 0 will dump all partitions default=102400
-n partitionName... optional - one or more partitions to dump
To use do this, all you need is an unlocked bootloader and ADB debugging turned on.
The steps are as follows:
1) Boot into TWRP Recovery
2) Run the following commands via ADB to prepare the backup (note /data/media/0/ can be substituted for /sdcard if you have one)
Code:
adb shell mkdir /data/media/0/PartitionImages
adb push .\backupPartitions.sh /data/media/0/PartitionImages/backupPartitions.sh
adb shell chmod 0755 /data/media/0/PartitionImages/backupPartitions.sh
3) Perform the backup to backup (see options above if you want a full backup or a more limited backup)
Code:
adb shell /data/media/0/PartitionImages/backupPartitions.sh
4) Copy the results back to your computer
Code:
adb pull /data/media/0/PartitionImages .\PartitionImages
Click to expand...
Click to collapse
hey bro can u please explain me this actually my moto g4 plus isnt accepting new hw image
I have the Moto G7 International variation (INDIA/RETIN, it turns out; I'm in the US and thought I was buying the RETUS version, but I didn't pay enough attention to the store page). I have rooted the device easily, thanks to the assistance of these forums. I have also installed TWRP 3.3.1-2-river for the purpose of backups and restores, though there seems to be problem with it. However TWRP is not the focus of my question right now.
I have become quite annoyed with the boot animation on this phone and would like to change it. Putting new boot animations in the /system/media folder has not been working and it seems to be because this international model has a boot animation override (that trumps all other boot animation locations) in the /oem/retin/media folder. The /oem folder is initially read-only, but can be remounted with read-write without error (using root). Using MiXplorer or the adb shell, I can delete stuff from there without error as well. However, when I reboot, it all comes back. I suspect that the changes I make to the /oem folder are not actually persisted to whereever in the first place. When I look at the mounts on the phone, I see /oem is mounted from /dev/block/dm-1. /dev/block/dm-1 is listed in my partitions list when the phone is booted up normally. From what I can tell though (and I'm not that knowledgable on this topic), that is just a "wrapper" around some data elsewhere. How can I tell where this dm-1 partition's data is really coming from?
As additional information, the block list by-name lists the oem image as belonging to block mmcblk0p58. When I boot into TWRP and mount that block, I do see the usual /oem stuff in there. I deleted the boot animation from there and tested unmounting the block, rebooting into TWRP and remounting the block and can see that the boot animation is still properly deleted from there. However, when I boot the phone back up normally, I see the usual stuff (including the boot animation) in the /oem folder still. That might make some sense, since it is listed as being mounted from /dev/block/dm-1 and not from /dev/block/mmcblk0p58 (though I was hoping dm-1 was a wrapper for mmcblk0p58).
This is the only dm mount on the phone; I don't have the problem with /system being uneditable because it is mounted to dm-0 like I see in many other posts for other phones. In turn, I don't think I have the "base data is encrypted" problem from those cases either (it is "just" an oem setup and not personal data). This still seems somewhat like the dm-verity problem I read about with other phones though (although this one doesn't give the dm-verity warning when I try to remount /oem as read-write). Running the commands:
Code:
adb root
adb disable-verity
just tells me
Code:
disable-verity only works for userdebug builds
verity cannot be disabled/enabled - USER build
I'm not sure how to check if there is dm-verity on in the first place though.
As a more direct question (though I would still like to know how to trace this dm-1 partition backwards), how can I make changes to this /oem folder actually persist between reboots?
@Spaceminer described the exact same problem for the Moto G6 in the Universal DM-Verity remover thread. In the end he said that it wasn't solvable without a system root.
https://forum.xda-developers.com/an...rceencrypt-t3817389/post81974407#post81974407
(I have since returned the phone because of this.)
1equals2 said:
@Spaceminer described the exact same problem for the Moto G6 in the Universal DM-Verity remover thread. In the end he said that it wasn't solvable without a system root.
https://forum.xda-developers.com/an...rceencrypt-t3817389/post81974407#post81974407
(I have since returned the phone because of this.)
Click to expand...
Click to collapse
i was unable to get this to persist either. i ended up using magisk for my work instead.
@1equals2 @HT123 To persist changes to your /oem partition the HAB (high assurance boot) verification must be deactivated. I've already successfully tested it on my device, a Moto G6 plus.
Here are the required steps: (only for Stock ROM!!)
1.) Start TWRP and backup /vendor + /system
2.) Mount /vendor + /system and delete the following
files:
- /vendor/etc/init/hw/init.mmi.hab.rc
- /vendor/bin/init.mmi.hab.sh
- /system/verity_key
3.) Go to /vendor/etc/init/hw and adb pull init.mmi.rc in order to edit the file.
4.) Open it and delete the lines 19+20:
Code:
19 # Moto verified boot extension
20 import /vendor/etc/init/hw/init.mmi.hab.rc
5.) Save the changes, copy it back to its path and set permissions to: -rw-r--r-- root:root
==> After the next reboot /vendor and /oem are mounted as ../vendor_a and ../oem_a (depending on your active slot).
As the last step you have to customize fstab.qcom to be able to access the files within the /oem folder.
Adb pull /vendor/etc/fstab.qcom and open it. The last line defines how /oem is mounted during the init process. You should change it like this:
before:
Code:
/dev/block [...] /oem ext4 ro,nosuid,nodev,[STRIKE]context=u:object_r:oemfs:s0[/STRIKE] wait,slotselect,[STRIKE]verify[/STRIKE]
after:
Code:
/dev/block [...] /oem ext4 ro,nosuid,nodev,[COLOR="red"]barrier=1[/COLOR] wait,slotselect
Save it and copy it back. Permissions: -rw-r--r-- root:root
>>> REBOOT AND ENJOY!!
If your persist partition gets damaged this can break your sensors. Sometimes that just happens during a faulty operation while flashing.
Some ROMs might even fail to boot and in some weird situations the screen may rotate to the opposite direction.
To fix persist you can try these methods. If none of them work flash the lastest OxygenOS (v3.1.4) and try again. This doesn't work with all ROMs.
Sensors can be checked using apps like CPU Info (Google Play), CPU Info (F-Droid) or SatStat (F-Droid).
Method A) Restore an older TWRP backup of persist
If this does not work or you never made a backup, keep reading for advanced options.Method B) Flash the lastest OxygenOS and reboot.
OxygenOS can recreate missing sensor calibration data. Some custom ROMs can but not all of them.If this does not work, keep reading for advanced options.
Once everything works again take a TWRP backup of persist you can always return to.
While you're at it, back up EFS as well if you don't know where to find a backup or you never made one.
More about what every partition does, including EFS and persist.
Congrats, you're done!
If you need to move to the advanced methods, take a TWRP backup of your current persist and keep it no matter what.
If none of them fixed your issues, restore this backup of persist before trying any other approach.
Copy the backup to your PC now to make sure you don't lose it on accident!
To open a shell on TWRP go to Advanced > Terminal or run adb shell on your PC.
If you really can't use TWRP or another custom recovery for this you can also try the following methods at runtime if your ROM is rooted.
Do this at your own risk.
If you can't take a TWRP backup of persist, e.g. because it is unmountable:
cd /sdcard; backup=persist_$(date +%Y-%m-%d_%H-%M-%S)_broken.img
dd bs=64k if=/dev/block/platform/msm_sdcc.1/by-name/persist | gzip > "$backup".gz
sha256sum /dev/block/platform/msm_sdcc.1/by-name/persist "$backup".gz > "$backup".sha2
To restore:
(gzip -d | dd bs=64k of=/dev/block/platform/msm_sdcc.1/by-name/persist) < <backup>.gz
sha256sum -c <backup>.sha2
Copy the backup to your PC now to make sure you don't lose it on accident!
These methods were tested with TWRP v3.4.0-0
Method C) Repair the filesystem on persist
- This may or may not work. This can help if you get the TWRP error Failed to mount '/persist'- Make sure that Persist is unchecked in the Mount section in TWRP.e2fsck -f /dev/block/platform/msm_sdcc.1/by-name/persistIf e2fsck asks questions you don't know how to answer cancel with Ctrl+C and ask someone for help. Otherwise just try whatever is available, restore your backup and try again if needed.mount /persist (this should give no errors)- RebootMethod D) Restore file permissions
- This may or may not work. This only works if persist is mountable.- It is possible that this method works better at runtime on a rooted ROM.- If you want to know what file contexts aremount /persist (this should give no errors)restorecon -R /persist/sensors/ /persist/sns.regchmod u+rwx /persist/sns.reg; chmod 775 /persist/sensors/; chmod u+rw /persist/sensors/*- RebootIt is recommended to try the following methods with OxygenOS 3.1.4 installed. Not all custom ROMs are able to regenerate sns.reg
Method E) Delete sensor related files from persist
- This may or may not work. This only works if persist is mountable.mount /persist (this should give no errors)rm -fr /persist/sensors/ /persist/sns.reg- RebootMethod F) Reformat persist, if all else fails, known to work
This method was tested to fix sensors without creating obvious issues but wiping persist could have unknown side-effects in the long run.
Only do it if you have to. Make sure you know what persist if used for so you can recognize possbile issues if they occur and keep your initial backup around.
- Tested with OxygenOS 3.1.4 and TWRP v3.4.0-0- This will get you a completely fresh start. This helps if you get the TWRP error Failed to mount '/persist'- Make sure that Persist is unchecked in the Mount section in TWRP.make_ext4fs /dev/block/platform/msm_sdcc.1/by-name/persistreboot- Note: Recent TWRP builds for the OnePlus X store settings in /persist/.twrps and /sdcard/TWRP/.twrps and will reset when wiping both at the same time.
That's it!
Remember to take a backup of EFS and Persist now if everything is working or restore the backup you took at the start if you're still having issues and want to try other solutions.