Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

The issues around resizing the '/system' partition #56

Open
Lanchon opened this issue Oct 19, 2016 · 4 comments
Open

The issues around resizing the '/system' partition #56

Lanchon opened this issue Oct 19, 2016 · 4 comments

Comments

@Lanchon
Copy link
Owner

Lanchon commented Oct 19, 2016

this is a note for those who want to resize /system. this operation has pros and cons that you should evaluate before making a decision.

the usual motivations to resize /system are:

  • /system is too small to fit a large google apps package.
  • /system is unnecessarily large and i want to use that space for /data.

a breakdown of the resulting issues follows.

if /system is too small to fit a large google apps package...

you should NOT grow /system if the 'nano' gapps package fits in your current partition size, and here is why:

  • the space issue: if you grow /system to install more google apps there, when google updates them they will eat TWICE as much space: once in /system for the flashed version, and again in /data for the updated version. in small flash devices, it is always better to have a smaller /system and bigger /data, and to install the absolute minimum in /system and the rest from the play store. apps installed from play store will use the same space in /data as system apps (after those are updated), but will use zero space in /system. this allows for a smaller /system and bigger /data, which is your ultimate goal.

and the following issue affects you if you are resizing /system for any reason...

  • the flashing issue: recent androids (5.0 and later) are flashed by writing an image of the complete /system partition file system, instead of writing its files one-by-one. this means that:
    • if you shrink /system, the flash will fail because the image does not fit the partition (even though the imaged file system might have a lot of free space within).
    • if you grow /system, flashing a standard rom will write a smaller file system within the partition. the extra space will then not be immediately available for writing files. in order to recover the space you would need to run the resize2fs tool to grow /system's file system back to a size that fills the /system partition AFTER EVERY ROM FLASH (and before flashing gapps). you can run the resize2fs tool simply by clicking TWRP's "resize partition" button, or by running REPIT again (-system=same is enough for this), or straight from the command line.

but because of the way the "gapps save and restore during flash" mechanism in roms works, and because the restore happens before you have a chance to grow the file system, the gapps restore will fail for lack of space. so you would need to manually format /system, flash rom, resize /system, and flash gapps for every rom upgrade.

the solution to this problem is asking the rom developer to include a /system resize step during the installation of their roms. there is a commit that can be added for this. variations of this commit are used in official i9100 CM, in several galaxy nexus roms, and in other devices. after this commit is added, the rom developer can also shrink the size of the /system image (after all, it will be expanded by the resize on install), solving both issues: the rom will grow to fill a bigger /system, but it will also install on a smaller-than-stock /system.

recommendations

  • if /system is around 1G: don't resize /system. use gapps nano and install play store gapps.
  • if /system is significantly smaller than 1G: then you need to resize /system even to fit nano gapps. contact your rom developer about using REPIT as a de facto solution for your device. besides documentation changes that point to REPIT as a one-off required step to flash rom+gapps, the rom developer will have to add the /system resize step to their rom installation script.
  • if /system is significantly bigger than 1G (eg: 2G): contact your rom developer about supporting optional /system partition shrinking: they will need to add the /system resize step to their rom installation script and then shrink /system's file system image to something reasonable like 0.75G or 1G. this adds support for people who want to shrink /system to have extra space in /data.
@nishimura-san
Copy link

Just referencing that my /system was 1.5gb from the get-go, and 1.1gb used doesnțt leave me with any alternative but to keep the system 1.5gb to still have some free space. That's the reasoning why i HAD to do it. Been running for 1 day with no problem. Might want to add that i am 西村大一 on XDA.

@ricardojlrufino
Copy link

Another argument against re-sizing: You won't be able to install any Android updates anymore, as those often come as "images" to flash (replacing entire file systems) – which then no longer would match the partition size, causing the update to fail to flash at best, or bricking your device at worst.

@Lanchon
Copy link
Owner Author

Lanchon commented Jul 13, 2018

you are obviously not going to resize /system if you use stock roms! and if you want to go back to stock, you typically restore partitions such as /system to stock condition beforehand.

@Lanchon
Copy link
Owner Author

Lanchon commented Sep 29, 2020

@Reckless71 ,

Hello!

I messed my Nook HD+ partitions by wrongly configure your script by omitting some parameters.

Your script worked fine for me earlier.

Please help me to recover / rebuild the partitions.
Thanking you in advance.

never ever hijack existing threads for your own unrelated purposes!

Repository owner deleted a comment from Reckless71 Sep 29, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants