-
Notifications
You must be signed in to change notification settings - Fork 26
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
Comments
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. |
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. |
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. |
never ever hijack existing threads for your own unrelated purposes! |
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:
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:
and the following issue affects you if you are resizing /system for any reason...
-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
The text was updated successfully, but these errors were encountered: