Develop Bugs

[TEST] Custom Storage Partitions v1 for OPPO FIND 7 (x9076)

Read-Me First
1) This procedure may brick your phone and make it useless. Use this procedure at your own risk.
2) This procedure is not official, so it is not supported by Oppo company.
3) This procedure is only for advanced users with a good low-level knowledge of Android storage and adb-fastboot commands.
4) This procedure WILL ERASE ALL YOUR PERSONAL DATA on your phone. Please BACKUP ALL YOUR DATA before using this procedure.
5) This procedure has been tested only on Oppo Find 7 (x9076) phone.
6) This procedure will use an external Micro-SD card to make user run some scripts.
Goal/Purpose
This procedure will resize the two partitions ("userdata" and "sdcard") used by Oppo Find 7 to store personal data, such as apps, photos, images, and so on.
Due to the fact the Oppo Find 7 (x9076) uses an only-3GB "userdata" partition to store apps, while all the remaining space (24 GB) is used for "sdcard" partition to store other data, this matter doesn't provide with enough space to store apps and their related data.
This procedure should be used to enlarge the size of "userdata" partition, to let user have more space for apps and less space for personal data in order to use some ROMs that currently do not provide with support for unified storage ("Unified Storage Layout" or LVM), such as Color OS, CyanogenMod and other ROMs based on CyanogenMod rom.
With the provided compressed file, you will receive some ".sh" files to be used to resize the storage partitions. The namefile of these scripts just means two numbers, the first one is the new size (in GB) of "userdata" partition, while the second one is the new size (in GB) of "sdcard" partition. So, for example, the script "8_19.sh" should be used to have 8 GB for the resized "userdata" partition, and "19 GB" for the resized "sdcard" partition.
How to
1) Make a backup of all your data on your phone.
2) Download and unzip the compressed file.
3) Just unzip the included "external_sd.zip" file on root of your external MicroSD card.
4) Restart into recovery.
5) Run terminal window and execute "adb shell" to go into adb shell.
6) Run command "cd /external_sd/new_scripts".
7) Be sure that all .sh files are in folder "/external_sd/new_scripts".
8) Run one of the provided ".sh" file. Do not unplug the usb cable and wait until the end of the procedure. If you've selected "unified.sh" script, please remember that you have to update the custom recovery (as described in thread "Unified Storage Layout" - http://www.oppoforums.com/threads/tutorial-unified-storage-layout-for-oppo-find-7a.17952/).
9) Enjoy your new storage partitions.
Issues
1) If the procedure will end with the error "Persist partition is damaged. After rebooting into recovery, please run persist_fix application.", you have to reboot into recovery again, and then run the script included inside "persist_fix" folder (it is part of the zipped file "external_sd.zip").
Make sure that "persist" partition will have the "ext4" formatting, because it is happened, many times, that during backup and restore of "persist" partition, something happens to damaged the "ext4" formatting.
2) It is happened, once only, that you cannot reboot into recovery again due to some problems during backup-restore procedure of "recovery" partition. This problem may be simply solved flashing the recovery with "fastboot" command.
Tips & Hints
1) I suggest users of Oppo Find 7a, to use alternate unified procedures (such as “Unified Storage Layout” or LVM) instead of this procedure, due to low storage sizes. It is a non-sense to waste space for two partitions (one dedicated only to the apps, and the other one to user’s data) when you can use only a big one, shared for both apps and data.
2) If you have not enough know-how to use this procedure or if you are afraid of doing something wrong using this procedure, you can wait for a definitive decision from Oppo about storage layout. With last final release of ColorOS (2.0 kitkat), Oppo still continues to use two partitions, with only 3GB dedicated to apps, and the remaining storage space dedicated to user’s data.
There are some rumors about Oppo regarding storage layout, that is Oppo will use the LVM storage layout in the future. Anyway we hope that Oppo may release the guidelines for storage as soon as possible, maybe with next ColorOS release.
3) This procedure makes a backup of the most important partitions in order to restore them after the resizing procedure. The backup is stored on the external MicroSD card at the end of the procedure, so please keep the backup for future reference and to restore it if something goes wrong in the future.
Please take note that only ColorOS is bundled with updated images of few partitions (some of them managed by the backup/restore procedure), but not for all partitions, so the only way to restore an image of a partition currently is to restore it from a stored image (such as the images stored by this procedure).
4) During testing period, I’ve discovered that “persist” partition, managed by this procedure, may lose the “ext4” file system formatting during the backup/restore procedure. On Internet there is a lot of mainstream about this partition, but mainly there is a lot of confusion regarding it. Someone even suggests formatting (so erasing it) this partition whenever users encounter problems on using phone.
As far as I understand, “persist” partition is a mountable partition, it contains important code (binaries and data), mainly regarding wi-fi connections. It is used by all ROMs, including stock and custom ones.
So it is mandatory to preserve the contents of this partition to avoid bootloops, missing or poor wi-fi connections and other serious problems on using this phone.
If you want to know what is the contents of this partition, you can simply boot your ROM, use a terminal prompt, input “su” (you need root permissions) and simply go into “/persist” folder (it is mounted by the ROM).
At the end of the resize procedure, the “ext4” formatting will be checked in order to prevent any problems on “persist” partition. If “ext4” file system formatting is lost, a message will be shown to the user. The user must reboot into recovery, and then use the script included inside “persist_fix” folder (included in “external_sd.zip” file). This script will restore an image of “persist” partition and then check if the problem is solved or not. Please use this script whenever you have problems on “persist” partition (on Internet there is a lot of mainstream about “persist” partition, not only related to Oppo Find 7).
Copyrights
Some scripts included in this procedure are based on scripts written by Coldbird and included into "Unified Storage Layout" procedure. All rights are reserved to Coldbird.
Thanks
1) Thanks to Coldbird, to aut0mat3d and to all people involved into "Unified Storage Layout" procedure.
2) Thanks to all people involved into "LVM Partition Remapping" procedure.
3) Thanks, in advance, to all people that will test this procedure.
References
Why there is only 9.x GB user space on Find 7a (http://www.oppoforums.com/threads/faq-why-there-is-only-9-x-gb-user-space-on-find-7a.11787/)
Unified Storage Layout (http://www.oppoforums.com/threads/tutorial-unified-storage-layout-for-oppo-find-7a.17952/)
Partition Repairscripts for Oppo Find7, Find7a (http://www.oppoforums.com/threads/tool-partition-repairscripts-for-oppo-find7-find7a.20271/)
LVM Partition Remapping (http://forum.xda-developers.com/find-7/orig-development/ref-lvm-partition-remapping-t2865843)
Tested ROMs
1) Color OS – releases 1.2.6 and 2.0.0 Kitkat.
2) AICP – Release 20141018.
Issue: it is not possible to use the "sdcard0" mounting partition, it is set to read-only permission. To solve this issue, you have to flash another ROM before this, reboot and let it write its own folders onto "sdcard0" partition. Finally you can flash AICP rom and use it normally.
3) AOKP – Nightly 2014-10-18.
4) CyanogenMod CM11 – Nightly 20141025.
5) Dirty Unicorns – 20141011 v8.0 weekly.
Issue: bootloop – When a window, for selecting the language, appears, it seems to be blocked and after 5 seconds it reboots.
6) Mokee – 141025 release
7) Nameless ROM – 20141027 nightly
8) Omnirom 20140923 nightly and 20141031 nightly
Issue: bootloop – When a window, for selecting the language, appears, it seems to be blocked and after 5 seconds it reboots.
9) Paranoid Android – 4.6 beta 5 20141021
Issue : no boot – This ROM doesn't boot at all.
Tested also with 4.6 beta 4 20141007 – no problem.
Tested machine
Custom Recovery : TWRP 2.8.0.1
Google Apps : gapps-kk-20140606-signed.zip
New Internal Storage : 8 GB for "userdata" + 19 GB for "sdcard"
External Storage : 32 gb micro-sd class 10

I've tried this method. And I choose unified.
but I can't see that unified (like the pic).
Here the log from command
H:\adt\sdk\platform-tools>adb shell
~ # ←[6ncd external_sd
cd external_sd
/external_sd # ←[6ncd external_sd
cd external_sd
/external_sd/external_sd # ←[6nls
ls
new_scripts
persist_fix
/external_sd/external_sd # ←[6ncd new_scripts
cd new_scripts
/external_sd/external_sd/new_scripts # ←[6nls
ls
10_17.sh
11_16.sh
13_14.sh
8_19.sh
parted
stock.sh
unified.sh
/external_sd/external_sd/new_scripts # ←[6nsh unified.sh
sh unified.sh
=================================================
Retrieving the size of all partitions.....
userdata = 6291456s sectors
sdcard = 50000000 sectors
=================================================
rm: can't remove '/tmp/backup': No such file or directory
=================================================
Unmount all partitions except external_sd ....
=================================================
=================================================
Backup partitions into /tmp folder.....
=================================================
65536+0 records in
65536+0 records out
33554432 bytes (32.0MB) copied, 0.809779 seconds, 39.5MB/s
32768+0 records in
32768+0 records out
16777216 bytes (16.0MB) copied, 0.440292 seconds, 36.3MB/s
3072+0 records in
3072+0 records out
1572864 bytes (1.5MB) copied, 0.036449 seconds, 41.2MB/s
2+0 records in
2+0 records out
1024 bytes (1.0KB) copied, 0.000651 seconds, 1.5MB/s
16+0 records in
16+0 records out
8192 bytes (8.0KB) copied, 0.000746 seconds, 10.5MB/s
2048+0 records in
2048+0 records out
1048576 bytes (1.0MB) copied, 0.025429 seconds, 39.3MB/s
32768+0 records in
32768+0 records out
16777216 bytes (16.0MB) copied, 0.396552 seconds, 40.3MB/s
65536+0 records in
65536+0 records out
33554432 bytes (32.0MB) copied, 0.829321 seconds, 38.6MB/s
65536+0 records in
65536+0 records out
33554432 bytes (32.0MB) copied, 0.840793 seconds, 38.1MB/s
32768+0 records in
32768+0 records out
16777216 bytes (16.0MB) copied, 0.424749 seconds, 37.7MB/s
16384+0 records in
16384+0 records out
8388608 bytes (8.0MB) copied, 0.221377 seconds, 36.1MB/s
131072+0 records in
131072+0 records out
67108864 bytes (64.0MB) copied, 1.573372 seconds, 40.7MB/s
253919+0 records in
253919+0 records out
130006528 bytes (124.0MB) copied, 3.915451 seconds, 31.7MB/s
=================================================
We remove and create new partitions .......
=================================================
unified.sh: line 94: can't open /external_sd/new_scripts/parted/find7_unified.pa
rted: no such file
=================================================
Restore partitions from /tmp folder.....
=================================================
32768+0 records in
32768+0 records out
16777216 bytes (16.0MB) copied, 0.495464 seconds, 32.3MB/s
3072+0 records in
3072+0 records out
1572864 bytes (1.5MB) copied, 0.199716 seconds, 7.5MB/s
2+0 records in
2+0 records out
1024 bytes (1.0KB) copied, 0.000620 seconds, 1.6MB/s
16+0 records in
16+0 records out
8192 bytes (8.0KB) copied, 0.005822 seconds, 1.3MB/s
2048+0 records in
2048+0 records out
1048576 bytes (1.0MB) copied, 0.139941 seconds, 7.1MB/s
32768+0 records in
32768+0 records out
16777216 bytes (16.0MB) copied, 2.644259 seconds, 6.1MB/s
65536+0 records in
65536+0 records out
33554432 bytes (32.0MB) copied, 5.312673 seconds, 6.0MB/s
65536+0 records in
65536+0 records out
33554432 bytes (32.0MB) copied, 5.498313 seconds, 5.8MB/s
32768+0 records in
32768+0 records out
16777216 bytes (16.0MB) copied, 2.608278 seconds, 6.1MB/s
16384+0 records in
16384+0 records out
8388608 bytes (8.0MB) copied, 1.549714 seconds, 5.2MB/s
131072+0 records in
131072+0 records out
67108864 bytes (64.0MB) copied, 11.840047 seconds, 5.4MB/s
253919+0 records in
253919+0 records out
130006528 bytes (124.0MB) copied, 3.924011 seconds, 31.6MB/s
=================================================
We format userdata, cache and sdcard partitions.....
=================================================
mke2fs 1.41.14 (22-Dec-2010)
Filesystem label=userdata
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
Stride=0 blocks, Stripe width=0 blocks
196608 inodes, 786432 blocks
0 blocks (0.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=805306368
24 block groups
32768 blocks per group, 32768 fragments per group
8192 inodes per group
Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912
Writing inode tables: done
Creating journal (16384 blocks): done
Writing superblocks and filesystem accounting information: done
This filesystem will be automatically checked every 29 mounts or
180 days, whichever comes first. Use tune2fs -c or -i to override.
tune2fs 1.41.14 (22-Dec-2010)
Setting maximal mount count to -1
Setting current mount count to -1
Setting interval between checks to 4294880896 seconds
mke2fs 1.41.14 (22-Dec-2010)
Filesystem label=cache
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
Stride=0 blocks, Stripe width=0 blocks
32768 inodes, 131072 blocks
0 blocks (0.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=134217728
4 block groups
32768 blocks per group, 32768 fragments per group
8192 inodes per group
Superblock backups stored on blocks:
32768, 98304
Writing inode tables: done
Creating journal (4096 blocks): done
Writing superblocks and filesystem accounting information: done
This filesystem will be automatically checked every 28 mounts or
180 days, whichever comes first. Use tune2fs -c or -i to override.
tune2fs 1.41.14 (22-Dec-2010)
Setting maximal mount count to -1
Setting current mount count to -1
Setting interval between checks to 4294880896 seconds
mke2fs 1.41.14 (22-Dec-2010)
Filesystem label=sdcard
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
Stride=0 blocks, Stripe width=0 blocks
1564672 inodes, 6250000 blocks
0 blocks (0.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=0
191 block groups
32768 blocks per group, 32768 fragments per group
8192 inodes per group
Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
4096000
Writing inode tables: done
Creating journal (32768 blocks): done
Writing superblocks and filesystem accounting information: done
This filesystem will be automatically checked every 39 mounts or
180 days, whichever comes first. Use tune2fs -c or -i to override.
tune2fs 1.41.14 (22-Dec-2010)
Setting maximal mount count to -1
Setting current mount count to -1
Setting interval between checks to 4294880896 seconds
=================================================
We restore and check the persist partition.....
=================================================
65536+0 records in
65536+0 records out
33554432 bytes (32.0MB) copied, 4.838189 seconds, 6.6MB/s
e2fsck 1.41.14 (22-Dec-2010)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
/dev/block/mmcblk0p16: 28/320 files (0.0% non-contiguous), 1085/1280 blocks
=================================================
We copy all /tmp folder into external sdcard....
=================================================
=================================================
End of resizing partitions....
=================================================
Model: MMC 032GE4 (sd/mmc)
Disk /dev/block/mmcblk0: 61071360s
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Number Start End Size File system Name Flags
1 16384s 147455s 131072s fat16 modem
2 147456s 148479s 1024s sbl1
3 148480s 148543s 64s dbi
4 163840s 163903s 64s DDR
5 180224s 182271s 2048s aboot
6 182272s 183271s 1000s rpm
7 196608s 229375s 32768s boot
8 229376s 230375s 1000s tz
9 230376s 232423s 2048s pad
10 232424s 235495s 3072s modemst1
11 235496s 238567s 3072s modemst2
12 238568s 259047s 20480s oppodycnvbk
13 259048s 279527s 20480s oppostanvbk
14 294912s 3006463s 2711552s ext4 system
15 3006464s 9297919s 6291456s ext4 userdata
16 9297920s 9363455s 65536s ext4 persist
17 9363456s 10412031s 1048576s ext4 cache
18 10412032s 10444799s 32768s recovery
19 10444800s 10447871s 3072s fsg
20 10452992s 10452993s 2s fsc
21 10452994s 10453009s 16s ssd
22 10453010s 10455057s 2048s misc
23 10455058s 10487825s 32768s LOGO
24 10487826s 10553361s 65536s DRIVER
25 10553362s 10618897s 65536s reserve1
26 10618898s 10651665s 32768s reserve2
27 10651666s 10668049s 16384s reserve3
28 10668050s 10799121s 131072s reserve4
29 10813440s 60813439s 50000000s ext4 sdcard
30 60817408s 61071326s 253919s grow
Done.
/external_sd/external_sd/new_scripts # ←[6n
Maybe I make a mistake but can you explain more detail what's wrong?
Thanks

OldClass said:
I've tried this method. And I choose unified.
but I can't see that unified (like the pic).
Here the log from command
.......................
Maybe I make a mistake but can you explain more detail what's wrong?
Thanks
Click to expand...
Click to collapse
May you kindly show me the output of command "ls -l /external_sd/new_scripts/parted/", because I am worried about upper/lower case of extracted files. Thanks.

italianquadcore said:
May you kindly show me the output of command "ls -l /external_sd/new_scripts/parted/", because I am worried about upper/lower case of extracted files. Thanks.
Click to expand...
Click to collapse
Here is the output :
K:\adt\sdk\platform-tools>adb shell
~ # ←[6nls -l /external_sd/new_scripts/parted/
ls -l /external_sd/new_scripts/parted/
/external_sd/new_scripts/parted/: No such file or directory
~ # ←[6nls -l /external_sd/external_sd/new_scripts/parted/
ls -l /external_sd/external_sd/new_scripts/parted/
__bionic_open_tzdata: couldn't find any tzdata when looking for localtime!
__bionic_open_tzdata: couldn't find any tzdata when looking for GMT!
__bionic_open_tzdata: couldn't find any tzdata when looking for posixrules!
-rwxrwxrwx root root 872 2014-11-06 23:36 find7_10_17.parted
-rwxrwxrwx root root 872 2014-11-06 23:36 find7_11_16.parted
-rwxrwxrwx root root 872 2014-11-06 23:36 find7_13_14.parted
-rwxrwxrwx root root 872 2014-11-06 23:36 find7_8_19.parted
-rwxrwxrwx root root 868 2014-11-06 23:36 find7_stock.parted
-rwxrwxrwx root root 872 2014-11-06 23:36 find7_unified.parted
~ # ←[6n

i'm sorry has make mistake when put extracted folder in my sd card
now i can repart my internal Find 7 X9076
thanks for your help

OldClass said:
i'm sorry has make mistake when put extracted folder in my sd card
now i can repart my internal Find 7 X9076
thanks for your help
Click to expand...
Click to collapse
I've just updated the "how-to" procedure in order to avoid this problem in the future. I'am happy that it worked. Thanks for your testing.

It's work. Tested on my x9076 using ColorOS KitKat 33 (Chinese Full)

Hello,
i was on unified storage (coldbird method) and this method take me to brick my x9076
I have recovered it with the method QHSUSB_BULK on Oppo forums, and then, when i have a stock layout, i try again with this method.
It works like a charm! Thank youuuuuuu!! :laugh: :laugh: :good:

Hi.
If i go to recovery and execute adb shell, "device not found" error appears. Seems that i missed to install a driver. But i installed the oppo driver, adb driver from google... Nothing of that works.

Trinaaa said:
Hi.
If i go to recovery and execute adb shell, "device not found" error appears. Seems that i missed to install a driver. But i installed the oppo driver, adb driver from google... Nothing of that works.
Click to expand...
Click to collapse
Enable USB Debugging under Developer options in ColorOS and disable MTP under the mount menu in TWRP, then reconnect the phone to PC.

Done everything before, but i´ve got an old twrp version which doesn´t show me the "diasble mtp" option. With your hint i installed the newest twrp and it works! Thank you!

Thank you!!!
Worked like a charm.
Regards,
Samit.

X9006
hi
is this work for x9006 device too?
thanks

@italianquadcore,
Thanks for this great mod.
I had a few issues, which I am posting below.
(I am using Linux)
1. copied the scirpt external_sd folder to external sd on the phone.
2. rebooted to recovery. (Since I was going to use unified.sh, so flashed the unified twrp recovery before hand)
3. connected to phone to pc.
4. from pc: sudo adb shell
5. cd external_sd/external_sd
6. ./unified.sh
Result ... Unification failed.
During the execution, the script encountered 2 problems.
1. The script was not able to find /external_sd/new_scrtipts/parted/find7_unified.parted on line no 94.
So i copied find7_unified.parted to new_scripts folder and modified line no 94 of unified.sh as follows:
parted /dev/block/mmcblk0 < /external_sd/new_scripts/find7_unified.parted
2. The other problem for me was that the script find /dev/block/mmcblk0p15 mounted.
So ran umount /dev/block/mmcblk0p15 script manually.
Result ... Unification successful.
I am posting this so that it can be helpful to others.

May I ask what exactly the unify version does? Does it properly unify the system or is the entire storage made only for apps? For example, running Coldbird's version in a non-unified ColorOS will result in the user being able to use the entire storage for apps, but you can't download files or add them through USB

ganeshbiyer said:
@italianquadcore,
Thanks for this great mod.
I had a few issues, which I am posting below.
(I am using Linux)
1. copied the scirpt external_sd folder to external sd on the phone.
2. rebooted to recovery. (Since I was going to use unified.sh, so flashed the unified twrp recovery before hand)
3. connected to phone to pc.
4. from pc: sudo adb shell
5. cd external_sd/external_sd
6. ./unified.sh
Result ... Unification failed.
During the execution, the script encountered 2 problems.
1. The script was not able to find /external_sd/new_scrtipts/parted/find7_unified.parted on line no 94.
So i copied find7_unified.parted to new_scripts folder and modified line no 94 of unified.sh as follows:
parted /dev/block/mmcblk0 < /external_sd/new_scripts/find7_unified.parted
2. The other problem for me was that the script find /dev/block/mmcblk0p15 mounted.
So ran umount /dev/block/mmcblk0p15 script manually.
Result ... Unification successful.
I am posting this so that it can be helpful to others.
Click to expand...
Click to collapse
"5. cd external_sd/external_sd" is wrong. Is it a typo? Folder "new_scripts" (and all its related subfolders) must be put on "external_sd". So you should have "/external_sd/new_scripts/unified.sh" script to be working.
"So ran umount /dev/block/mmcblk0p15 script manually." mmcblk0p15 is mounted as "data" under TWRP recovery, so all the scripts simply unmount "data" mounting partition. Did you use another recovery?
Thanks for your testing.

idir_muse3k said:
hi
is this work for x9006 device too?
thanks
Click to expand...
Click to collapse
Please refer to paragraph "Tips & Hints" (here above), item 1.

farenteria said:
May I ask what exactly the unify version does? Does it properly unify the system or is the entire storage made only for apps? For example, running Coldbird's version in a non-unified ColorOS will result in the user being able to use the entire storage for apps, but you can't download files or add them through USB
Click to expand...
Click to collapse
For questions regarding "Unified Storage", please refer to thread on Oppo Forum ( http://www.oppoforums.com/threads/tutorial-unified-storage-layout-for-oppo-find-7a.17952/ ). Thanks.

to Italianquadcore
This is so freakin brilliant i screwed up my partitions (with 48mb internal space-lol) and followed your very well written gui, and bingo i got the partition sizes i want again....:highfive::highfive:
Worked like a charm on my x9076 qhd, which i was about to give up on!! Thankyou thankyou so much Pal
Gonna throw a small donation your way soon (not enough to buy a airplane., sorry) money is not what i have most off, just to show my appreciation!
:good:

Hello, I repartitioned the internal memory of my oppo 7 ( rom color os 2.0.0i) by your guide (13GB for data and the rest for storage) and it works perfectly and for that I m very happy because to have 3GB maximum for the app was something really limiting.
I wanted to ask you a question, if I try to change the my actually rom into one of those that you tested (for repartition memory) in the first post of the thread, i must repeat the procedure repartitioning? I must do wipe data / factory and flash the rom and I maintain the same memory repartitioned or i must redo the repartitioning procedure again? With rom tested in the first post i risk a brick of device? I say this because I want to change the color os because I would like to reduce the high consumption of battery and switch to a rom with consumption lower than, or at least let me flash the kernel sensei (the only kernel undervolted available for oppo7) with which to make a undervolt decent. To this end, I take this opportunity to ask you this too, that your opinion and what the best rom with low battery consumption (or what rom where i can flash the kernel sensei) that allows me to maintain this repartitioning already done in my color os 2.0

size partition for BoardConfig.mk

Hi
this is from the BoardConfig.mk
Code:
# fix this up by examining /proc/mtd on a running device
BOARD_BOOTIMAGE_PARTITION_SIZE := 0x105c0000
BOARD_RECOVERYIMAGE_PARTITION_SIZE := 0x105c0000
BOARD_SYSTEMIMAGE_PARTITION_SIZE := 0x105c0000
BOARD_USERDATAIMAGE_PARTITION_SIZE := 0x105c0000
BOARD_FLASH_BLOCK_SIZE := 131072
I want to find the actual size partition adb shell cat /proc/mtd" or "adb shell cat /proc/emmc" or "adb shell cat /proc/dumchar_info" doesn't work !

Steps:
*root your device;
*install TWRP or CWM for your device ;
*install busybox tools ( Busybox Free Goolge Play);
After this, enter to recovery mode. Mount /system into TWRP or CWM.
Plug USB cabe, and in your computer input these commands:
adb devices --> verify if device is connected
Now, install parted into /system/bin:
adb push <path-to-file>/parted /system/bin
Now, insert this command:
parted /dev/block/mmcblk0 unit B print
The output is similar :
Code:
~ # parted /dev/block/mmcblk0 unit B print
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 4194304B 6291455B 2097152B MRD
2 6291456B 8388607B 2097152B MRD_BK
3 8388608B 10485759B 2097152B MEP2
4 10485760B 31457279B 20971520B ext4 EFS
5 31457280B 46137343B 14680064B Reserved
6 46661632B 48234495B 1572864B LOKE_2ND
7 48758784B 50331647B 1572864B LOKE_1ST
8 50331648B 67108863B 16777216B PARAM
9 67108864B 83886079B 16777216B RECOVERY
10 83886080B 100663295B 16777216B KERNEL
11 100663296B 125829119B 25165824B MODEM
12 125829120B 142606335B 16777216B ext4 NVM
13 142606336B 352321535B 209715200B ext4 HIDDEN
14 352321536B 713031679B 360710144B ext4 CACHE
15 713031680B 2307915775B 1594884096B ext4 SYSTEM
16 2307915776B 7817134079B 5509218304B ext4 USER
Use the column size to fill in the BoardConfig values.
The first column it refers to the mount point.
Ex.: the kernel partition has 16.777.216 bytes mounted in /dev/block/mmcblk0p10
Links references:
http://forum.xda-developers.com/showthread.php?t=2450045
http://stackoverflow.com/questions/...ormation-for-android-device/15639867#15639867
http://forum.xda-developers.com/attachment.php?attachmentid=2397268&d=1384688569

naufragoweb said:
Now, install parted into /system/bin:
adb push <path-to-file>/parted /system/bin
Click to expand...
Click to collapse
Path to.. what file?

Nicofisi said:
Path to.. what file?
Click to expand...
Click to collapse
Path to the "parted" file in your PC

Trying to flash a dd image I took from the system partition

Long-time UNIX guy here, but relatively new to the world of Android.
I have recently purchased an Asus MemoPAD (ME103K) ; I then became root, and took a `dd` image of the read-only `system` partition to the external SD card:
Code:
$ su
# dd if=/dev/block/platform/msm_sdcc.1/by-name/system \
of=/storage/MicroSD/system.img bs=1M
# ls -l /storage/MicroSD/system.img
-rw-r--r-- 1 root root 2147483648 Sep 27 13:15 system.img
The size (exactly 2GiB) was a bit suspicious - could it be that this was because of the FAT32 partition on the SD card?
No, it was not - `tune2fs -l` revealed that this was indeed, a valid EXT4 image, exactly sized at 2GiB, which passed `fsck -f` with no errors at all.
And `fastboot` (from the linux machine attached to the tablet) concurred, after an `adb reboot bootloader`:
Code:
linuxbox# fastboot getvar all
(bootloader) version-bootloader: 3.03
(bootloader) version-hardware: rev_c
(bootloader) variant: LEOPARDCAT 16G
(bootloader) version-baseband: H00_0.16.F_0521
(bootloader) serialno: 0a3dXXXX
...
(bootloader) partition-type:system: ext4
(bootloader) partition-size:system: 0x0000000080000000
That size, is indeed 2GB:
Code:
linuxbox# python2 -c 'print 0x0000000080000000'
2147483648
So, all is good - I have a backup of the image. Now to test restoring it.
I try to flash the system.img back to the tablet - to make sure I can recover from anything, the sort of bullet-proof backup we do in the Unix world (*e.g. restore contents of a drive via `dd if=backup.image of=/dev/sdXXX`*).
Everything related to `adb` and `fastboot` work flawlessly - so I try...
Code:
linux_box# fastboot devices
0a3dXXXX fastboot
linux_box# mount /dev/sdcard /mnt/sdcard
linux_box# cp /mnt/sdcard/system.img .
linux_box# fastboot flash system system.img
error: cannot load 'system.img'
Hmm. I download and build the `android-tools-5.1.1` of my distribution from sources, adding debug information - and step in the debugger, to see this failure:
Code:
# gdb --args fastboot flash system system.img
...
(sorry, can't paste links yet - see this image: http i stack imgur com 9bIEM.png
Interesting - even though I am in a 64bit machine, apparently there are issues that turn the file size "negative" (in a 32bit world, the file size of my image, 2^31, is indeed considered negative - to be exact, `-2147483648`.
OK, fine - how do they flash large image files in Android?
Googling, searching - turns out they use this `make_ext4fs` tool, that creates flashable images. In fact it is part of what I just compiled, so I might as well use it:
Code:
# mkdir /system
# mount -o loop,ro system.img /system
# ls -l /system
total 208
drwxr-xr-x 106 root root 8192 Sep 17 22:24 app
drwxr-xr-x 3 root 2000 8192 Sep 26 21:08 bin
-rw-r--r-- 1 root root 6847 Sep 12 16:59 build.prop
drwxr-xr-x 19 root root 4096 Sep 26 21:08 etc
drwxr-xr-x 2 root root 4096 Aug 11 22:27 fonts
drwxr-xr-x 4 root root 4096 Sep 12 16:56 framework
drwxr-xr-x 10 root root 16384 Sep 12 16:59 lib
drwxr-xr-x 2 root root 4096 Jan 1 1970 lost+found
drwxr-xr-x 3 root root 4096 Aug 11 22:18 media
drwxr-xr-x 59 root root 4096 Aug 11 22:29 priv-app
-rw-r--r-- 1 root root 126951 Aug 1 2008 recovery-from-boot.p
drwxr-xr-x 3 root root 4096 Aug 11 21:02 scripts
drwxr-xr-x 3 root root 4096 Aug 11 21:02 tts
drwxr-xr-x 11 root root 4096 Sep 26 21:08 usr
drwxr-xr-x 8 root 2000 4096 Aug 11 22:29 vendor
drwxr-xr-x 2 root 2000 4096 Sep 26 21:09 xbin
# ../extras/source/extras/ext4_utils/make_ext4fs \
-l 2048M new_system.img /system
Creating filesystem with parameters:
Size: 2147483648
Block size: 4096
Blocks per group: 32768
Inodes per group: 8192
Inode size: 256
Journal blocks: 8192
Label:
Blocks: 524288
Block groups: 16
Reserved block group size: 127
Created filesystem with 2666/131072 inodes and 375014/524288 blocks
Cool - so I can apparently build system images from plain old folders. The sky will be my limit - I'll be able to add anything I want to this image.
Let's burn it...
Code:
# fastboot flash system new_system.img
erasing 'system'...
OKAY [ 0.064s]
sending 'system' (2088960 KB)...
^C
I waited for 1h before hitting that Ctrl-C. And had to power-cycle the tablet, which booted back in fastboot mode.
This is not looking good.
What if I build a smaller image? Maybe the 2GB are somehow an issue, and this partition is not used to full capacity - it has free space:
Code:
# ../extras/source/extras/ext4_utils/make_ext4fs \
-l 1536M new_system.img /system
# ./fastboot flash system system.img
erasing 'system'...
OKAY [ 0.065s]
sending 'system' (1572864 KB)...
OKAY [ 51.039s]
writing 'system'...
OKAY [235.080s]
finished. total time: 286.183s
OK, this looks very promising (and only took 5 min). I guess I can now reboot back and everything should be normal, yes?
No
(sorry, can't paste links yet - see this image: http i stack imgur com U7wiX.png
I don't mind a temporarily bricked device, as long as I **do** get to control it in the end (machines that I am not a master of, are machines I don't care to operate
Any ideas on what I did wrong and what I can do to fix this?
Thanks in advance.
P.S. I checked the Asus support page for my tablet - they only provide the sources for the kernel, and the Over-the-air .zip file. That in turn contains a file-system level backup from the root - i.e. the `system` folder exists in there as just a folder, not an image, not a `system.img` that I can flash - so that doesn't really help me.

[SOLVED] Booted from external sd.
I documented how I solved it in android stack exchange, article 124344 (can't post links - the url is formed from .... http android.stackexchange.com questions 124344 trying-to-flash-a-system-img-i-took-with-dd-failing )
Executive summary - I edited my custom boot image /fstab.qcom to point /system to the external SD card, and dd-ed my image there.

Stuck in the bootloop after flashing data.img on Pixel C device.

Hi,
I am stuck in the bootloop after flashing data.img on Pixel C device.
I have done the following steps and have serached around in 100s of forums before posting this. Please bear with me.
My bootloader is unlocked and I have flashed my boot partition with dragon-boot-encryptable-rooted-01092016-1.img so that the data is not encrypted by default.
I have a freshly booted up (new setup) device with default apps installed. I installed one app so that the /data partition contains something. I am firing all commands as root on Ubuntu 14
I then flashboot into TWRP recovery so that I can access root shell through adb. This is not flashing the TWRP recovery, just booting into it.
#adb reboot bootloader
#fastboot boot twrp-3.0.0-0-dragon-ryu-02112016-1.img
#adb shell
~ # whoami
root
~ # df
Filesystem 1K-blocks Used Available Use% Mounted on
tmpfs 1420244 20 1420224 0% /dev
tmpfs 1420244 20 1420224 0% /tmp
/dev/block/mmcblk0p6 396744 452 388100 0% /cache
/dev/block/mmcblk0p7 55453060 304032 55132644 1% /data
/dev/block/mmcblk0p7 55453060 304032 55132644 1% /sdcard
Now, I am interested only in taking image backup of my /data partition which is at /dev/block/mmcblk0p7. I confirmed this by:
/dev/block/platform/700b0600.sdhci/by-name # ls -l
...
lrwxrwxrwx 1 root root 20 Oct 16 07:38 UDA -> /dev/block/mmcblk0p7
...
Now, I fire the make_ext4fs command to create the image.
~#umount /sdcard (optional)
~ # make_ext4fs -s -l 55453060K -a data mydata.img /data
SELinux: Loaded file_contexts contexts from /file_contexts.
Creating filesystem with parameters:
Size: 56783933440
Block size: 4096
Blocks per group: 32768
Inodes per group: 8176
Inode size: 256
Journal blocks: 32768
Label:
Blocks: 13863265
Block groups: 424
Reserved block group size: 1024
Created filesystem with 11/3466624 inodes and 263660/13863265 blocks
mydata.img is created. I do an adb pull on my Ubuntu and fetch the mydata.img and /file_contexts
#adb pull /file_contexts
#adb pull /mydata.img
# du *
20 file_contexts
140888 mydata.img
Now, I convert the mydata.img into raw image file with simg2img.
#./simg2img mydata.img mydata.img.raw
#ls -lrt
-rw-r--r-- 1 root root 17261 Oct 16 13:17 file_contexts
-rw-r--r-- 1 root root 144267780 Oct 16 13:18 mydata.img
-rw-r--r-- 1 root root 56783933440 Oct 16 13:21 mydata.img.raw
Now, I create a directory and mount my raw image into that directory.
#mkdir phonedata
#mount -t ext4 mydata.img.raw phonedata/
I navigate into phonedata and verify the contents. I can see that the app I installed in avaialable under /data/data.
Then, I re-create the image from phonedata mount using make_ext4fs, or I can use the mydata.img fetch by adb pull too.
If I re-create the image, I give file_contexts(fetched) as the -S option to make_ext4fs. One doubt here, if I am re-creating the sparse image, what value should be passed to -l paramtere now?
I got to fastboot and fire these commands.
#fastboot format userdata
#fastboot format data
#fastboot format cache
#fastboot flash data mydata.img { I am confused between data and userdata, which is the correct one. This is mydata.img from adb pull }
#fastboot flash vendor vendor.img { I read in one forum that vendor should be flashed again on a nexus device }
#fastboot reboot
All things take smoothly. When the tab reboot, it shows Google logo, then android flash animation, then it shows 'Android is starting', and then goes back to flash animation. That is, it's stuck in bootloop.
Kindly let me know if there is something with these steps. Or is there is any alternate way to do the same thing. My problem statement is, I need a flashable data.img. I can create TWRP backup and recovery fine, but that's not my requirement.
Thanks!
Edit 1:
I should add, at this point, if I hard boot to fastboot and do a fastboot format userdata followed by fastboot reboot, I am able to boot to device and perform new device setup.
I can also flash system,boot,vendor,recovery and cache.img and perform new device setup normally. This should mean my fastboot/adb are working fine.

Ummmmm

Did you try with smaller sparse image size ?
make_ext4fs -s -l 30000M -a data mydata.img /data
The sparse will grow until max partition size.
Did you play with "img2simg" as well ? (not simg2img)
img2simg mydata.img.raw mydata.img

init.rc update twrp bootloop

EDIT I FIGURED IT OUT, after some head scratching and studying of magisk 15.3 zip.
Below is how I was able to edit the init.rc:
Required:
Magisk-v15.3.zip
- Magisk-v15.3/arm64/magiskboot
- Magisk-v15.3/chromeos/futility
- Magisk-v15.3/chromeos/kernel.keyblock
- Magisk-v15.3/chromeos/kernel_data_key.vbprivk
*I have to sudo adb, not sure how to have the permissions by default.*
Code:
adb push futility /sdcard/
adb push magiskboot /sdcard/
cp /sdcard/futility /system/bin/
chmod u+x /system/bin/futility
cp magiskboot /system/bin/
chmod u+x /system/bin/magiskboot
mkdir -p /sdcard/initrc
adb push kernel_data_key.vbprivk /sdcard/initrc/
adb push kernel.keyblock /sdcard/initrc/
Old guides on the interwebs tell you that lnx is the partition to unpack / repack flash however if you peek at Magisk-v15.3/common/util_functions.sh
Code:
find_boot_image() {
...
for BLOCK in boot_a kern-a android_boot kernel boot lnx bootimg; do
BOOTIMAGE=`find /dev/block -iname $BLOCK | head -n 1` 2>/dev/null
Because there's a kern-a that's the one you need to use. The above command gets me:
/dev/block/platform/700b0600.sdhci/by-name/KERN-A
The above command also is used to display: "Found boot image: /dev/block/mmcblk0p1" (cat /proc/partitions) during Magisk installation.
Now that I've figured out the boot partition, I'll use magiskboot to unpack it.
Code:
cd /sdcard/initrc
magiskboot --unpack /dev/block/platform/700b0600.sdhci/by-name/KERN-A
MagiskBoot v15.3(1531) (by topjohnwu) - Boot Image Modification Tool
Parsing boot image: [/dev/block/platform/700b0600.sdhci/by-name/KERN-A]
KERNEL [5481552] @ 0x10008000
RAMDISK [1876886] @ 0x11000000
SECOND [0] @ 0x10f00000
EXTRA [0] @ 0x10000100
PAGESIZE [2048]
OS_VERSION [8.1.0]
PATCH_LEVEL [2018-03]
NAME []
CMDLINE [buildvariant=userdebug]
DTB [5481552]
KERNEL_FMT [dtb]
RAMDISK_FMT [gzip]
The unpacking will create dtb, kernel, and ramdisk.cpio. I'll extract the ramdisk.cpio so I can add / edit files.
**NOTE** if you get a permission denied .backup / .subackup just run sudo
Code:
mkdir ramdisk
cd ramdisk
sudo cpio -i -d -m < ../ramdisk.cpio
I'm not sure how to fix this but I was getting:
cpio: bugreports: Operation not permitted
cpio: charger: Operation not permitted
cpio: d: Operation not permitted
cpio: etc: Operation not permitted
cpio: sbin/ueventd: Operation not permitted
cpio: sbin/watchdogd: Operation not permitted
cpio: sdcard: Operation not permitted
I was forced to copy ramdisk.cpio to my computer and extract it, update, and repack it there.
Once you're ready to repack and move the ramdisk back to the pixel c.
Code:
sudo find . | sudo cpio -R 0:0 -H newc -o > ../newramdisk.cpio
mv /sdcard/initrc/ramdisk.cpio /sdcard/initrc/ramdisk.cpio.orig
adb push newramdisk.cpio /sdcard/initrc/ramdisk.cpio
cd /sdcard/initrc && magiskboot --repack /dev/block/platform/700b0600.sdhci/by-name/KERN-A
MagiskBoot v15.3(1531) (by topjohnwu) - Boot Image Modification Tool
Parsing boot image: [/dev/block/platform/700b0600.sdhci/by-name/KERN-A]
KERNEL [5481552] @ 0x10008000
RAMDISK [1876886] @ 0x11000000
SECOND [0] @ 0x10f00000
EXTRA [0] @ 0x10000100
PAGESIZE [2048]
OS_VERSION [8.1.0]
PATCH_LEVEL [2018-03]
NAME []
CMDLINE [buildvariant=userdebug]
DTB [5481552]
KERNEL_FMT [dtb]
RAMDISK_FMT [gzip]
Repack to boot image: [new-boot.img]
KERNEL [5481552] @ 0x10008000
RAMDISK [1879383] @ 0x11000000
SECOND [0] @ 0x10f00000
EXTRA [0] @ 0x10000100
PAGESIZE [2048]
OS_VERSION [8.1.0]
PATCH_LEVEL [2018-03]
NAME []
CMDLINE [buildvariant=userdebug]
This will create "new-boot.img" file. Next we'll need to sign the image. If someone can explain why it's required that would be great.
Code:
cd /sdcard/initrc
echo > empty
futility vbutil_kernel --pack new-boot.img.signed --keyblock ./kernel.keyblock --signprivate ./kernel_data_key.vbprivk --version 1 --vmlinuz new-boot.img --config empty --arch arm --bootloader empty --flags 0x1
Finally flash the signed boot image and reboot
Code:
cat /sdcard/initrc/new-boot.img.signed | eval cat - | cat - /dev/zero 2>/dev/null | dd of=/dev/block/platform/700b0600.sdhci/by-name/KERN-A bs=4096
dd: /dev/block/platform/700b0600.sdhci/by-name/KERN-A: No space left on device
8193+0 records in
8192+0 records out
33554432 bytes transferred in 0.129 secs (260111875 bytes/sec)
---ORIGINAL POST---
Trying to edit init.rc (or anything really in the ramdisk) by unpacking / repacking and flashing but I get stuck in a TWRP 3.2.1-0 bootloop. I've been using the latest unofficial lineage March 8, 2018 from followmsi
I'm not sure if there's an easier way or I'm doing it wrong all the guides out there are from 2012-2014.
With github com/xiaolu/mkbootimg_tools was using the LNX partition but then noticed the SuperSu.zip when installing from TWRP was using KERN-A the mmcblk0p1.
Code:
Unpack & decompress ../boot.img to boot
kernel : kernel
ramdisk : ramdisk
page size : 2048
kernel size : 5463088
ramdisk size : 1594653
base : 0x10000000
kernel offset : 0x00008000
ramdisk offset : 0x01000000
tags offset : 0x00000100
cmd line : buildvariant=userdebug
ramdisk is gzip format.
Unpack completed.
When flashing either of them I get stuck in the bootloop. I've tried fastboot flash boot new_boot.img, dd and cat > when updating the repacked boot image. I also tried fastboot flash:raw boot <kernel> [ <ramdisk> [ <second> ] ] create bootimage and flash it.
When booting the image without flashing via sudo fastboot boot new_boot.img I get stuck on the lineageOS logo before it reboots to recovery TWRP then I have to reboot again to get back into the rom.
I've also tried many other unpacking / packing script tools with no success just bootloops or complaints about invalid boot.img
I don't understand how supersu and magisk zip can have zips run from twrp that are able to edit the ramdisk? Are they running a compiled c program like this? github com/TeamWin/Team-Win-Recovery-Project/blob/8373cfe28cf1b5ad758faa1d502e21787c3665e4/injecttwrp/injecttwrp.c
Probably not relevant (disclaimer couldn't hex edit my way out of a paper bag) but noticed sometimes when repacking with different tools and peeking at the new boot image with ghex that the first line in the original boot was always CHROMEOS but the repacked would say ANDROID! and be just 5-7mb when the boot image backup would be 36mb in size.
Code:
APP -> /dev/block/mmcblk0p4
CAC -> /dev/block/mmcblk0p6
KERN-A -> /dev/block/mmcblk0p1
KERN-B -> /dev/block/mmcblk0p2
LNX -> /dev/block/mmcblk0p9
MD1 -> /dev/block/mmcblk0p8
MSC -> /dev/block/mmcblk0p10
PST -> /dev/block/mmcblk0p11
UDA -> /dev/block/mmcblk0p7
VNR -> /dev/block/mmcblk0p5
recovery -> /dev/block/mmcblk0p3
cat /proc/partitions
Code:
7 0 98304 loop0
254 0 520912 zram0
179 0 61071360 mmcblk0
179 1 32768 mmcblk0p1
179 2 32768 mmcblk0p2
179 3 32768 mmcblk0p3
179 4 3670016 mmcblk0p4
179 5 311296 mmcblk0p5
179 6 409600 mmcblk0p6
179 7 56470528 mmcblk0p7
179 8 65536 mmcblk0p8
179 9 32768 mmcblk0p9
179 10 4096 mmcblk0p10
179 11 512 mmcblk0p11
179 96 4096 mmcblk0rpmb
179 64 4096 mmcblk0boot1
179 32 4096 mmcblk0boot0
253 0 56470528 dm-0