Database Users

[Q] Requirements for new ROMs with different size paritions

Hey everyone.
Can any senior member write me a bit of a guide as of what do I have to do in order to switch ROMs with different partition requirements?
I am looking for as little work as possible. I am having problem making ADB run on my computer, so I need a way to do it without need of ADB. Preferably something straight from the phone. So:
Of course, first I do nandroid backup through CMR. Then what?
Do I have to get to fastboot somehow and manually change values?
Or when I download the cLK ROM version, do I just flash it through CMR by zip from SD and it will repartition automatically to fit the requirements?
Currently my system partition is 190MB, and I'd like to try a 2 roms that are 150MB and 220MB required.
Thanks in advance.

while you wait for someone to link you to the (easily findable ) guide stickies, you can flash a 150 rom to a 190 partition if you are just playing. you will waste 40 meg, but if you're planning to flash again it hardly matters.

Yeah, I figured that, but I am more interested in a quick and safe way to switch system partition size, without ADB.
and when looking at roms, i only see different requirements, but no way to change the sizes.
Would you be so kind to explain, how this repartitioning works for flashing new roms? (clk)

When you flash clockwork, there is a file in the clockwork folder on your PC called flash.cfg (beware of the second file flash.cfg.txt, , if you only see "flash" and "flash.cfg" then you need to unhide file extensions)
anyway, open notepad, drag the flash.cfg file into it and you will see something like
Boot yaffs 8m
System yaffs 150m
Data allsize
(More than just that but you get the idea)
Well, if I change the 150m to 200m, save the file, run daf.exe to instal clockwork, it will be flashed with a 200 Meg system partition.
That's all there is to it.
Each line is one partition, boot, cache, system, data,, data doesn't have a size, it has allsize so will take up whatever space is left. You generally only ever alter the system.
The nand toolkit is the easier way to do it. Same principle, but point and click.
Either way, you perform this from within magldr, "USB flasher" option.
If you are on clk not magldr, I can't help, never used it.
Edit - "without adb " ... hmm, do you mean without USB? You can't.
If you are just having driver problems, there's an install drivers (or something) button in nand toolkit, try it.

samsamuel said:
When you flash clockwork, there is a file in the clockwork folder on your PC called flash.cfg (beware of the second file flash.cfg.txt, , if you only see "flash" and "flash.cfg" then you need to unhide file extensions)
anyway, open notepad, drag the flash.cfg file into it and you will see something like
Boot yaffs 8m
System yaffs 150m
Data allsize
(More than just that but you get the idea)
Well, if I change the 150m to 200m, save the file, run daf.exe to instal clockwork, it will be flashed with a 200 Meg system partition.
That's all there is to it.
Each line is one partition, boot, cache, system, data,, data doesn't have a size, it has allsize so will take up whatever space is left. You generally only ever alter the system.
The nand toolkit is the easier way to do it. Same principle, but point and click.
Either way, you perform this from within magldr, "USB flasher" option.
If you are on clk not magldr, I can't help, never used it.
Edit - "without adb " ... hmm, do you mean without USB? You can't.
If you are just having driver problems, there's an install drivers (or something) button in nand toolkit, try it.
Click to expand...
Click to collapse
Thanks mate. That's exactly the problem, I have found guides for magldr, but never for clk.
And about adb - my pc would need an OS reinstall to run well again - vista, and i already got it pretty screwed up.
Anyway, thanks for your help, I understand it more!

PIT file method to revive your phone from a MMC_CAP_ERASE brick

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

Let's hear it....

ok I wait. ..

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

clockworkmod

Hi guys, I had clockworkmod 5.0.2.6 installed but it was small(partition). I've found some clockwork mods with bigger partition(250, 400) in guide and downloaded them. I flashed them via daf and they've flashed successfully. Now, the problem is none of newer roms(ics, jb) work with that version of cwm. How to install other recovery(for eg. newer cwm)? Don't give me the guide, I'm sick of them and have a few bookmarked but there is no solution for that. Oh, I forgot. I have mag1.13 and cwm 3.0.0.8(orange one)..
Thanks in advance.

Shaumaaa said:
Hi guys, I had clockworkmod 5.0.2.6 installed but it was small(partition). I've found some clockwork mods with bigger partition(250, 400) in guide and downloaded them. I flashed them via daf and they've flashed successfully. Now, the problem is none of newer roms(ics, jb) work with that version of cwm. How to install other recovery(for eg. newer cwm)? Don't give me the guide, I'm sick of them and have a few bookmarked but there is no solution for that. Oh, I forgot. I have mag1.13 and cwm 3.0.0.8(orange one)..
Thanks in advance.
Click to expand...
Click to collapse
If your just looking to increase system partition then there is a file (flash.cfg I think) that you need to modify, open it and it should be fairly clear what to modify to increase the partition size.

I edited the flash.cfg with notepad++ and wanted to flash the same recovery again but daf is showing me some error.

first, in case you handt realised, increasing teh system size is only needed when the size required by your rom needs it, , , , so for example flashing a 200mb rom to a 400mb partition will waste 200mb, the system wont use that extra space. Your total available storage does NOT include teh system partition, sop teh bigger system partition you create, the lesws available internal storage you will have for data.
Look in the folder where flash.cfg is, , find recovery-raw.img and replace it with the new recovery .img you want to use.
Then, because of the line
recovery rrecov|ro|nospr filesize recovery-raw.img
in flash.cfg, when you run the flash it will create the correct recovery partition size.
(If the newer recovery didnt use a larger recovery partition, or if you wanted to reinstal recovery again after already doing the above, ((meaning the recovery partition is already big enough)) you would simply start cwm, and flash the new recovery from sd card, just like flashing a rom)
showing me some error.
Click to expand...
Click to collapse
completely useless sentence, you may as well not bother, how do we know what error it shows? mind reading?

This error
An error has occurred
Read below for more information
Error Description: Config load failed.
Info: .\RSPL\RSPL.cpp (725)
Error Description: CONFIG: bad data size format
Info: .\RSPL\RSPL.cpp (428)

**** yeah! I did it!
Thanks bro'

I dindn't Heeeeeeeeelp..
I installed the cwm touch and when installing rom with aroma(pacman) it stays at 0% but it's putting files to system. Then it passes the mag and stays at bootanimation. Whats wrong?
EDIT: I'm uploading video of my problem

Fixed
Fixed with magldr repartitioning. Thanks anyway.

[Q&A] [MOD][TWRP][RECOVERY] Reclaim the whole free space of your system partition

Q&A for [MOD][TWRP][RECOVERY] Reclaim the whole free space of your system partition
Some developers prefer that questions remain separate from their main development thread to help keep things organized. Placing your question within this thread will increase its chances of being answered by a member of the community or by the developer.
Before posting, please use the forum search and read through the discussion thread for [MOD][TWRP][RECOVERY] Reclaim the whole free space of your system partition. If you can't find an answer, post it here, being sure to give as much information as possible (firmware version, steps to reproduce, logcat if available) so that you can get help.
Thanks for understanding and for helping to keep XDA neat and tidy!

Khaon said:
Hello,
many users complain that since lollipop their system partition size doesn't reflect the actual system of the block device. Therefore, they can not install some extra in this partition( busybox, big gapps packages,etc.).
This is due to the system image size specified when building the rom:
One of the parameter of your system partition(which has been hardcoded in some config file, I.e. BoardConfig) is its size, but if the block device(i.e. the part of your internal storage that will be mounted for the system partition)'s size that is mounted is larger than the system partition's size than you will loose some space.
Fortunately resize2fs executable allows to modify an ext2,ext3,ext4 partition size:
This package simply resizes your system size to match the size of your block device size.
It does not alter your partitions table just reclaim the unmounted space.
Instructions:
Boot on a twrp 2.8.x.y TWRP recovery
flash the package
Download :
https://drive.google.com/file/d/0B9kxrJw-dzUmNG12QkdaU3R4Ujg/view
Credits :
@m11kkaa from whom I took the idea
Click to expand...
Click to collapse
Hello,
It doesn't work on my fresh install of 5.1 (stock and on nexus 7 2012 wifi). TWRP says :
Code:
Error executing updater binary in zip '/sdcard/resize_manta.zip'
Error flashing zip '/sdcard/resize_manta.zip'
I've tried both with TWRP and with nexus root toolkit. I've redownload the zip. Still the same.
Any idea ?

carrion crow said:
Hello,
It doesn't work on my fresh install of 5.1 (stock and on nexus 7 2012 wifi). TWRP says :
Code:
Error executing updater binary in zip '/sdcard/resize_manta.zip'
Error flashing zip '/sdcard/resize_manta.zip'
I've tried both with TWRP and with nexus root toolkit. I've redownload the zip. Still the same.
Any idea ?
Click to expand...
Click to collapse
The binary is not static and it was built for nexus 10.

OK, thank you. I will search for another solutions.

Khaon said:
Can you confirm this is the path of your system partition's block device?
Code:
dev/block/platform/sdhci-tegra.3/by-name/APP
Click to expand...
Click to collapse
I have a Nexus 7 (2012) and can confirm that this is the path of the device:
Code:
[email protected]:/ # cat /proc/mounts
/dev/block/platform/sdhci-tegra.3/by-name/APP /system ext4 ro,seclabel,relatime,user_xattr,acl,barrier=1 0 0

OK I won't be able to edit now but if you open the .sh fi!e you will be able to hardcode this path instead of the one I put!

0.0mb system on Nexus 7
So I found this post which have the solution to this problem here;
http://forum.xda-developers.com/nexus-10/development/mod-reclaim-free-space-partition-t3029605
This does not currently work for the Nexus 7. Since I'm a new member here I cannot answer the OP personally, but if he sees this or anyone care to relay the information;
I can confirm that this is the correct path
Code:
dev/block/platform/sdhci-tegra.3/by-name/APP
//MarK

Khaon said:
OK I won't be able to edit now but if you open the .sh fi!e you will be able to hardcode this path instead of the one I put!
Click to expand...
Click to collapse
Okay so I tried to hardcode this path. Maybe I'm just extremely stupid, but I couldn't get it to work.
Still get the Error executing updater binary. I'm on TWRP 2.8.7.0.

MarkPersson said:
Okay so I tried to hardcode this path. Maybe I'm just extremely stupid, but I couldn't get it to work.
Still get the Error executing updater binary. I'm on TWRP 2.8.7.0.
Click to expand...
Click to collapse
If you are on twrp 2.8.7.0 you dont need this anymore , yu can from the wipe screen resize a system partition

Khaon said:
If you are on twrp 2.8.7.0 you dont need this anymore , yu can from the wipe screen resize a system partition
Click to expand...
Click to collapse
Oh. I had no idea.
I don't know if the N7 has too low memory, but this didn't help at all unfortunately.
I get the following info:
Present: Yes
Size: 639MB
Free: 0MB
Used: 639MB
Backup Size: 639MB
Tried both to Resize and Repair but to no avail. :crying:

MarkPersson said:
Oh. I had no idea.
I don't know if the N7 has too low memory, but this didn't help at all unfortunately.
I get the following info:
Present: Yes
Size: 639MB
Free: 0MB
Used: 639MB
Backup Size: 639MB
Tried both to Resize and Repair but to no avail. :crying:
Click to expand...
Click to collapse
I'm probably, no ... surely ... completely out of my depth, but is there any chance this was done intentionally to keep Bad Things(tm) from being put onto the system partition? It seems like a horrible oversight so I'm wondering if it was intentional. Of course if a hack was in a position to write the the system partition, then it is just as likely in a position to delete something to make room, but that might then be noticed.
Just something that popped into my head after all day cooking for the in-laws and now trying to decompress with some Nexus hacking

Both the script and the TWRP functionality worked fine on my N10. But it still doesn't leave much space on /system when running a Marshmallow-based ROM. Meanwhile, I have 22GB free on my internal user storage (emulated SD card).
I'm curious if it would be possible to shrink that user partition size some and add that space to /system using this script or TWRP? Running fdisk -l /dev/block/mmcblk0 in adb shell shows only one partition, so I'm not totally sure how things are being sectioned off internally.

I used this for the main reason to fix the issue of insufficient space in system partition that wasn't letting me install gapps, I don't know why but after I did the mod, and flashed aicp is showing 700mb total on system partition in tibu, I thought it's supposed to be 800mb on it, no biggie since I fixed my main issue but I only have 13mb left in system.
Sent from my Nexus 10 using Tapatalk

PIT files
My nexus 10 has the boot loop problem and I think I have been left with the only option of Re-Partition but I need the PIT file. Can anybody help or provide this file?
I have tried everything else (fastboot, adb, temporary custom recoveries, Nexus Root Toolkit) with no success.

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

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

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

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

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

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

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

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