[GUIDE] Increase your Nexus 4's system partition for more space!

Search This thread

bmg1001

Senior Member
Mar 18, 2012
1,585
924
Los Angeles
I got tired of installing amazing ROMs created by the talented folks here on XDA, but being held back on things like Google Apps because of the tiny /system partition we have on the Nexus 4. I looked around and found guides to increase the system space in the Nexus 5 and Nexus 7 2013, so I basically just adapted them to work on our beloved Nexus 4.

As always, do this at your OWN risk. I am not responsible for bricking your Nexus 4. I will simply list the process which I used to increase my Nexus 4's system partition (by taking a big ol' chunk from the cache partition). Remember, any sort of modification to your device of this caliber WILL void any warranty you might still have.


REQUIREMENTS:
parted (Uploaded to my Google Drive. If it downloads as a .txt, rename it to remove the extension and make it a plain file)
adb and fastboot, and preferably knowledge on how they work

Step 1: Install TWRP onto your Nexus 4 and reboot into it.

Step 2: Open up command prompt / terminal and check to see if your Nexus 4 is connected properly with "adb devices".

Step 3: Once you've confirmed that adb is fully working and your Nexus 4 is properly connected to your PC, download parted and use adb to push it to your Nexus 4 using the command:

Code:
adb push parted /

Step 4: Now enter the following command:
Code:
adb shell
and then the command:
Code:
chmod +x parted
This will enter adb shell and make the "parted" binary you pushed to your device earlier executable.

Step 5:
Now run the command
Code:
./parted /dev/block/mmcblk0 p
You should see a long list with a bunch of numbers and names in your terminal. These are the partitions on your device. parted will give you the partition number, the "start" and "end" of the partition, the size, and the name.
This is the partition layout on my device. It will probably be the same on your device, though the size of userdata may vary depending on whether you have the 8gb or 16gb Nexus 4.
Code:
~ # ./parted /dev/block/mmcblk0 p
Model: MMC 016G92 (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      524kB   67.6MB  67.1MB  fat16        modem
 2      67.6MB  68.2MB  524kB                sbl1
 3      68.2MB  68.7MB  524kB                sbl2
 4      68.7MB  70.8MB  2097kB               sbl3
 5      70.8MB  71.3MB  524kB                tz
 6      71.3MB  94.4MB  23.1MB               boot
 7      94.4MB  117MB   23.1MB               recovery
 8      117MB   118MB   799kB                m9kefs1
 9      118MB   119MB   799kB                m9kefs2
10      119MB   120MB   799kB                m9kefs3
11      120MB   121MB   524kB                rpm
12      121MB   121MB   524kB                aboot
13      121MB   122MB   524kB                sbl2b
14      122MB   124MB   2097kB               sbl3b
15      124MB   124MB   524kB                abootb
16      124MB   125MB   524kB                rpmb
17      125MB   125MB   524kB                tzb
18      125MB   126MB   524kB                metadata
19      126MB   143MB   16.8MB               misc
20      143MB   159MB   16.8MB  ext4         persist
21      159MB   1040MB  881MB   ext2         system
22      1040MB  1627MB  587MB   ext4         cache
23      1627MB  15.8GB  14.1GB  ext4         userdata
24      15.8GB  15.8GB  524kB                DDR
25      15.8GB  15.8GB  507kB                grow

Step 6:
Now run the following three commands:
Code:
umount /data
umount /sdcard
umount /cache

Step 7: So, on my Nexus 4, the system partition is number 21, and cache is 22. We're kinda lucky in the fact that system and cache are right next to each other, meaning we don't have to touch any other partition.

You'll want to run these two next commands. These commands will essentially "remove" the two partitions.

Code:
./parted /dev/block/mmcblk0 rm 21
./parted /dev/block/mmcblk0 rm 22

Step 8: Now it is time to recreate these two partitions, however, when recreating them, we will make system bigger and the cache smaller. From the partitions list we got in Step 5, we can see that system starts at 159 and ends at 1040, while cache starts at 1040 and ends at 1627. The following two commands will rebuild /system starting at 159, but ending at 1590, while rebuilding cache at 1590, and ending at 1627. We are essentially stealing a large chunk from cache, since we don't really need that anymore on newer ROMs.

Code:
./parted /dev/block/mmcblk0 mkpart primary 159 1590
./parted /dev/block/mmcblk0 mkpart primary 1590 1627

Step 9: Now run this command:
Code:
./parted /dev/block/mmcblk0 p

This will bring up the partitions list, or table, again. This time, however, we'll see the new partitions where system and cache were, however, they have no names! The following two commands will name the two partitions again.

Code:
./parted /dev/block/mmcblk0 name 21 system
./parted /dev/block/mmcblk0 name 22 cache

Step 10: Great! Now the partitions should be named again! Now, we still have to format the partitions as ext4 so that we can actually use them. The following two commands will do that for you.

Code:
mke2fs -b 4096 -T ext4 /dev/block/mmcblk0p21
mke2fs -b 4096 -T ext4 /dev/block/mmcblk0p22

Step 11: At this point, feel free to run the command from Step 5 to take one more look at the partition table and make sure everything looks good. Now run the command
Code:
mount -a
and then type in
Code:
exit
.

Step 12: Now we are pretty much done. We've extended the system partition from approx. 881mb to 1431mb, which is a nice large chunk of memory. In the future, we could always mess with the partitions more to add even more space by stealing from userdata, but until we reach that point, I think we are pretty well set for now!

Now...
You'll want to reboot TWRP, and flash a new ROM. You can now use a much bigger Google Apps package, without any worries.
Do note, however, that flashing a ROM will "resize" system to be smaller, but this isn't a huge deal. After flashing a ROM, while still in TWRP, you'll want to go to Wipe > Advanced Wipe > check "system" then head to "Repair or Change File System", > then tap on "Resize File System." If you encounter any errors while trying to resize, try remounting system or rebooting TWRP. Afterwards, you should be able to flash your Google Apps package. I'm not sure if you need to repeat these steps after flashing things other than ROMs, but repeating this process within TWRP should work just as well.


I hope I helped y'all out and feel free to post if this guide worked for you or if you have any other comments!
CREDITS:
@surfrock66 for his Nexus 5 guide here.
@rkhat for his Nexus 7 2013 guide here.
 
Last edited:

jfsobreira

Member
Aug 6, 2012
6
7
São Paulo
It worked here on my 8 Gb mako. Here are the original parted output:

Code:
Model: MMC 008G92 (sd/mmc)
Disk /dev/block/mmcblk0: 7818MB
Sector size (logical/physical): 512B/512B
Partition Table: gpt

Number  Start   End     Size    File system  Name      Flags
 1      524kB   67.6MB  67.1MB  fat16        modem
 2      67.6MB  68.2MB  524kB                sbl1
 3      68.2MB  68.7MB  524kB                sbl2
 4      68.7MB  70.8MB  2097kB               sbl3
 5      70.8MB  71.3MB  524kB                tz
 6      71.3MB  94.4MB  23.1MB               boot
 7      94.4MB  117MB   23.1MB               recovery
 8      117MB   118MB   799kB                m9kefs1
 9      118MB   119MB   799kB                m9kefs2
10      119MB   120MB   799kB                m9kefs3
11      120MB   121MB   524kB                rpm
12      121MB   121MB   524kB                aboot
13      121MB   122MB   524kB                sbl2b
14      122MB   124MB   2097kB               sbl3b
15      124MB   124MB   524kB                abootb
16      124MB   125MB   524kB                rpmb
17      125MB   125MB   524kB                tzb
18      125MB   126MB   524kB                metadata
19      126MB   143MB   16.8MB               misc
20      143MB   159MB   16.8MB  ext4         persist
21      159MB   1040MB  881MB   ext2         system
22      1040MB  1627MB  587MB   ext4         cache
23      1627MB  7817MB  6190MB  ext4         userdata
24      7817MB  7818MB  524kB                DDR
25      7818MB  7818MB  507kB                grow

I'm using Nitrogen OS 8.1 with GZR Gapps
 
  • Like
Reactions: bmg1001

bmg1001

Senior Member
Mar 18, 2012
1,585
924
Los Angeles
It worked here on my 8 Gb mako. Here are the original parted output:

Code:
Model: MMC 008G92 (sd/mmc)
Disk /dev/block/mmcblk0: 7818MB
Sector size (logical/physical): 512B/512B
Partition Table: gpt

Number  Start   End     Size    File system  Name      Flags
 1      524kB   67.6MB  67.1MB  fat16        modem
 2      67.6MB  68.2MB  524kB                sbl1
 3      68.2MB  68.7MB  524kB                sbl2
 4      68.7MB  70.8MB  2097kB               sbl3
 5      70.8MB  71.3MB  524kB                tz
 6      71.3MB  94.4MB  23.1MB               boot
 7      94.4MB  117MB   23.1MB               recovery
 8      117MB   118MB   799kB                m9kefs1
 9      118MB   119MB   799kB                m9kefs2
10      119MB   120MB   799kB                m9kefs3
11      120MB   121MB   524kB                rpm
12      121MB   121MB   524kB                aboot
13      121MB   122MB   524kB                sbl2b
14      122MB   124MB   2097kB               sbl3b
15      124MB   124MB   524kB                abootb
16      124MB   125MB   524kB                rpmb
17      125MB   125MB   524kB                tzb
18      125MB   126MB   524kB                metadata
19      126MB   143MB   16.8MB               misc
20      143MB   159MB   16.8MB  ext4         persist
21      159MB   1040MB  881MB   ext2         system
22      1040MB  1627MB  587MB   ext4         cache
23      1627MB  7817MB  6190MB  ext4         userdata
24      7817MB  7818MB  524kB                DDR
25      7818MB  7818MB  507kB                grow

I'm using Nitrogen OS 8.1 with GZR Gapps

Awesome! Thanks for letting me know. Glad it worked for you. :good:
 

sambartle

Senior Member
Dec 17, 2006
270
19
Sheffield
www.sambartle.co.uk
Great guide works perfectly.. has anyone tried to reverse the process and go back to stock to reflash a factory image?

I just tried it on my old Nexus 4, and after resettting the partitions, and reflashing the factory image, its just a permanent bootloop. I've cleared all the cache, tried a wipe from the stock recovery, tried flashing TWRP and wiping there.. nothing seems to work. Im not too worried, but it'd be nice if it could boot again.
 

franz.s

New member
Aug 6, 2018
1
1
Thanks for your guide. It worked like a charm for my Nexus 4.

Just a small addition: To resize the system partition automatically I placed a script in /system/addon.d:

Code:
#!/sbin/sh
#
# /system/addon.d/10-resize-system.sh
#
. /tmp/backuptool.functions

case "$1" in
  backup)
    # Stub
  ;;
  restore)
    # Stub
  ;;
  pre-backup)
    # Stub
  ;;
  post-backup)
    # Stub
  ;;
  pre-restore)
    /sbin/resize2fs /dev/block/platform/msm_sdcc.1/by-name/system
  ;;
  post-restore)
    # Stub
  ;;
esac
 
  • Like
Reactions: bmg1001

caliban2

Senior Member
Mar 9, 2009
2,187
407
If it doesn't work for you

Thanks for this great guide!

Decided to breath some new life into an old N4 in my family and now it's going (very) strong again with LineageOS 15.1. Still had to clear a bit over 100 MB with .gapps-config from Stock-OpenGapps, but that's no biggie. I always liked to start with the big package and then remove everything that I don't need from it.

Second issue gave me some headaches at first.

"Resize File System" in TWRP apparently worked and Gapps-Install went through (~100 MB free at the end), but boot would fail and crash back to recovery.
(I'm using the daily LOS-nightlies by Milaq and Stock-Package from OpenGapps, maybe it's no problem with other ROMs and/or Gapps-Packages.)

Turns out the fix in TWRP wasn't really working, nevermind what partition size it shows for /system afterwards. It's somehow corrupted and still has the original size -> most of the gapps stuff get's written to nirvana, thus the failing boot.

I found the solution over in the Nexus5-Thread:

Hello guys!
Try this:
1) Install ROM
2) Backup ROM
3) Enable "Use 'rm -rf' instead of formatting" in TWRP settings
4) Format /system
4.1) Unmount /system and use 'resize2fs -f /dev/block/mmcblk0p21' in terminal (TWRP)
5) Reboot TWRP
5.1) Uncheck "Use 'rm -rf' instead of formatting" in TWRP settings
6) Restore backup
7) Install Stock OpenGapps
8) Done!

The idea behind it is that ROM installation somehow corrupt /system partition thus any write operations above normal data region silently fail.

at step 4.1 I already changed the partition number to 21 for Nexus4. In the original post it says mmcblk0p25, because on the Nexus 5 that's /system.

Now it works.
In theory this procedure should also work for updating the ROM without losing data, but haven't tested it yet. (Maybe throw in a wipe of /system as step 0...?)

To be clear: This isn't the fault of the guide to resize system-partition.
Problem is (at least certain) ROMs resetting size of file system to original and then TWRP failing to fix that doing it the easy way as described in OP (-> bug in TWRP?).

EDIT:
Above procedure also works for an update without data loss. Only difference was I did a normal wipe of /system first, "step 0" so to say.

No idea if all this is still necessary with TWRP 3.2.3-0, I'm not willing to risk a full wipe at this point. ^^
 
Last edited:

NotATechnician

Senior Member
Jan 15, 2016
67
8
Really wanted to thank-you for this!

Two questions:
1. When you printed the partitions, system (21) was ext2. When you recreated it after resizing, you created it as ext4. Was that intentional?
2. You also made the claim that modern ROMs don't need such a big cache partition (your new one was 37MB, I wasn't so brave). Can you justify that claim or provide some technical details? It's not that I don't believe you (I trusted you enough to do this on my device!), just merely curious as to why/how this would be.

Thanks!
 

berk90

New member
Aug 23, 2018
1
0
X:\xxx\xxx\xxx\xxx\adb>adb push parted /
487 KB/s (346680 bytes in 0.695s)

X:\xxx\xxx\xxx\xxx\adb>adb shell
~ # chmod +x parted
chmod +x parted
~ # ./parted /dev/block/mmcblk0 p
./parted /dev/block/mmcblk0 p
Error: Can't have overlapping partitions.
~ # 




Please Help!!!!!!!!!!!!!!!!!!!
 

jfsobreira

Member
Aug 6, 2012
6
7
São Paulo
Thanks for this great guide!

Decided to breath some new life into an old N4 in my family and now it's going (very) strong again with LineageOS 15.1. Still had to clear a bit over 100 MB with .gapps-config from Stock-OpenGapps, but that's no biggie. I always liked to start with the big package and then remove everything that I don't need from it.

Second issue gave me some headaches at first.

"Resize File System" in TWRP apparently worked and Gapps-Install went through (~100 MB free at the end), but boot would fail and crash back to recovery.
(I'm using the daily LOS-nightlies by Milaq and Stock-Package from OpenGapps, maybe it's no problem with other ROMs and/or Gapps-Packages.)

Turns out the fix in TWRP wasn't really working, nevermind what partition size it shows for /system afterwards. It's somehow corrupted and still has the original size -> most of the gapps stuff get's written to nirvana, thus the failing boot.

I found the solution over in the Nexus5-Thread:



at step 4.1 I already changed the partition number to 21 for Nexus4. In the original post it says mmcblk0p25, because on the Nexus 5 that's /system.

Now it works.
In theory this procedure should also work for updating the ROM without losing data, but haven't tested it yet. (Maybe throw in a wipe of /system as step 0...?)

To be clear: This isn't the fault of the guide to resize system-partition.
Problem is (at least certain) ROMs resetting size of file system to original and then TWRP failing to fix that doing it the easy way as described in OP (-> bug in TWRP?).

EDIT:
Above procedure also works for an update without data loss. Only difference was I did a normal wipe of /system first, "step 0" so to say.

No idea if all this is still necessary with TWRP 3.2.3-0, I'm not willing to risk a full wipe at this point. ^^

I'm using TWRP 3.2.3-0 and it has this bug, too. After I followed your steps I was able to install Nitrogen OS and Open Gapps Micro in my phone without erros.

Thanks!
 
  • Like
Reactions: caliban2

myxal

Senior Member
Sep 5, 2011
110
15
Hi all. I only discovered this thread after independently figuring out the partitioning scheme (plain GPT) and process.

Sadly, even after this effort, it seems L-OS upgrades won't work unless L-OS devs modify their upgrade script to make use of resize2fs. Here's what happens as of package 2018-09-11:
  1. L-OS runs backup procedure for all addons found in the existing /system/addon.d/
  2. The above creates files (I guess) in /tmp
  3. The /system is unmounted
  4. The partition is overwritten with the image in the upgrade package
  5. The script in addon.d/ are then run to restore the addons from /tmp

The problem is, the partition image in the upgrade package is for the old partition size, and therefore step 5 fails when the free space runs out. It seems the install or restore scripts don't detect this failure, and just exit without reporting an error, with 0B free space on /system.

I'm guessing the problem can be "solved" by formatting the system partition and installing LOS and all addons from scratch, but that's ridiculous. :eek: has anyone tried to raise this issue with devs? I'm about to report this in L-OS's JIRA, as I haven't seen any relevant report there.

EDIT: If anyone wants to track: https://jira.lineageos.org/browse/BUGBASH-2306
 
Last edited:

Fif_

Senior Member
Jun 5, 2013
1,022
1,022
Google Nexus 10
Google Nexus 4
Hi all. I only discovered this thread after independently figuring out the partitioning scheme (plain GPT) and process.

Sadly, even after this effort, it seems L-OS upgrades won't work unless L-OS devs modify their upgrade script to make use of resize2fs. Here's what happens as of package 2018-09-11:
L-OS runs backup procedure for all addons found in the existing /system/addon.d/
The above creates files (I guess) in /tmp
The /system is unmounted
The partition is overwritten with the image in the upgrade package
The script in addon.d/ are then run to restore the addons from /tmp


The problem is, the partition image in the upgrade package is for the old partition size, and therefore step 5 fails when the free space runs out. It seems the install or restore scripts don't detect this failure, and just exit without reporting an error, with 0B free space on /system.

I'm guessing the problem can be "solved" by formatting the system partition and installing LOS and all addons from scratch, but that's ridiculous. :eek: has anyone tried to raise this issue with devs? I'm about to report this in L-OS's JIRA, as I haven't seen any relevant report there.

EDIT: If anyone wants to track: https://jira.lineageos.org/browse/BUGBASH-2306
You may be able to fix that on your own by adding an add-on.d named 00-resize-system (so that's it's ran first) that just does "resize2fs /dev/block/.../system", with maybe an unmount before and a mount after. This way, LOS can just flash the full image when upgrading and the system is resized before the other addons.d scripts run.
 
  • Like
Reactions: myxal

myxal

Senior Member
Sep 5, 2011
110
15
You may be able to fix that on your own by adding an add-on.d named 00-resize-system (so that's it's ran first) that just does "resize2fs /dev/block/.../system", with maybe an unmount before and a mount after. This way, LOS can just flash the full image when upgrading and the system is resized before the other addons.d scripts run.

Thanks for the tip, will give that a try. Any idea where I could find an "authoritative" docs/guide to those scripts? Just looked at the one supplied by open g-apps, and I don't really see the difference between the various commands that the script is supposed to handle (which is executed when?). Also what list_file() is supposed to provide.
  • backup
  • restore
  • pre-backup
  • pre-restore
  • post-backup
  • post-restore
 

Fif_

Senior Member
Jun 5, 2013
1,022
1,022
Google Nexus 10
Google Nexus 4
Thanks for the tip, will give that a try. Any idea where I could find an "authoritative" docs/guide to those scripts? Just looked at the one supplied by open g-apps, and I don't really see the difference between the various commands that the script is supposed to handle (which is executed when?). Also what list_file() is supposed to provide.
backup
restore
pre-backup
pre-restore
post-backup
post-restore
You want to put the resize2fs call in the pre-restore section.
It should look like this:
Code:
pre-restore)
  unmount /system
  resize2fs /dev/block/platform/.../system
  mount /system
  ;;
This includes unmounting and remounting /system which I think are needed, but YMMV. You'll need to fill in the full path to system under /dev.
There is no authoritative resource for backup scripts that I know of, but the gapps script is a good example.

P.S.: If you make it work, please post the script for others...
 

Top Liked Posts

  • There are no posts matching your filters.
  • 31
    I got tired of installing amazing ROMs created by the talented folks here on XDA, but being held back on things like Google Apps because of the tiny /system partition we have on the Nexus 4. I looked around and found guides to increase the system space in the Nexus 5 and Nexus 7 2013, so I basically just adapted them to work on our beloved Nexus 4.

    As always, do this at your OWN risk. I am not responsible for bricking your Nexus 4. I will simply list the process which I used to increase my Nexus 4's system partition (by taking a big ol' chunk from the cache partition). Remember, any sort of modification to your device of this caliber WILL void any warranty you might still have.


    REQUIREMENTS:
    parted (Uploaded to my Google Drive. If it downloads as a .txt, rename it to remove the extension and make it a plain file)
    adb and fastboot, and preferably knowledge on how they work

    Step 1: Install TWRP onto your Nexus 4 and reboot into it.

    Step 2: Open up command prompt / terminal and check to see if your Nexus 4 is connected properly with "adb devices".

    Step 3: Once you've confirmed that adb is fully working and your Nexus 4 is properly connected to your PC, download parted and use adb to push it to your Nexus 4 using the command:

    Code:
    adb push parted /

    Step 4: Now enter the following command:
    Code:
    adb shell
    and then the command:
    Code:
    chmod +x parted
    This will enter adb shell and make the "parted" binary you pushed to your device earlier executable.

    Step 5:
    Now run the command
    Code:
    ./parted /dev/block/mmcblk0 p
    You should see a long list with a bunch of numbers and names in your terminal. These are the partitions on your device. parted will give you the partition number, the "start" and "end" of the partition, the size, and the name.
    This is the partition layout on my device. It will probably be the same on your device, though the size of userdata may vary depending on whether you have the 8gb or 16gb Nexus 4.
    Code:
    ~ # ./parted /dev/block/mmcblk0 p
    Model: MMC 016G92 (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      524kB   67.6MB  67.1MB  fat16        modem
     2      67.6MB  68.2MB  524kB                sbl1
     3      68.2MB  68.7MB  524kB                sbl2
     4      68.7MB  70.8MB  2097kB               sbl3
     5      70.8MB  71.3MB  524kB                tz
     6      71.3MB  94.4MB  23.1MB               boot
     7      94.4MB  117MB   23.1MB               recovery
     8      117MB   118MB   799kB                m9kefs1
     9      118MB   119MB   799kB                m9kefs2
    10      119MB   120MB   799kB                m9kefs3
    11      120MB   121MB   524kB                rpm
    12      121MB   121MB   524kB                aboot
    13      121MB   122MB   524kB                sbl2b
    14      122MB   124MB   2097kB               sbl3b
    15      124MB   124MB   524kB                abootb
    16      124MB   125MB   524kB                rpmb
    17      125MB   125MB   524kB                tzb
    18      125MB   126MB   524kB                metadata
    19      126MB   143MB   16.8MB               misc
    20      143MB   159MB   16.8MB  ext4         persist
    21      159MB   1040MB  881MB   ext2         system
    22      1040MB  1627MB  587MB   ext4         cache
    23      1627MB  15.8GB  14.1GB  ext4         userdata
    24      15.8GB  15.8GB  524kB                DDR
    25      15.8GB  15.8GB  507kB                grow

    Step 6:
    Now run the following three commands:
    Code:
    umount /data
    umount /sdcard
    umount /cache

    Step 7: So, on my Nexus 4, the system partition is number 21, and cache is 22. We're kinda lucky in the fact that system and cache are right next to each other, meaning we don't have to touch any other partition.

    You'll want to run these two next commands. These commands will essentially "remove" the two partitions.

    Code:
    ./parted /dev/block/mmcblk0 rm 21
    ./parted /dev/block/mmcblk0 rm 22

    Step 8: Now it is time to recreate these two partitions, however, when recreating them, we will make system bigger and the cache smaller. From the partitions list we got in Step 5, we can see that system starts at 159 and ends at 1040, while cache starts at 1040 and ends at 1627. The following two commands will rebuild /system starting at 159, but ending at 1590, while rebuilding cache at 1590, and ending at 1627. We are essentially stealing a large chunk from cache, since we don't really need that anymore on newer ROMs.

    Code:
    ./parted /dev/block/mmcblk0 mkpart primary 159 1590
    ./parted /dev/block/mmcblk0 mkpart primary 1590 1627

    Step 9: Now run this command:
    Code:
    ./parted /dev/block/mmcblk0 p

    This will bring up the partitions list, or table, again. This time, however, we'll see the new partitions where system and cache were, however, they have no names! The following two commands will name the two partitions again.

    Code:
    ./parted /dev/block/mmcblk0 name 21 system
    ./parted /dev/block/mmcblk0 name 22 cache

    Step 10: Great! Now the partitions should be named again! Now, we still have to format the partitions as ext4 so that we can actually use them. The following two commands will do that for you.

    Code:
    mke2fs -b 4096 -T ext4 /dev/block/mmcblk0p21
    mke2fs -b 4096 -T ext4 /dev/block/mmcblk0p22

    Step 11: At this point, feel free to run the command from Step 5 to take one more look at the partition table and make sure everything looks good. Now run the command
    Code:
    mount -a
    and then type in
    Code:
    exit
    .

    Step 12: Now we are pretty much done. We've extended the system partition from approx. 881mb to 1431mb, which is a nice large chunk of memory. In the future, we could always mess with the partitions more to add even more space by stealing from userdata, but until we reach that point, I think we are pretty well set for now!

    Now...
    You'll want to reboot TWRP, and flash a new ROM. You can now use a much bigger Google Apps package, without any worries.
    Do note, however, that flashing a ROM will "resize" system to be smaller, but this isn't a huge deal. After flashing a ROM, while still in TWRP, you'll want to go to Wipe > Advanced Wipe > check "system" then head to "Repair or Change File System", > then tap on "Resize File System." If you encounter any errors while trying to resize, try remounting system or rebooting TWRP. Afterwards, you should be able to flash your Google Apps package. I'm not sure if you need to repeat these steps after flashing things other than ROMs, but repeating this process within TWRP should work just as well.


    I hope I helped y'all out and feel free to post if this guide worked for you or if you have any other comments!
    CREDITS:
    @surfrock66 for his Nexus 5 guide here.
    @rkhat for his Nexus 7 2013 guide here.
    3
    If it doesn't work for you

    Thanks for this great guide!

    Decided to breath some new life into an old N4 in my family and now it's going (very) strong again with LineageOS 15.1. Still had to clear a bit over 100 MB with .gapps-config from Stock-OpenGapps, but that's no biggie. I always liked to start with the big package and then remove everything that I don't need from it.

    Second issue gave me some headaches at first.

    "Resize File System" in TWRP apparently worked and Gapps-Install went through (~100 MB free at the end), but boot would fail and crash back to recovery.
    (I'm using the daily LOS-nightlies by Milaq and Stock-Package from OpenGapps, maybe it's no problem with other ROMs and/or Gapps-Packages.)

    Turns out the fix in TWRP wasn't really working, nevermind what partition size it shows for /system afterwards. It's somehow corrupted and still has the original size -> most of the gapps stuff get's written to nirvana, thus the failing boot.

    I found the solution over in the Nexus5-Thread:

    Hello guys!
    Try this:
    1) Install ROM
    2) Backup ROM
    3) Enable "Use 'rm -rf' instead of formatting" in TWRP settings
    4) Format /system
    4.1) Unmount /system and use 'resize2fs -f /dev/block/mmcblk0p21' in terminal (TWRP)
    5) Reboot TWRP
    5.1) Uncheck "Use 'rm -rf' instead of formatting" in TWRP settings
    6) Restore backup
    7) Install Stock OpenGapps
    8) Done!

    The idea behind it is that ROM installation somehow corrupt /system partition thus any write operations above normal data region silently fail.

    at step 4.1 I already changed the partition number to 21 for Nexus4. In the original post it says mmcblk0p25, because on the Nexus 5 that's /system.

    Now it works.
    In theory this procedure should also work for updating the ROM without losing data, but haven't tested it yet. (Maybe throw in a wipe of /system as step 0...?)

    To be clear: This isn't the fault of the guide to resize system-partition.
    Problem is (at least certain) ROMs resetting size of file system to original and then TWRP failing to fix that doing it the easy way as described in OP (-> bug in TWRP?).

    EDIT:
    Above procedure also works for an update without data loss. Only difference was I did a normal wipe of /system first, "step 0" so to say.

    No idea if all this is still necessary with TWRP 3.2.3-0, I'm not willing to risk a full wipe at this point. ^^
    2
    2
    This should work:
    View attachment 00-grow_system.sh.zip - this is NOT an installable zip - if anyone's more versed with making those, they're welcome to make one.

    1. Boot into recovery
    2. In TWRP: Mount -> system
    3. Extract the script attached above
    4. Push it to appropriate location
      Code:
      adb push 00-grow_system.sh /system/addon.d

    Relevant part:

    Code:
    {
          grep -q "/system" /proc/mounts
        } && {
          umount /system || {
            echo "grow_system: error unmounting - cannot continue"
            exit 1
          }
        } || {
          echo "grow_system: /system wasn't mounted, proceeding"
        }
        { e2fsck -fy "$syspart" || [ "$?" -le "1" ]; } || {
          echo "grow_system: unrecoverable error found on /system, refusing to resize" >&2
          exit 1
        }
        resize2fs "$syspart"
        { e2fsck -fy "$syspart" || [ "$?" -le "1" ]; } || {
          echo "grow_system: unrecoverable error found after resize, /system is damaged" >&2
          exit 1
        }
        mount "$syspart" /system

    EDIT: Whoops, no idea how that managed to work yesterday. Updated script should work now.
    2
    Hi all. I only discovered this thread after independently figuring out the partitioning scheme (plain GPT) and process.

    Sadly, even after this effort, it seems L-OS upgrades won't work unless L-OS devs modify their upgrade script to make use of resize2fs. Here's what happens as of package 2018-09-11:
    1. L-OS runs backup procedure for all addons found in the existing /system/addon.d/
    2. The above creates files (I guess) in /tmp
    3. The /system is unmounted
    4. The partition is overwritten with the image in the upgrade package
    5. The script in addon.d/ are then run to restore the addons from /tmp

    The problem is, the partition image in the upgrade package is for the old partition size, and therefore step 5 fails when the free space runs out. It seems the install or restore scripts don't detect this failure, and just exit without reporting an error, with 0B free space on /system.

    I'm guessing the problem can be "solved" by formatting the system partition and installing LOS and all addons from scratch, but that's ridiculous. :eek: has anyone tried to raise this issue with devs? I'm about to report this in L-OS's JIRA, as I haven't seen any relevant report there.

    EDIT: If anyone wants to track: https://jira.lineageos.org/browse/BUGBASH-2306