Database Users

[RECOVERY] [WIP] CWM Recovery

Just thought I'd create a place to pool our knowledge and try to get a custom recovery going.
So far I've been able to piece together the partition table using an app from the Play Store. I don't know if it's accurate or not since I'm new at this, so if someone else knows that something is wrong please let me know.
BLOCK- MOUNT- DEVICE NO- LABEL- FILESYSTEM- SIZE (MB)
MMCBLK0 179/0 15028
MMCBLK0P1 /FIRMWARE 179/1 MODEM VFAT 13.5 / 64.0
MMCBLK0P2 179/2 SBL1 0.5
MMCBLK0P3 179/3 SBL2 0.5
MMCBLK0P4 179/4 SBL3 2
MMCBLK0P5 179/5 ABOOT 0.5
MMCBLK0P6 179/6 RPM 0.5
MMCBLK0P7 179/7 BOOT 24
MMCBLK0P8 179/8 TZ 0.5
MMCBLK0P9 179/9 PAD 0
MMCBLK0P10 179/10 MODEMST1 3
MMCBLK0P11 179/11 MODEMST2 3
MMCBLK0P12 179/12 M9KEFS1 0.8
MMCBLK0P13 179/13 M9KEFS2 0.8
MMCBLK0P14 179/14 M9KEFS3 0.8
MMCBLK0P15 /PERSIST-LG 179/15 DRM EXT4 4.3 / 7.9
MMCBLK0P16 /SNS 179/16 SNS EXT4 4.1 / 7.9
MMCBLK0P17 179/17 SSD 0
MMCBLK0P18 179/18 MISC 16
MMCBLK0P19 /FACTORY 179/19 FACTORY EXT4 4.1 / 15.8
MMCBLK0P20 179/20 BNR EXT4 8
MMCBLK0P21 179/21 ENCRYPT 0.5
MMCBLK0P22 179/22 EKSST 0.5
MMCBLK0P23 /SYSTEM 179/23 SYSTEM EXT4 1853.8 / 2113.8
MMCBLK0P24 /CACHE 179/24 CACHE EXT4 14.4 / 788.4
MMCBLK0P25 /PERSIST 179/25 PERSIST EXT4 4.1 / 7.9
MMCBLK0P26 179/26 TOMBSTONES 256
MMCBLK0P27 179/27 RECOVERY 24
MMCBLK0P28 179/28 FSG 3
MMCBLK0P29 179/29 DDR 0
MMCBLK0P30 179/30 FOTA 32
MMCBLK0P31 /MPT 179/31 MPT EXT4 11.5 / 31.5
MMCBLK0P32 259/0 TZBAK 0.5
MMCBLK0P33 259/1 RPMBAK 0.5
MMCBLK0P34 259/2 RCT 0
MMCBLK0P35 259/3 RESERVED 16
MMCBLK0P36 /DATA 259/4 USERDATA EXT4 2260.3 / 11304.5
MMCBLK0P37 259/5 GROW 4
/DEV/FUSE /STORAGE/EMULATED/LEGACY NA/NA EMULATED STORAGE AT /DATA/MEDIA ? FUSE 2260.3 / 11304.5
/DEV/FUSE /STORAGE/EMULATED/0 NA/NA EMULATED STORAGE AT /DATA/MEDIA ? FUSE 2260.3 / 11304.5
/DEV/FUSE /STORAGE/EMULATED/0/ANDROID/OBB NA/NA EMULATED STORAGE AT /DATA/MEDIA ? FUSE 2260.3 / 11304.5
/DEV/FUSE /STORAGE/EMULATED/LEGACY NA/NA EMULATED STORAGE AT /DATA/MEDIA ? FUSE 2260.3 / 11304.5
/DEV/FUSE /STORAGE/EMULATED/LEGACY/ANDROID/OBB NA/NA EMULATED STORAGE AT /DATA/MEDIA ? FUSE 2260.3 / 11304.5
The last bit there is a bit of a head scratcher to me.
I've also extracted the recovery.img from the mmcblk0p27.
https://www.dropbox.com/s/4u9v9dqfzrj5100/recovery.img

Thanks for your effort man, i wouldn't know where to begin with something like this.

Endlessillusion said:
Thanks for your effort man, i wouldn't know where to begin with something like this.
Click to expand...
Click to collapse
Trust me, I didn't either. Just taking it one step at a time. We've got a way to restore to stock, so it's relatively safe if you're patient and don't rush.

mustbepbs said:
Trust me, I didn't either. Just taking it one step at a time. We've got a way to restore to stock, so it's relatively safe if you're patient and don't rush.
Click to expand...
Click to collapse
I don't have my pad yet shipment was delayed until tomorrow. I am going to wait around, will take it nice and slow just happy to see some progress.

This is the working recovery?, you can get root access?

hello e thanks @mustbepbs
can you use this site to create a recovery cwm? builder(dot)clockworkmod(dot)com <--upload recovery image & build the recovery.. we can try to obtain the recovery without attend the job of "team CWM"
edit:
I apologize, I missed the link reading the first post..I saw now.
I now see what we get by loading the recovery image on the site.

Palux said:
hello e thanks @mustbepbs
can you use this site to create a recovery cwm? builder(dot)clockworkmod(dot)com <--upload recovery image & build the recovery.. we can try to obtain the recovery without attend the job of "team CWM"
edit:
I apologize, I missed the link reading the first post..I saw now.
I now see what we get by loading the recovery image on the site.
Click to expand...
Click to collapse
Yeah it doesn't work. A lot of builds are failing on there so I don't know if it's the IMG or their build server.
I synced the CM10.2 repo last night so I'm gonna get started on trying to build from scratch today. Can't make any promises.

Okay, so I got CWM to build and I think I've gotten it right. Basically at this point I've got an update.zip for future reference and a recovery.img from the build. I've got to work in LOKI and see what happens.

Okay, so I patched LOKI and flashed it successfully.
When I adb reboot recovery, I get:
https://www.dropbox.com/s/591cd1a349nqfq0/bootingimage.jpg
It just boots normally after that. I suppose it's progress.

yeah ... thanks for the tests and the work you're doing :highfive:

It remains to unlock the tablet?

Not really sure what went wrong.
CWM built, so I think if there was a problem it wouldn't have built. Loki patched and flashed successfully because of that error message I got.
If something flashed to the wrong place, I wouldn't think I'd be able to boot like I can.
I guess I don't fully understand LOKI. Trying to do as much digging around as I can.

mustbepbs said:
Not really sure what went wrong.
CWM built, so I think if there was a problem it wouldn't have built. Loki patched and flashed successfully because of that error message I got.
If something flashed to the wrong place, I wouldn't think I'd be able to boot like I can.
I guess I don't fully understand LOKI. Trying to do as much digging around as I can.
Click to expand...
Click to collapse
Hi,
It seems we have got the same error. Being new to compiling android i can't be sure my initial configuration (recovery.fstab BoardConfig.mk) were correct. The problem could also be that LG has changed its bootloader and Loki doesn't work anymore as i haven't seen anybody having succesfully tested it on the G Pad.

obiwan86300 said:
Hi,
It seems we have got the same error. Being new to compiling android i can't be sure my initial configuration (recovery.fstab BoardConfig.mk) were correct. The problem could also be that LG has changed its bootloader and Loki doesn't work anymore as i haven't seen anybody having succesfully tested it on the G Pad.
Click to expand...
Click to collapse
From what I've read, getting that error means that LOKI is working. I pulled the recovery.fstab from the stock img so I know that's correct. I may have mucked up a few things in the BoardConfig.mk, I fixed them but was so tired last night that I couldn't focus. Gonna try again today and tomorrow.

has anyone tried this http://www.xda-developers.com/android/compile-twrp-for-your-device/

I haven't tried TWRP yet.

mustbepbs said:
I haven't tried TWRP yet.
Click to expand...
Click to collapse
I don;t know much about development but it looks like they made it easier?

joshuadjohnson22 said:
I don;t know much about development but it looks like they made it easier?
Click to expand...
Click to collapse
I'll take a look if my revised CWM build doesn't work.

Hi, how's it going?. Recently brought a tablet, I would like to recovery

well we should have something soon
just need some time to test

[Q] Qualcomm Secure Boot Weird Issue

##########################################
I NO LONGER HAVE THIS DEVICE, AND WILL NOT BE WORKING ON IT
SEE LAST POST BY MOONBUTT74 FOR USEFUL INFO
##########################################
Hello XDA,
Im going to start with some backstory (hopefully will help find a solution).
I got a galaxy tab 4 8.0" sm-t330nu a few months back extremely cheap and decided to make the jump back to android from (yes im going to say it) apple. So after recieving my tab, I instantly jumped onto xda to find a rooting method and stumbled upon a tutorial similar to this one http://androidxda.com/root-samsung-galaxy-tab-4-8-0-sm-t330nu (i dont think that was it but same process). Got my root on, and enjoyed it for awhile. (Not realizing CF_AUTOROOT trips the knox counter).
About 2 months ago i found kali nethunter, and decided that since i dont own a nexus device and noone has yet built a port for sm-t330nu (as shown by http://forum.xda-developers.com/tab-4/help/request-tutorial-kali-linux-nethunter-t2929079), i would do my best to make a port for my tab (my first ever attempt at any form of android dev).
So i fired up my kali, and got to work. After many small issues (1- http://stackoverflow.com/questions/28970296/c-pointer-type-comparison-in-android-kernel and 2- http://stackoverflow.com/questions/28952868/android-kernel-build-first-time) Ive managed to fully build a vanilla kernel using samsungs opensource code, aswell as a modified and mac80211 patched version (as per https://github.com/offensive-security/kali-nethunter/wiki/Modifying-the-Kernel).
Now onto the issue. I am able to fully flash philz touch recovery and CF_AUTOROOT without any issues through odin, and both show up and are usable afterwards. However, when i attempt to flash ANY rom (stock or modded) the flash runs through fully and seems to finish correctly, but does not actually make any changes at all.
Due to this i decided to try and test my kernel by temp booting it hrough fastboot, and stumbled across a new issue. I am able to send adb commands, BUT when i reboot to bootloader, im taken directly to download mode without an option to get to fastboot, and fastbot does not recognize it in this mode. When in download mode i see this exact information:
ODIN MODE
PRODUCT NAME: SM-T330NU
CURRENT BINARY: CUSTOM
SYSTEM STATUS: CUSTOM
KNOX WARRENTY VOID: 0x1 (4)
QUALCOMM SECURE BOOT: ENABLE (csb)
RP SWREV: S1, T1, R1, A1, P1
UDC START
All of this leads me to believe that in someway my bootloader is only partially locked. It is able to accept certain files only. DOES ANYONE KNOW HOW TO BYPASS THIS CRAP?
Im all excited to test my kernel and unable to do so. :crying:

I,
first, thanks for your question , it was very informative. :good:
as far as i know no samsung wifi-only device has fastboot.
if you can get into recovery, via adb shell force/manually re write your stock kernel image to the correct partition
and work backwards from there which in this case would seem to be to restore the full backup you absolutely positively without a doubt
made.... right?
this is the device's partition layout via adb shell parted /dev/block/mmcblk0 and then print all [philz/cwm]
Code:
~ # 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 all
print all
Model: MMC 016GE2 (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 18.9MB 14.7MB apnhlos
2 18.9MB 71.0MB 52.2MB modem
3 71.0MB 71.6MB 524kB sbl1
4 71.6MB 71.6MB 32.8kB dbi
5 71.6MB 71.6MB 32.8kB ddr
6 71.6MB 73.7MB 2097kB aboot
7 73.7MB 74.3MB 524kB rpm
8 74.3MB 74.8MB 524kB tz
9 74.8MB 75.8MB 1049kB pad
10 75.8MB 86.3MB 10.5MB param
11 86.3MB 101MB 14.7MB ext4 efs
12 101MB 104MB 3146kB modemst1
13 104MB 107MB 3146kB modemst2
14 107MB 118MB 10.5MB boot
15 118MB 128MB 10.5MB recovery
16 128MB 139MB 10.5MB fota
17 139MB 146MB 7331kB backup
18 146MB 149MB 3146kB fsg
19 149MB 149MB 1024B fsc
20 149MB 149MB 8192B ssd
21 149MB 158MB 8389kB ext4 persist
22 158MB 167MB 9437kB ext4 persdata
23 167MB 2579MB 2412MB ext4 system
24 2579MB 2893MB 315MB ext4 cache
25 2893MB 2914MB 21.0MB ext4 hidden
26 2914MB 15.8GB 12.8GB ext4 userdata
the numbers on the left correspond to mmcblk ## so cache is /dev/block/mmcblk0p24
if you haven't hacked out your bootloader, modified your partition layout the above recommend should set you back right[ish]
check your nethunter project's installer/script to see if it modified anything
m

Thank you so much for responding and giving such a concise answer. To be entirely honest though, i believe it may be a little over my head (this is my first android dev project, and i kinda just "jumped in"). From what i understand, your answer is basically a very detailed way to unbrick my device.... should i brick it flashing my kernel? If so then, sadly, Im not quite that far yet lol. At this point My device is a rooted stock 4.4.2 , and i am unable to get my kernel to flash at all (and therefore havent even tried to flash the rom part of nethunter untill kernel is working). Thank you for the information about fastboot however, I didnt realize samsung wifi devices had no such thing. (Spent hours trying to figure out why it would work lol)
Question #1
Since fastboot is not an option, is it possible to temporarily flash my kernel to ram using only adb? (Like you would using fastboot for a "safe" test?)
Question #2
Has any dev, anywhere, ever built a kernel from source for this device and been able to flash it? (as i am unable to flash a "vanilla" kernel from source aswell.)
Question #3
Is there any dev who own this particular tablet (sm-t330nu 4.4.2 KOT49H.T330NUUAU1AND4) who is willing to have a short PM convo with a new aspiring dev.... maybe point me in the right direction with a few things? (im also working on a custom rom in android kitchen http://forum.xda-developers.com/showpost.php?p=60227726&postcount=6)

l8,
hey hey,
from what i am able to decipher, you forgot to account for your kernel modules which are by default as of kitkat and later on in jellybean
located in /system/modules on many/most devices where they used to be packed into the boot image.
You also may have forgotten to account for the device tree binary [dtb] as well, Although there does exist the option during
menuconfig to concatenate the kernel binary and the dtb which resultes in zImage-dtb instead , which might be a route to follow.
The following is my default go-to build script for the kernel which i adjust by source and system/location setup
Code:
#!/bin/bash
rm -frv build
make clean && make mrproper
mkdir -pv build/out/modules/pronto build/out/dt_image
export ARCH=arm
export CROSS_COMPILE=/storage/toolchains/NDK-x86-armeabi-4.6-KK/bin/arm-linux-androideabi-
export STRIP=/storage/toolchains/NDK-x86-armeabi-4.6-KK/bin/arm-linux-androideabi-strip
make msm8226-sec_defconfig VARIANT_DEFCONFIG=msm8226-sec_milletwifiue_defconfig
make menuconfig && wait
clear
make CONFIG_NO_ERROR_ON_MISMATCH=y -j10 && make modules
./tools/dtbTool -o build/out/dt_image/boot.img-dtb -s 2048 -p ./scripts/dtc/ ./arch/arm/boot/
cp arch/arm/boot/*zImage build/out/boot.img-zImage
find -type f -name *.ko -exec cp {} build/out/modules/ \;
ls -al build/out/modules/
cd build/out/modules/
$STRIP --strip-unneeded *.ko
mv wlan.ko pronto/pronto_wlan.ko
cd ../../../
ls -al build/out/modules/ build/out/modules/pronto/ build/out/dt_image/ build/out/
echo Done !
i name this script go , and set it in the top of the kernel source, meaning for example
/kernel-srcs/samsung/sm-t330nu_kk/go
adjust for flavor.
ok adb, the answer is no. if you can get kexec configured properly and working, that might be a better way to go without continually
slaying your system. Additionally you may want to be sure module versioning , forced module load, and forced module unload are set,
As to adb [while in recovery] run adb remount it should be successful, if not jump straight to adb shell
now while in your device remount
mount -o rw,remount /system
provided you have the image on the device already navigate to it's location and dd write the boot kernel image
dd if=boot.img of=/dev/block/mmcblk0p14
quadruple check this command for correctness before executing.
On kali, you may be better served to run a non-gui chrooted linux off of your external sdcard and curl wget or git clone the source
you need to build, and do it natively on your tab through that chroot. The tab can manage it, bot the sm-t53xx and the sm-t33x, the benefit
being a "native" compile [static is good, dynamic blows bubbles] I am actually wondering if you can do some hackery with the nethunter sources
to be specifically keyed/tied in to that chrooted distro?
Lastly two points, be more specific, and, be more specific. :silly:
I can't really know what you ACTUALLY mean by my image won't write and nothing changes.
Your partitions are still intact?
You need the attached tools in your kernel source tools directory
m

Thank you so much for the help!! I had been confusing two seperate issue (one ive figured out for my seperate custom rom http://forum.xda-developers.com/showpost.php?p=60227726&postcount=6, and one youve explained beautifully here for nethunter).
Everything youve explained is completely new to me (and therefor i absolutely missed it lol) Youve given me a whole lot to look into and once again explained it in such a concise way i believe i can follow and hopefully manage to get this working Also youve now given me a whole new project lol Ill be attempting the full nethunter rom, and ill be later attempting a chroot environment as you suggested just to see which runs cleaner. Thank you so much for your help (In my side project custom rom ive added thanks to you at the end of the updater-script for all your help )
Now off to learn!! lol

@l8nit3
hey, i just did a plain straight foward flash of nethunter on my sm-t330nu, i am working on getting the boot.img sorted. Until then
i just flashed back my stock boot image. I used the oneplus image as it's a msm8974 device and mostly "compatible"
i haven't found out anything on prima drivers and monitor mode etc. assuming this is more meant for supported dongles, but the neat thing is else the kali chroot seems to function. doing cross compiles of standard gnu bsd stuff to "fix" android where possible.
the kernel need support for the hid and maybe bluetooth stuff, not sure if the rf stuff actually matters without a dongle which i'm just not getting,
but the point of this drive by posting is with a little mod to the issues boot.img and inclusion of modules i don't think a full build of nethunter for these devices [the qcom/msm variety] is really needed.
m

[Guide] Repartition Nexus7(2013) to increase system partition - Extra Space for Rom

Hi, this is my first time posting here. I noticed there is no guide to increase the system partition size in Nexus 7 (2013). The system partition is only around 880MB making it impossible to flash new ROMs and large package of GApps. This guide is for Nexus 7 (2013) wifi 32GB but it should work for other Nexus 7 (2013) editions and even Nexus 7 (2012) with some numbers changed.
My guide is based on this guide for Nexus 5. Check it out. The only issue with Nexus 7 is that the recovery partition is between the system and userdata partitions in the partition table. So deleting the partitions (which includes recovery partition) and then recreating them with offsets might leave your tablet bricked. If you have a way to unbrick the tablet or you are manly enough, you can try the guide written in the next comment. I haven't tested it. Leave a comment if it works. Anyway from the Nexus 5 guide:
The high-level procedure here is, since filesystems must be contiguous and in order so they can be addressed properly, we need to delete every partition inclusively from system to userdata, then recreate them with new storage offsets.
Click to expand...
Click to collapse
This part is not very accurate. I am not sure about Nexus 5 but in Nexus 7, I have changed the order with great success. Only thing is that you need to restart at the end so that the recovery mode updates the mounting configuration. I am not sure if it works with the stock ROM but it definitely works with a custom ROM.
The downside of my way is that you end up with around 880MB unused memory. You can give it to the cache partition. Otherwise, you have to do the untested one in the next comment.
Before we start, I am not liable if it doesn't work or makes your device unusable. The tested guide below works for me.
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
Tested Guide starts here:
Prerequisite:
1. PC (any OS) with adb and fastboot
2. Nexus 7 with TWRP recovery connected to the PC via USB.
3. Get parted from iwf1.com/iwf-repo/parted.rar and extract it into any directory
4. (Optional) System and userdata partitions are wiped out. So backup system and/or data partitions using TWRP recovery
Steps:
1. Open TWRP recovery mode in Nexus 7. Make sure to have the system partition read/write.
2. Go to mount and unmount all partitions you are going to modify (for now system and data).
3. Open PC's command line in parted's directory
4. The next steps are on the command line unless stated:
Code:
adb push parted /
adb shell
~ # chmod +x parted
~ # /parted /dev/block/mmcblk0
(parted): unit b
(parted): p
I used unit b to get partition sizes in bytes. So you can resize accurately this way. You will get the following partition table by default. Keep a copy of this partition table (and one with unit compact for easy readability) as reference if you mess up or want to restore to default.
Code:
Number Start End Size File system Name Flags
1 67108864B 156745727B 89636864B fat16 radio
2 201326592B 204472319B 3145728B modemst1
3 204472320B 207618047B 3145728B modemst2
4 268435456B 283795455B 15360000B ext4 persist
5 335544320B 336343039B 798720B m9kefs1
6 336343040B 337141759B 798720B m9kefs2
7 402653184B 403451903B 798720B m9kefs3
8 403451904B 406597631B 3145728B fsg
9 469762048B 471298047B 1536000B sbl1
10 471298048B 472834047B 1536000B sbl2
11 472834048B 474931199B 2097152B sbl3
12 474931200B 480174079B 5242880B aboot
13 480174080B 480698367B 524288B rpm
14 536870912B 553648127B 16777216B boot
15 603979776B 604504063B 524288B tz
16 604504064B 604505087B 1024B pad
17 604505088B 606041087B 1536000B sbl2b
18 606041088B 608138239B 2097152B sbl3b
19 608138240B 613381119B 5242880B abootb
20 613381120B 613905407B 524288B rpmb
21 613905408B 614429695B 524288B tzb
22 671088640B 1551892479B 880803840B ext2 system
23 1551892480B 2139095039B 587202560B ext4 cache
24 2147483648B 2148532223B 1048576B misc
25 2214592512B 2225078271B 10485760B recovery
26 2281701376B 2281709567B 8192B DDR
27 2281709568B 2281717759B 8192B ssd
28 2281717760B 2281718783B 1024B m9kefsc
29 2348810240B 2348843007B 32768B metadata
30 2415919104B 31272713727B 28856794624B ext4 userdata
5. Rename the system partition to disable it
Code:
(parted): name 22 unused1
6. Now you need to delete userdata partition:
Code:
(parted): rm 30
7. You need to create 2 primary partitions in place of userdata. First one will be the system partition. Second one will be the userdata partition. I recommend to have the system partition to start with the same byte userdata started and size divisible by 4096 bytes. Leave some space between the 2 divisible by 4096 bytes (block-size). Then have userdata partition start with a number divisible by 4096 bytes, size divisible by 512 bytes and ends where user data ended. I increased my system partition to around 2.93GiB (you can resize it whatever you want). I don't really need a lot of userdata. So my configuration would be:
Code:
(parted): mkpart primary 2415919104B 5570068479B
(parted): mkpart primary 5637144576B 31272713727B
8. Now you need to rename these 2 partitions:
Code:
(parted): name 30 system
(parted): name 31 userdata
(parted): p
9. Finally you need to create ext4 filesystem for system and userdata.
Code:
(parted): quit
~ # mke2fs -b 4096 -T ext4 /dev/block/mmcblk0p30
~ # mke2fs -b 4096 -T ext4 /dev/block/mmcblk0p31
~ # /parted /dev/block/mmcblk0 p
10. Have a final look at the partition table to see if everything is correct. Then Reboot into Recovery. This is a very important step. The mount configuration (/etc/fstab) doesn't update until you reboot.
Code:
~ # exit
adb reboot recovery
Done! You have a new system partition with a larger size ready for a ROM. The Size of the ROM will shrink after flashing a new ROM, Using TWRP, Wipe -> Advanced Wipe -> select system -> Resize File System -> Swipe.
Note: You might need to wipe cache/dalvik (might need wipe system too for mount to work), then unmount and remount system/cache/data for everything to work (for example, I had tablet's internal storage not showing on PC initially). But once everything works, it will always work
Final partition table looks like this:
Code:
Number Start End Size File system Name Flags
1 67.1MB 157MB 89.6MB fat16 radio
2 201MB 204MB 3146kB modemst1
3 204MB 208MB 3146kB modemst2
4 268MB 284MB 15.4MB ext4 persist
5 336MB 336MB 799kB m9kefs1
6 336MB 337MB 799kB m9kefs2
7 403MB 403MB 799kB m9kefs3
8 403MB 407MB 3146kB fsg
9 470MB 471MB 1536kB sbl1
10 471MB 473MB 1536kB sbl2
11 473MB 475MB 2097kB sbl3
12 475MB 480MB 5243kB aboot
13 480MB 481MB 524kB rpm
14 537MB 554MB 16.8MB boot
15 604MB 605MB 524kB tz
16 605MB 605MB 1024B pad
17 605MB 606MB 1536kB sbl2b
18 606MB 608MB 2097kB sbl3b
19 608MB 613MB 5243kB abootb
20 613MB 614MB 524kB rpmb
21 614MB 614MB 524kB tzb
22 671MB 1552MB 881MB ext2 unused1
23 1552MB 2139MB 587MB ext4 cache
24 2147MB 2149MB 1049kB misc
25 2215MB 2225MB 10.5MB recovery
26 2282MB 2282MB 8192B DDR
27 2282MB 2282MB 8192B ssd
28 2282MB 2282MB 1024B m9kefsc
29 2349MB 2349MB 32.8kB metadata
30 2416MB 5570MB 3154MB ext2 system
31 5637MB 31.3GB 25.6GB ext4 userdata
To increase cache size:
You have 880MB unused storage from the old system partition. You can keep it the way it is as you have the old system partition here which can be re-enabled quickly in the future. OR You can give this unused partition to the cache partition without messing around a lot. I recommend keeping a small unused partition in place of the old system partition to avoid messing with the order of recovery partition.
Code:
adb push parted /
adb shell
~ # chmod +x parted
~ # /parted /dev/block/mmcblk0
(parted): unit b
(parted): p
(parted): rm 22
(parted): rm 23
(parted): mkpart primary 671088640B 671096831B
(parted): mkpart primary 671096832B 2139095039B
(parted): name 22 unused1
(parted): name 23 cache
(parted): p
(parted): quit
~ # mke2fs -b 4096 -T ext4 /dev/block/mmcblk0p23
~ # quit

Edit: Deleted

rkhat said:
If you have a way to unbrick the tablet or you are manly enough, you can try the guide...
I haven't tested it. Leave a comment if it works.
Click to expand...
Click to collapse
No, there is no way to unbrick the tablet.
Here is a likely comment "So I took the jump in the name of exploration, and bricked my tablet"
Now, are you manly enough to try your own guide?
/EDIT 1
2018 - Unbricking method is available.
/EDIT 2
Here is a Non-destructive repartition script which you can simply 'install' from TWRP.

k23m said:
No, there is no way to unbrick the tablet.
Here is a likely comment "So I took the jump in the name of exploration, and bricked my tablet"
Now, are you manly enough to try your own guide?
Click to expand...
Click to collapse
If you checked the comment write below the second link, you will see a link to a repair option with RIFF JTAG box (costs >100$). I am not going to invest into a repair kit on a device that is probably worth less than the box, but hopefully someone who has the box and tablet can test the solution in the "name of exploration" and help others
Anyway, I am going to buy a chromebook in a year. Tablet market is dead. I might try the second solution on the N7 if some realtive doesn't steal it.

Didn't know that parted on works on android partitions in the way you describe.
My n7 2013 is in pretty bad shape, it has severe touch screen problems which sucks (its gone back to ASUS three times! pretty much gave up... haha they don't want to see it again).
So maybe I'll be game enough to try out the guide someday, but not today

There are something strange after I follow this guide.
If I copy files to /system and /system usage space is over 1GB.
/system will become read-only and mount as ro.
I try to remount /system as rw. But if I copy files into /system, it will become ro again.
Only I can do is format /system. Anyone can help?
Thanks.

I assume to do this you only need custom recovery and root?

OK, I've done the repartitioning. Looks good.
But, I can't seem to flash via TWRP. I try to side-load ROM and I see:
detecting filesystem ext4 for ...
Patching system image unconditionally...
E1001: Failed to update system image.
Updater process ended with error: 7
Any ideas?

RedBullet said:
OK, I've done the repartitioning. Looks good.
But, I can't seem to flash via TWRP. I try to side-load ROM and I see:
detecting filesystem ext4 for ...
Patching system image unconditionally...
E1001: Failed to update system image.
Updater process ended with error: 7
Any ideas?
Click to expand...
Click to collapse
Which ROM did you use? I don't think it works with stock ROM. I use lineageOS.
Btw if you attempt to update the ROM instead of reinstalling it, the system partition will shrink back and you can't use the following step to fix it:
The Size of the ROM will shrink after flashing a new ROM, Using TWRP, Wipe -> Advanced Wipe -> select system -> Resize File System -> Swipe.
Click to expand...
Click to collapse
I found a solution to skip this whole resizing step. I am going to post it after some testing.

rkhat said:
Which ROM did you use? I don't think it works with stock ROM. I use lineageOS.
Btw if you attempt to update the ROM instead of reinstalling it, the system partition will shrink back and you can't use the following step to fix it:
I found a solution to skip this whole resizing step. I am going to post it after some testing.
Click to expand...
Click to collapse
Yea, I was flashing lineage. I eventually got it. I wonder if my partition shrunk back also... What's easiest way to check?
Oh and what do you mean by update vs re-install? I am just flashing via sideload

RedBullet said:
Yea, I was flashing lineage. I eventually got it. I wonder if my partition shrunk back also... What's easiest way to check?
Oh and what do you mean by update vs re-install? I am just flashing via sideload
Click to expand...
Click to collapse
Use parted to print the partition table. First four steps in my guide. Then check the system partition. If it's like the original size, it shrank.
LineageOS supports updating. Let's say you are now on LineageOS 20170801. You want to update to 20170829. When you sideload the newer version, it will attempt to update the previous version (basically only update the differences between the 2 versions). You retain any modification to the system partition (like gapps). Reinstalling means you wipe the system partition then sideload the ROM.
So when updating LineageOS, the system partition will shrink again and I wasn't able to resize it back. Thus corrupting the system partition.

would it not be easier/safer to use parted's resize command to shrink the userdata partition, and then use the move command to move partition 23-29, and then use the resize command again to increase the size of the system partition?

theistus said:
would it not be easier/safer to use parted's resize command to shrink the userdata partition, and then use the move command to move partition 23-29, and then use the resize command again to increase the size of the system partition?
Click to expand...
Click to collapse
I don't think you can do it with parted's move command because according to move's documentation, these are the only supported formats:
ext2 (provided the destination partition is larger than the source partition)
fat16, fat32
linux-swap
reiserfs (if libreiserfs is installed)
Click to expand...
Click to collapse
Partitions 24-29 don't use a file system supported by parted. They definitely contain data (for example recovery partition has your twrp recovery image ).
I think there is a way to do what you are suggesting. In fact, the solution in my 2nd post was about moving the partitons. However, the solution had a mistake which is why I removed it. I had to use dd command to move all the bytes from the old partition to the new partition.
Also, it is somewhat risky. If you do any mistake with the recovery partition (not sure about the other 5 partitions), you pretty much bricked the tablet. If I had anyway to unbrick it, I would do it. Since not, better lose the 840MB.

rkhat said:
I don't think you can do it with parted's move command because according to move's documentation, these are the only supported formats:
Partitions 24-29 don't use a file system supported by parted. They definitely contain data (for example recovery partition has your twrp recovery image ).
I think there is a way to do what you are suggesting. In fact, the solution in my 2nd post was about moving the partitons. However, the solution had a mistake which is why I removed it. I had to use dd command to move all the bytes from the old partition to the new partition.
Also, it is somewhat risky. If you do any mistake with the recovery partition (not sure about the other 5 partitions), you pretty much bricked the tablet. If I had anyway to unbrick it, I would do it. Since not, better lose the 840MB.
Click to expand...
Click to collapse
Yeah, that's the one that scares me. That recovery partition is smack dab in the middle, and it's very ... inconvenient.

Anyone try this with the Nexus 7 2013 LTE version?

better 64gb
https://forum.xda-developers.com/picture.php?albumid=14541&pictureid=56454

Rather than move the system partition, I just moved the cache partition ahead of userdata and extended my system partition by 587MB. This allowed me to keep the same partition numbers and have no unused space.
And after flashing an image if you want to extend the logical drive to fill the partition manually, the command is:
Code:
resize2fs -f /dev/block/mmcblk0p22

Magendanz said:
Rather than move the system partition, I just moved the cache partition ahead of userdata and extended my system partition by 587MB. This allowed me to keep the same partition numbers and have no unused space.
Click to expand...
Click to collapse
Could you explain a bit more how to do that ?
I have read on a few websites that Android Oreo doesn't use the cache partition anymore. If this is true, could it also be simply removed instead of moved ?

Non-destructive repartition script
rkhat said:
The only issue with Nexus 7 is that the recovery partition is between the system and cache partitions in the partition table.
Code:
Number Start End Size File system Name Flags
22 671088640B 1551892479B 880803840B ext2 system
23 1551892480B 2139095039B 587202560B ext4 cache
24 2147483648B 2148532223B 1048576B misc
25 2214592512B 2225078271B 10485760B recovery
Click to expand...
Click to collapse
Have another look at the table - recovery is not between the system and cache partitions.
k23m said:
No, there is no way to unbrick the tablet.
Click to expand...
Click to collapse
I wrote it a year ago, but now we do have a way to unbrick the tablet, so read on and feel free to experiment
wline said:
I have read on a few websites that Android Oreo doesn't use the cache partition anymore. If this is true, could it also be simply removed instead of moved ?
Click to expand...
Click to collapse
Good point. N7's cache is oversized anyway, all my relatively new Xiaomi phones use only 256MB cache. There is no need for complex re-partitioning if we opt for decreased cache. I just did this...
Code:
Number Start End Size File system Name Flags
22 640MiB 1780MiB 1140MiB ext2 system
23 1780MiB 2040MiB 260MiB ext4 cache
24 2048MiB 2049MiB 1.00MiB misc
25 2112MiB 2122MiB 10.0MiB recovery
Code:
Filesystem Size Used Available Use% Mounted on
/dev/block/mmcblk0p30
26.4G 7.0G 19.4G 27% /data
/dev/block/mmcblk0p22
1.1G 607.0M 517.3M 54% /system
/dev/block/mmcblk0p23
258.8M 19.0M 226.7M 8% /cache
Now I have 1.1GB non-destructively resized system and 260MB cache. No changes to other partitions and original OS still works without any backup/restore. It was only a test because personally I have no need for larger system partition. I install LineageOS with pico gapps and later add other Google apks as non-system in the data partition space. I attached a script for the 1.1GB/260MB re-partition. While it is non-destructive, you should do a backup and copy it to your PC first.
Use the latest TWRP and just install sysrepart.zip. The script will create a backup of your original gpt partition table and a log file in the root of internal storage. If you have any issues, post the log.
If you wish to restore original partitioning, install sysrepartundo.zip. This script will attempt to non-destructively resize system again but if you installed some mega-gapps, it will obviously fail. In this case, use TWRP and manually format the system partition, then restore system's backup.
:good:

k23m said:
Have another look at the table - recovery is not between the system and cache partitions.
Click to expand...
Click to collapse
That was a typo. It should be between system and userdata because I am taking from userdata to increase the system partition. I'll edit the main post.
k23m said:
I wrote it a year ago, but now we do have a way to unbrick the tablet, so read on and feel free to experiment
Click to expand...
Click to collapse
Is your guide for soft-unbrick only?
I don't think fastboot can resize or rename a partition. So if you resized the recovery partition to a smaller size or forgot to name a partition "recovery", will your solution be able to handle these situations?

[GUIDE][WORK IN PROGRESS]Oneplus one - resize system partition and maybe even more

WARNING!!!​Everyone is responsible for the proper functioning of their device. This guide is the result of personal experiments and I'm not responsible for any damage caused to your device as a result of improper use of its contents.
Introduction
Stock partitions layout has a 1.3Gb /system partition that is too small for users that flash modern custom roms + some kinds of google apps.
This is a step by step guide to change the layout of the partitions table with a bigger /system partition.
How
On OnePlus One, stock partition table looks like the following
Code:
... ... ...
/dev/block/mmcblk0p14 : start= 294912, name="system"
/dev/block/mmcblk0p15 : start= 3006464, name="persist"
/dev/block/mmcblk0p16 : start= 3072000, name="cache"
... ... ...
/dev/block/mmcblk0p28 : start= 4521984, name="userdata"
/dev/block/mmcblk0p29 : start= 121552896, name="grow"
With this layout, resizing the /system partition may seem difficult because it's close to other very important partitions.
So I've experimented with another approach. By resizing userdata partition, and relocate the /system partition at the beginning of the resulting free space, other partitions are left untouched.
There are mainly two (little) issues
almost all custom roms out of there assume that /system partition is 1.3gb of size
on internal storage the old area of /system partition are unused.
For the first point, the solution is to resize the filesystem when you first flash a custom rom. To automatically resize filesystem at every update there is an addon.d script.
For the second point the new free space available (the old 1.3G /system partition) can be used as a new /cache partition.
And, again, the new free space available (the old /cache partition) can be the famous /vendor partition (that is out of the scope of this guide).
This guide uses the sfdisk tool from util-linux. In my opinion, it's more powerful than parted and it's easy to use via script.
IMPORTANT - Before you start
Obviously, this method is destructive regarding userdata partition, so make a full backup of your data.
Manually resizing filesystem of /system partition is needed only once because the addon.d script will ensure that everything works as expected. The only exception is when you wipe /system and flash a new rom
Prerequisites
a working TWRP recovery installed on device
knowledge of adb tools
a statically cross compiled sfdisk tool (you can self compile, or use the one attached below)
this addon.d script (thanks to @osmosis)
flashable zip of a custom rom (and optionally gapps, magisk etc etc etc)
flashable zip bacon-resize-system.zip (attached on this post)
Let's go
enter TWRP recovery and connect phone on a PC
push sfdisk into a temporary dir and ensure is executable
Code:
adb push sfdisk-arm /tmp
adb shell
cd /tmp
chmod 755 sfdisk-arm
make and pull a backup of your partition table (there is also the 64Gb stock layout in attachments)
Code:
./sfdisk-arm -d /dev/block/mmcblk0 > bacon.gpt
exit
adb pull /tmp/bacon.gpt
looking into the partition table you see that userdata partition starts at sector 4521984.
So in order to resize partition (for example 53G instead of 55,8G).
Code:
adb shell
cd /tmp
umount /data
umount /sdcard
echo "4521984,53G" | ./sfdisk-arm --no-reread -N 28 /dev/block/mmcblk0
. Scrolling down the output of this command the new userdata partition is
Code:
Device Start End Sectors Size Type
/dev/block/mmcblk0p28 4521984 115671039 111149056 53G unknown
so the start sector of /system partition will be 115671040 (115671039+1)
relocating system partition at the end of the new userdata partition(size now will be 2,8G)
Code:
echo "115671040,+" | ./sfdisk-arm --no-reread -N 14 /dev/block/mmcblk0
reboot recovery (kernel need to reload partition table)
Code:
reboot recovery
format userdata with TWRP(no wipe... full format)
push custom rom with adb and flash with TWRP (without rebooting)
flash bacon-resize-system.zip
finish.. you can now reboot or continue with flashing gapps, magisk etc etc (but now with a bigger system partition)
Rollback
TODO
Nice to have
flashable zip for addon.d script (WIP)(DONE)

[*] looking into the partition table you see that userdata partition starts at sector 4521984.
So in order to resize partition (for example 53G instead of 55,8G).
Code:
adb shell
cd /tmp
umount /data
umount /sdcard
echo "4521984,53G" | ./sfdisk-arm --no-reread -N 28 /dev/block/mmcblk0
Click to expand...
Click to collapse
If I understand correctly, the system partition will now be 2.8 GB larger. So it will have a total of about 4.1 GB. Is that so?
BTW this is very good work. :good::good::good::good:

BoquinhaSK said:
If I understand correctly, the system partition will now be 2.8 GB larger. So it will have a total of about 4.1 GB. Is that so?
Click to expand...
Click to collapse
the /system partition are 'moved' at the end of the resized userdata partition.. so it's only 2.8G
I've made this decision for two reasons
no needs to move critical partitions
the unused space (the old /system partition) can be used in another way(for example a larger cache partition or a vendor partition)
BoquinhaSK said:
BTW this is very good work.
Click to expand...
Click to collapse
Thanks a lot
Michele
EDIT: another reason for this method is that almost all custom roms works

I have one small problem. Internal storage (/sdcard) I haven't defined. Is it defined as "Invalid partition selection." Full storage is for /data.
How I can mount /sdcard?
Edit: I mean this: /sdcard, /storage/emulated/0, /data/media/0
I changed partition system to ext2 in TWRP.
And system partition si bigger. This works.
Edit2:
I have problem with flash new ROM. Flashing change filesystem from ext2 to ext4 always with smaller previous value. I have problem maybe with script. But I try it again tomorrow.

BoquinhaSK said:
I have one small problem. Internal storage (/sdcard) I haven't defined. Is it defined as "Invalid partition selection." Full storage is for /data.
How I can mount /sdcard?
Edit: I mean this: /sdcard, /storage/emulated/0, /data/media/0
Click to expand...
Click to collapse
after formatting /data the filesystem is empty.. these directories are created when you first start android(if not found)
BoquinhaSK said:
Edit2:
I have problem with flash new ROM. Flashing change filesystem from ext2 to ext4 always with smaller previous value.
Click to expand...
Click to collapse
This is normal. Starting from nougat/oreo the building process of an android system creates a block-based flashable zip.
This means that the system partition is preformatted in ext4 and (for Oneplus One) with a size of 1.3G (the original /system partition). So you cannot change the type of filesystem.
BoquinhaSK said:
I have problem maybe with script. But I try it again tomorrow.
Click to expand...
Click to collapse
Check if the script has the right permission (I'll update the guide).
Also keep in mind that, like others addon.d scrips, it works only with the OTA updater.
If you flash directly from recovery (changing rom, or dirty flash) you need to manually repeat the steps described for resizing partition and installing the script.
I've planned to create a flashable zip to automate these steps.
Thanks
Michele

little update... I've uploaded a simple flashable zip that resize filesystem of /system partition and install the addon.d script.
The procedure now is more simpler.

ilmich said:
little update... I've uploaded a simple flashable zip that resize filesystem of /system partition and install the addon.d script.
The procedure now is more simpler.
Click to expand...
Click to collapse
Hi ilmich, I followed your guide while flashing LOS 17.1 on my OPO and this allowed me to have a /system partition large enough to be able to have a large GApps installation, so cheers for that! However, I installed an OTA update on LOS 17.1 today (29/10 update) and that rebooted to TWRP which seemed to have installed the zip, but then entered a boot loop with several "Could not find x for ctl.interface_start" on the dmesg log. I can see the resizesystem script in the addon.d folder but something must've gone wrong because the partitions seem to have been restored to its default and /system seems to be 1.3GB again in TWRP. I will pull the partition table and post it here.
Update:
I was wrong, /system seems to be the same size on running sfdisk. The cause of the update fail must be somewhere else. Here's the /system partition from sfdisk:
Code:
/dev/block/mmcblk0p14 : start= 115671040, size= 5881856, type=EBD0A0A2-B9E5-4433-87C0-68B6B72699C7, uuid=B17FA16F-3B1D-8D12-329D-88B49B096554, name="system", attrs="GUID:60"
I still don't understand why TWRP displays /system as 1303MB again though. Any idea?

Still working...?
Are you still working on this guide?
I'ld love to try it, but I'm a little frightened since there seem to be issues about future udates of Lineage (see previous post).

Zyndstoff said:
Are you still working on this guide?
I'ld love to try it, but I'm a little frightened since there seem to be issues about future udates of Lineage (see previous post).
Click to expand...
Click to collapse
Sorry for the late reply. For sure, but for now, I don't have with me my opo.
But if I understand correctly
BoquinhaSK said:
Update:
I was wrong, /system seems to be the same size on running sfdisk. The cause of the update fail must be somewhere else.
Click to expand...
Click to collapse
update problems are not the repartition procedure.
BoquinhaSK said:
I still don't understand why TWRP displays /system as 1303MB again though. Any idea?
Click to expand...
Click to collapse
I suppose that TWRP is built with 1.3Gb size limit (like everything that is based on opo device tree) and without mounting the filesystem show this static value.
But the power of this procedure (and the resize script) is that you can safely install your preferred rom. The filesystem is expanded in order to fill the 'new' partition size.
During my experiments, I've updated a lineage os (also simulating OTA by pushing a recovery command into the /cache partition), with and without GAPPS.
This guide, if executed step by step, should be safe.

I'm testing again my procedure. This is my situation
Code:
bacon:/ $ df -h
Filesystem Size Used Avail Use% Mounted on
/dev/block/mmcblk0p14 2.7G 1.0G 1.7G 38% /
/dev/block/mmcblk0p28 52G 15G 37G 30% /data
I've latest official lineageos with some Gapps.
Now I'm waiting for an official OTA to see if anything goes wrong.

Hi all,
I've uploaded a new bacon-resize-system.zip that fixes the issue with OTA (wrong escape sequence when creating survival script in the updater binary).
Thanks all for the bug report.
Cheers
Michele

ilmich said:
Hi all,
I've uploaded a new bacon-resize-system.zip that fixes the issue with OTA (wrong escape sequence when creating survival script in the updater binary).
Thanks all for the bug report.
Cheers
Michele
Click to expand...
Click to collapse
Hello sir,
I am still using OPO in 2021 and i want 5gb system partition.. What will be start and end sectors for that changes? I am really confused so can you please recreate your post for 5gb and will you post it in reply?
Another one question if i flashed stock rom via fastboot then it will restore partition size to default or changes still remain which we did?
Thank You.

pbankar7 said:
Hello sir,
I am still using OPO in 2021 and i want 5gb system partition.. What will be start and end sectors for that changes? I am really confused so can you please recreate your post for 5gb and will you post it in reply?
Another one question if i flashed stock rom via fastboot then it will restore partition size to default or changes still remain which we did?
Thank You.
Click to expand...
Click to collapse
Code:
adb shell
cd /tmp
umount /data
umount /sdcard
echo "4521984,51G" | ./sfdisk-arm --no-reread -N 28 /dev/block/mmcblk0
After that
Code:
Device Start End Sectors Size Type
/dev/block/mmcblk0p28 4521984 111476735 106954752 51G unknown
After this
Code:
echo "111476736,+" | ./sfdisk-arm --no-reread -N 14 /dev/block/mmcblk0
Am I right for 4.8gb??
Please answer of this 2 questions
1. If i flashed stock rom via fastboot then it will restore partition size to default or changes still remains which we did?
2. It is necessary to flash bacon-resize-system.zip everytime whenever we flash new custom rom or after ota updates?
Thank You.

ilmich said:
WARNING!!!​Everyone is responsible for the proper functioning of their device. This guide is the result of personal experiments and I'm not responsible for any damage caused to your device as a result of improper use of its contents.
Introduction
Stock partitions layout has a 1.3Gb /system partition that is too small for users that flash modern custom roms + some kinds of google apps.
This is a step by step guide to change the layout of the partitions table with a bigger /system partition.
How
On OnePlus One, stock partition table looks like the following
Code:
... ... ...
/dev/block/mmcblk0p14 : start= 294912, name="system"
/dev/block/mmcblk0p15 : start= 3006464, name="persist"
/dev/block/mmcblk0p16 : start= 3072000, name="cache"
... ... ...
/dev/block/mmcblk0p28 : start= 4521984, name="userdata"
/dev/block/mmcblk0p29 : start= 121552896, name="grow"
With this layout, resizing the /system partition may seem difficult because it's close to other very important partitions.
So I've experimented with another approach. By resizing userdata partition, and relocate the /system partition at the beginning of the resulting free space, other partitions are left untouched.
There are mainly two (little) issues
almost all custom roms out of there assume that /system partition is 1.3gb of size
on internal storage the old area of /system partition are unused.
For the first point, the solution is to resize the filesystem when you first flash a custom rom. To automatically resize filesystem at every update there is an addon.d script.
For the second point the new free space available (the old 1.3G /system partition) can be used as a new /cache partition.
And, again, the new free space available (the old /cache partition) can be the famous /vendor partition (that is out of the scope of this guide).
This guide uses the sfdisk tool from util-linux. In my opinion, it's more powerful than parted and it's easy to use via script.
IMPORTANT - Before you start
Obviously, this method is destructive regarding userdata partition, so make a full backup of your data.
Manually resizing filesystem of /system partition is needed only once because the addon.d script will ensure that everything works as expected. The only exception is when you wipe /system and flash a new rom
Prerequisites
a working TWRP recovery installed on device
knowledge of adb tools
a statically cross compiled sfdisk tool (you can self compile, or use the one attached below)
this addon.d script (thanks to @osmosis)
flashable zip of a custom rom (and optionally gapps, magisk etc etc etc)
flashable zip bacon-resize-system.zip (attached on this post)
Let's go
enter TWRP recovery and connect phone on a PC
push sfdisk into a temporary dir and ensure is executable
Code:
adb push sfdisk-arm /tmp
adb shell
cd /tmp
chmod 755 sfdisk-arm
make and pull a backup of your partition table (there is also the 64Gb stock layout in attachments)
Code:
./sfdisk-arm -d /dev/block/mmcblk0 > bacon.gpt
exit
adb pull /tmp/bacon.gpt
looking into the partition table you see that userdata partition starts at sector 4521984.
So in order to resize partition (for example 53G instead of 55,8G).
Code:
adb shell
cd /tmp
umount /data
umount /sdcard
echo "4521984,53G" | ./sfdisk-arm --no-reread -N 28 /dev/block/mmcblk0
. Scrolling down the output of this command the new userdata partition is
Code:
Device Start End Sectors Size Type
/dev/block/mmcblk0p28 4521984 115671039 111149056 53G unknown
so the start sector of /system partition will be 115671040 (115671039+1)
relocating system partition at the end of the new userdata partition(size now will be 2,8G)
Code:
echo "115671040,+" | ./sfdisk-arm --no-reread -N 14 /dev/block/mmcblk0
reboot recovery (kernel need to reload partition table)
Code:
reboot recovery
format userdata with TWRP(no wipe... full format)
push custom rom with adb and flash with TWRP (without rebooting)
flash bacon-resize-system.zip
finish.. you can now reboot or continue with flashing gapps, magisk etc etc (but now with a bigger system partition)
Rollback
TODO
Nice to have
flashable zip for addon.d script (WIP)(DONE)
Click to expand...
Click to collapse
I'm interested in installing Ubuntu touch on my OnePlus One but since I used this guide successfully to resize my system partition I don't think I can install it without restoring the partition tables. How can I restore the partitions properly without bricking my phone?

Hi all. Please help.
I ruined my OPO phone.
iI followed the steps correctly.
After reboot the system partition cannot mount.
I see in the log:
Failed to mount '/system' (invalid argument)
My GPT after the change:
/tmp # fdisk -l /dev/block/mmcblk0
Found valid GPT with protective MBR; using GPT
Disk /dev/block/mmcblk0: 122142720 sectors, 2296M
Logical sector size: 512
Disk identifier (GUID): 98101b32-bbe2-4bf2-a06e-2bb33d000c20
Partition table holds up to 32 entries
First usable sector is 34, last usable sector is 122142686
Number Start (sector) End (sector) Size Code Name
1 16384 147455 64.0M 0700 modem
2 147456 148479 512K 0700 sbl1
3 148480 148543 32768 0700 dbi
4 163840 163903 32768 0700 DDR
5 180224 182271 1024K 0700 aboot
6 182272 183271 500K 0700 rpm
7 196608 229375 16.0M 0700 boot
8 229376 230375 500K 0700 tz
9 230376 232423 1024K 0700 pad
10 232424 235495 1536K 0700 modemst1
11 235496 238567 1536K 0700 modemst2
12 238568 259047 10.0M 0700 oppodycnvbk
13 259048 279527 10.0M 0700 oppostanvbk
14 115671040 121552895 2872M 0700 system
15 3006464 3071999 32.0M 0700 persist
16 3072000 4120575 512M 0700 cache
17 4120576 4153343 16.0M 0700 recovery
18 4153344 4156415 1536K 0700 fsg
19 4161536 4161537 1024 0700 fsc
20 4161538 4161553 8192 0700 ssd
21 4161554 4163601 1024K 0700 misc
22 4163602 4196369 16.0M 0700 LOGO
23 4196370 4261905 32.0M 0700 DRIVER
24 4261906 4327441 32.0M 0700 reserve1
25 4327442 4360209 16.0M 0700 reserve2
26 4360210 4376593 8192K 0700 reserve3
27 4376594 4507665 64.0M 0700 reserve4
28 4521984 115671039 53.0G 0700 userdata
29 121552896 122142686 287M 0700 grow
/tmp # cat /etc/fstab
/dev/block/mmcblk0p1 /firmware vfat rw 0 0
/dev/block/mmcblk0p14 /system ext4 rw 0 0
/dev/block/mmcblk0p28 /data ext4 rw 0 0
/dev/block/mmcblk0p16 /cache ext4 rw 0 0
/tmp # df -h
Filesystem Size Used Available Use% Mounted on
tmpfs 1.4G 32.0K 1.4G 0% /dev
tmpfs 1.4G 28.0K 1.4G 0% /tmp
/dev/block/mmcblk0p16
503.9M 8.4M 495.5M 2% /cache
/dev/block/mmcblk0p28
52.2G 180.0M 52.0G 0% /data
/dev/block/mmcblk0p28
52.2G 180.0M 52.0G 0% /sdcard

dimitrios5000 said:
Hi all. Please help.
I ruined my OPO phone.
iI followed the steps correctly.
After reboot the system partition cannot mount.
I see in the log:
Failed to mount '/system' (invalid argument)
My GPT after the change:
/tmp # fdisk -l /dev/block/mmcblk0
Found valid GPT with protective MBR; using GPT
Disk /dev/block/mmcblk0: 122142720 sectors, 2296M
Logical sector size: 512
Disk identifier (GUID): 98101b32-bbe2-4bf2-a06e-2bb33d000c20
Partition table holds up to 32 entries
First usable sector is 34, last usable sector is 122142686
Number Start (sector) End (sector) Size Code Name
1 16384 147455 64.0M 0700 modem
2 147456 148479 512K 0700 sbl1
3 148480 148543 32768 0700 dbi
4 163840 163903 32768 0700 DDR
5 180224 182271 1024K 0700 aboot
6 182272 183271 500K 0700 rpm
7 196608 229375 16.0M 0700 boot
8 229376 230375 500K 0700 tz
9 230376 232423 1024K 0700 pad
10 232424 235495 1536K 0700 modemst1
11 235496 238567 1536K 0700 modemst2
12 238568 259047 10.0M 0700 oppodycnvbk
13 259048 279527 10.0M 0700 oppostanvbk
14 115671040 121552895 2872M 0700 system
15 3006464 3071999 32.0M 0700 persist
16 3072000 4120575 512M 0700 cache
17 4120576 4153343 16.0M 0700 recovery
18 4153344 4156415 1536K 0700 fsg
19 4161536 4161537 1024 0700 fsc
20 4161538 4161553 8192 0700 ssd
21 4161554 4163601 1024K 0700 misc
22 4163602 4196369 16.0M 0700 LOGO
23 4196370 4261905 32.0M 0700 DRIVER
24 4261906 4327441 32.0M 0700 reserve1
25 4327442 4360209 16.0M 0700 reserve2
26 4360210 4376593 8192K 0700 reserve3
27 4376594 4507665 64.0M 0700 reserve4
28 4521984 115671039 53.0G 0700 userdata
29 121552896 122142686 287M 0700 grow
/tmp # cat /etc/fstab
/dev/block/mmcblk0p1 /firmware vfat rw 0 0
/dev/block/mmcblk0p14 /system ext4 rw 0 0
/dev/block/mmcblk0p28 /data ext4 rw 0 0
/dev/block/mmcblk0p16 /cache ext4 rw 0 0
/tmp # df -h
Filesystem Size Used Available Use% Mounted on
tmpfs 1.4G 32.0K 1.4G 0% /dev
tmpfs 1.4G 28.0K 1.4G 0% /tmp
/dev/block/mmcblk0p16
503.9M 8.4M 495.5M 2% /cache
/dev/block/mmcblk0p28
52.2G 180.0M 52.0G 0% /data
/dev/block/mmcblk0p28
52.2G 180.0M 52.0G 0% /sdcard
Click to expand...
Click to collapse
have you figured it out?
i was succeeded, through
Failed to mount '/system' (invalid argument)
i have seen also.
i was able to sideload lineage and boot it.
After rebooting into recovery the error message was away.
After that i sideloaded lienage again, then bacon-resize-system.zip.
After that i was able to sideload Gapps Nano, the required size check was successful
Oh wait, you have OPO Phone, not OnePlus One
you can try to restore your partiotion table from backup created earlier
Bash:
./sfdisk-arm -f /dev/block/mmcblk0 < bacon.gpt
OnePlus One (Bacon) 3/64
twrp-3.6.0_9-0-bacon.img
lineage-18.1-20211223-nightly-bacon-signed.zip
open_gapps-arm-11.0-nano-20220112.zip

[TUTORIAL] How to resize system partition on Galaxy S3 for larger GAPPS

On newer Android versions, the system occupies more of the system partition and with GAPPS upgrades, larger GAPPS packages (such as stock and mini) cannot fit on the system partition of the 2012 Galaxy S3. You can just use pico or nano, but sometimes you want the full GAPPS, the real deal. This is also necessary for upcoming ROMs that come with GAPPS preinstalled, such as Pixel Experience. To do this, you must resize the system partition. You can do this by taking some of the space from the cache partition and giving it to the system partition.
PLEASE NOTE: This process is not risk-free! If you do not know what you are doing, I strongly advise against this procedure. I am not responsible for any bricked devices or issues you may face. You have been warned.
Requirements:
A Samsung Galaxy S3. I have the i9300 model, where I have tested it.
parted, downloadable from here. If it downloads as a txt file, delete the extension by renaming it without the txt.
TWRP installed on your device (available for i9300 from here.)
A computer with ADB installed and relevant drivers.
First of all, you must boot TWRP. Once booted, wipe all partitions in TWRP, including system. Reboot back into recovery. Then go into mount and deselect all devices, and uncheck the box saying "Mount system partition as read-only"
Secondly, connect your S3 and send parted to the device with the following command:
Code:
adb push <path_to_parted> /
Thirdly, enter the ADB shell with the following command:
Code:
adb shell
Now, give executable permission to the parted file with the following command:
Code:
chmod +x parted
Now run:
Code:
./parted /dev/block/mmcblk0
Run the print command and you will get a list of partitions. It should look something like:
Code:
Model: MMC VTU00M (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 8389kB 4194kB BOTA0
2 8389kB 12.6MB 4194kB BOTA1
3 12.6MB 33.6MB 21.0MB ext4 EFS
4 33.6MB 41.9MB 8389kB PARAM
5 41.9MB 50.3MB 8389kB BOOT
6 50.3MB 58.7MB 8389kB RECOVERY
7 58.7MB 92.3MB 33.6MB RADIO
8 92.3MB 1166MB 1074MB ext4 CACHE
9 1166MB 2777MB 1611MB ext4 SYSTEM
10 2777MB 3364MB 587MB ext4 HIDDEN
11 3364MB 3372MB 8389kB OTA
12 3372MB 15.8GB 12.4GB ext4 USERDATA
Make a note of the Start and End points for partitions 8 and 9 (CACHE and SYSTEM). In my case, the start and end points for partition 8 are 92.3 and 1166 and the start and end points for partition 9 are 1166 and 2777.
What we're going to do is delete these two partitions, then recreate them, but make the new partition 8 (Cache) smaller and allocate the space left to partition 9 (System).
Remove them with the following commands in parted:
Code:
./parted /dev/block/mmcblk0 rm 8
./parted /dev/block/mmcblk0 rm 9
Now recreate them with the following commands:
Code:
./parted /dev/block/mmcblk0 mkpart primary <cache_start> <cache_start+200>
./parted /dev/block/mmcblk0 mkpart primary <cache_end> <system_end>
Replace <cache_start> with the start of the former cache petition. In my case, it would be:
Code:
./parted /dev/block/mmcblk0 mkpart primary 92.3 292
./parted /dev/block/mmcblk0 mkpart primary 292 2777
Now name the partitions.
Code:
./parted /dev/block/mmcblk0 name 8 CACHE
./parted /dev/block/mmcblk0 name 9 SYSTEM
Then format them as ext4:
Code:
mke2fs -T ext4 /dev/block/mmcblk0p8
mke2fs -T ext4 /dev/block/mmcblk0p9
Run ./parted, followed by print, to check if the changes have been applied. If so, well done! You have successfully enlarged the system partition. Exit parted with the quit command.
Now configure and exit:
Code:
mount -a
exit
Reboot back into recovery and install any ROM of your choice. Once you've installed the ROM, reboot into recovery once again, and navigate to wipe --> advanced wipe, select system, tap repair or change filesystem, then resize.
You can now install any GAPPS of your choice. I've gotten LineageOS 16.0 working with mini gapps (Google Play Store + some Google apps) and it is working fine. You could make the system partition bigger by borrowing some more MB from the cache partition, or experimenting further by taking some from the HIDDEN partition. Remember, I am NOT responsible for any damage done when doing this. You assume full responsibility for any problems with the device. I hope this tutorial did help you, feel free to post here if it did or ask for help if you need it.

Did you experiment this process for a long time ? With so small a cache what could be the consequences ?
A finally do you know what is the use of HIDDEN partition ?
Great tutorial anyway.

barbe31 said:
Did you experiment this process for a long time ? With so small a cache what could be the consequences ?
Click to expand...
Click to collapse
Newer Android versions don't use up as much in the cache partition. If you're on say stock ICS or JB you may encounter some issues but if you're using LOS 15 or 16 it should work fine. I've used LOS 16 with GAPPS using this method for a while on my S3 and it's been fine.

ChasTechProjects said:
parted, downloadable from here.
Click to expand...
Click to collapse
Link says file doesn't exist.

petera703 said:
Link says file doesn't exist.
Click to expand...
Click to collapse
parted
drive.google.com

Cheers for that. I've been trying for some time to do the same thing on a Galaxy S4 Mini, working from a few variations of this process that I've found here and there, but never with any success. All appears to go well, with no errors, but it doesn't stick--the device just reverts to the previous partition sizes on reboot..
I've been using parted 3.2. I wondered if it would work with the parted you were using, but the one from your new link is 1.8 and doesn't even get as far for me (tried that one previously and it gets errors on my device).
If anyone know how to overcome the issue of resized partitions not surviving a reboot on Android, please help! I've been unable to solve it.
If it was plain Linux, it would be something to do with fstab, but fstab is never mentioned in the posts where people succeed in resizing Android partitions, so I think it must be something else, and perhaps something that varies from one device to another. Looking forward to any suggestions--thanks!

Can this idea/technique be applied to other *droid based devices
like Nook HD ?
[ Having same 'not enough space for the gaps' issue]