Related
After upgrading from MIUIv4 to v6, I've discovered that the new version comes with a bootloader that
reflashes the recovery partition each time it's run with the stock recovery, which makes it impossible to use a custom recovery in order to install unsigned .zip patches,
doesn't support download mode, which makes it impossible to connect the phone to a computer as a block device and repartition it.
Since resolving this wasn't completely trivial (to me) and required a bit of research, I took some notes for future reference. I later decided to publish these notes, since someone might find them useful. Keep in mind that, while I do have technical background, I'm not intimately acquainted with the inner workings of Android and there was some trial and error involved. As a result, certain steps may be too heavy-handed or even unnecessary and I encourage comments on that.
Prerequisites
The guide presumes one has the adb, fastboot and parted binaries installed on an OS that enables access to connected block devices via the filesystem. For most users, that means a linux box.
Download mode
Booting into download mode appears to be disabled in MIUI6 v5.8.6. You will therefore need to boot into a custom recovery (see Booting into a custom recovery mode) and flash an alternative ROM (it would likely suffice to flash only certain partitions?):
Code:
$ adb push cm-11-20150802-NIGHTLY-aries.zip /storage/sdcard0
To boot into the download mode with an alternative ROM, consult [3] or run adb reboot dload against the phone in the system or in the recovery mode.
Repartitioning the internal flash memory
In my experience, the default size of the /system partition is insufficient to accommodate all the system applications along with the ever-growing Google Apps. The original inspiration came from [4]. To adjust the partition sizes, I used the parted command-line tool, since it comes with full support for GPT partitions and labels. Gparted used, but (as of v0.19.0-2) appeared to be much slower compared to parted and didn't seem to fully support GPT partition labels. Keep in mind that, unlike gparted, parted applies the changes to the block device immediately. Proceed with caution.
Before starting, it's best to backup the current partition table for a reference:
Code:
# gparted /dev/sdc
GNU Parted 3.2
Using /dev/sdc
Welcome to GNU Parted! Type 'help' to view a list of commands.
(parted) unit MiB
(parted) print
Number Start End Size File system Name Flags
1 0,02MiB 85,0MiB 85,0MiB fat16 modem msftdata
2 85,0MiB 170MiB 85,0MiB fat16 modem1 msftdata
3 170MiB 171MiB 0,50MiB sbl1
4 171MiB 171MiB 0,50MiB sbl2
5 171MiB 172MiB 1,00MiB sbl3
6 172MiB 173MiB 1,00MiB rpm
7 173MiB 174MiB 1,00MiB tz
8 174MiB 175MiB 0,50MiB DDR
9 175MiB 179MiB 4,00MiB aboot
10 179MiB 180MiB 1,00MiB misc
11 180MiB 182MiB 2,85MiB logo
12 182MiB 183MiB 0,76MiB m9kefs1
13 183MiB 184MiB 0,76MiB m9kefs2
14 184MiB 184MiB 0,00MiB m9kefsc
15 184MiB 192MiB 8,11MiB bk1
16 192MiB 193MiB 0,76MiB m9kefs3
17 193MiB 256MiB 63,2MiB bk2
18 256MiB 271MiB 15,0MiB boot
19 271MiB 286MiB 15,0MiB boot1
20 286MiB 301MiB 15,0MiB recovery
21 301MiB 312MiB 11,0MiB bk3
22 312MiB 320MiB 8,00MiB ext4 persist
23 320MiB 832MiB 512MiB ext4 system
24 832MiB 1344MiB 512MiB ext2 system1
25 1344MiB 1728MiB 384MiB ext4 cache
26 1728MiB 5312MiB 3584MiB ext4 userdata
27 5312MiB 29820MiB 24509MiB ext4 storage
Mind that /dev/sdc refers to the block device of my phone and will differ on your system depending on the amount of other block devices connected and the type of your system. It's also best to backup either the entire block device (/dev/sdc) or at last the specific partitions you are going to be messing with (/dev/sdcXY) – this is doubly important for partitions <= 22, the correct content of which may be difficult to retrieve when damaged. Labels (most likely) aren't important, the partition numbers are, so make sure you keep the order of the partitions when fiddling with them.
After finishing, reconnect the phone to make the kernel recognize the new partition structure and create the filesystem (mkfs.ext4) for any partitions you have created. The following example makes the system and system1 partitions 1GiB each and the userdata partition 4GiB at the expense of the storage partition:
Code:
# parted /dev/sdc
GNU Parted 3.2
Using /dev/sdc
Welcome to GNU Parted! Type 'help' to view a list of commands.
(parted) rm 23
(parted) rm 24
(parted) rm 25
(parted) rm 26
(parted) rm 27
(parted) mkpart physical ext4 320MiB 1344MiB
(parted) mkpart physical ext4 1344MiB 2368MiB
(parted) mkpart physical ext4 2368MiB 2752MiB
(parted) mkpart physical ext4 2752MiB 6848MiB
(parted) mkpart physical ext4 6848MiB 29819MiB
(parted) name 23 system
(parted) name 24 system1
(parted) name 25 cache
(parted) name 26 userdata
(parted) name 27 storage
(parted) quit
# sync
And then, after reattaching the phone to the computer:
Code:
# for i in /dev/sdc2[34567]; do mkfs.ext4 $i; done
# sync
Recovery mode
For booting into recovery, consult [3].
Booting into a custom recovery
Use the process described at [2], with steps 7-8 interchanged with 9-10. I used the emms_appsboot.mbm and recovery-clockwork-6.0.5.0-aries-20140718.img files (see List of files) from the fastboot mode as follows:
Code:
$ fastboot flash recovery recovery-clockwork-6.0.5.0-aries-20140718.img
$ fastboot flash aboot emmc_appsboot.mbn
$ fastboot boot recovery-clockwork-6.0.5.0-aries-20140718.img
If the phone gets stuck at booting during the last step, restart the phone and try again.
You should now be in the custom recovery. For me, this only lasted until a reboot. Then, the recovery was replaced with the stock one and it became impossible to boot into the system, effectively softbricking the phone. To fix this, flash the stock emmc_appsboot.mbm bootloader image extracted from the .zip of the MIUI ROM you are using and flash it from the fastboot mode:
Code:
$ fastboot flash aboot ./the/original/emmc_appsboot.mbn
$ fastboot continue
Fastboot mode
To boot into the fastboot mode, either:
Reboot the phone while holding the volume down button.
Run adb reboot bootloader against the phone in the system or in the recovery mode.
List of files
You don't need these files, it's only what I used, which should enable the reproducibility of my results.
xiaomi.eu_multi_aries_5.8.6_v6-5.0.zip – The MIUI6 v5.8.6 Czech ROM. Downloaded from [5].
emms_appsboot.mbm – A fixed bootloader for MIUI6 v5.8.6, which allows for the installation of recoveries other than the
built-in one (see Reinstalling the recovery). Downloaded from [2].
recovery-clockwork-6.0.5.0-aries-20140718.img – A recovery image of a custom version of the clockworkmod. Extracted from the archive downloaded from [1].
cm-11-20150802-NIGHTLY-aries.zip – An alternative ROM (Cyanogenmod 11). downloaded from [6].
Links
[2014-07-08] ClockworkMod Recovery 6.0.5.0
[Tools, Tips & Tutorials] [Device Team] How to get Custom Recoveries working again on Mi 2/2S with MIUI 6
[Tips & Tutorials] [Mods' Insight] Understanding Recovery mode & Download Mode
[SCRIPT] Fix partition table for Android 4.4
MIUIV6 OFFICIAL RELEASE
Browse Files for Samsung Galaxy S - aries
Hi, I updated partitioning tutorial to install Android 10: https://forum.xda-developers.com/t/guide-tutorial-howto-xiaomi-mi-2-2s-stock-to-android-10.4391775/
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?
I have made a workaround/guide for the Nexus 10 Pie/Gapps problem (modified Nexus 4; Tnx to bmg1001).
Modified and corrected , for installation of Pie (Android 9.0) with Gapps.
Source: https://forum.xda-developers.com/nexus-4/general/guide-increase-nexus-4s-partition-space-t3800264
Big thanks to bmg1001 on XDA-Dev!
REQUIREMENTS:
parted (in the ZIP-file on mega.nz or link above)
adb and fastboot, and preferably knowledge on how they work
Step 1: Install TWRP onto your Nexus 10 and reboot into it.
Step 2: Open up command prompt / terminal (Right mouse click) in the folder were the "parted-script" is located and check to see if your Nexus 10 is connected properly with the command "adb devices".
Step 3: Once you've confirmed that adb is fully working and your Nexus 10 is properly connected to your PC, download parted and use adb to push it to your Nexus 10 using the command: "adb push parted /"
(Without the " )!!!
Step 4: Now enter the following command: adb shell
and then the command: 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: ./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 32gb or 16gb Nexus 10). It should look a bit like the table below:
Number Start End Size File system Name Flags
1 4194kB 25.2MB 21.0MB ext4 efs
2 25.2MB 33.6MB 8389kB param
3 33.6MB 50.3MB 16.8MB boot
4 50.3MB 83.8MB 33.5MB recovery
5 83.8MB 83.9MB 65.5kB metadata
6 83.9MB 88.1MB 4194kB misc
7 88.1MB 612MB 523MB ext4 cache
8 612MB 1481MB 869MB ext2 system
9 1481MB 15.8GB 14.3GB ext4 userdata
Step 6: Now run the following three commands: umount /data umount /sdcard umount /cache
Step 7: So, on my Nexus 10, the system partition is number 8, and cache is 7. 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: ./parted /dev/block/mmcblk0 rm 7 ./parted /dev/block/mmcblk0 rm 8
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 cache starts at 88.1 and ends at 612, while system starts at 612 and ends at 1481. The following two commands will rebuild /system starting at 88.1, but ending at 400, while rebuilding cache at 400, and ending at 1481. We are essentially stealing a large chunk from cache, since we don't really need that anymore on newer ROMs. I choose the "system-/cache-size" randomly, so you may size it, the way you like!
Command: ./parted /dev/block/mmcblk0 mkpart primary 88.1 400 and ./parted /dev/block/mmcblk0 mkpart primary 400 1481
Step 9: Now run this command: ./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): ./parted /dev/block/mmcblk0 name 8 system and ./parted /dev/block/mmcblk0 name 7 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.
mke2fs -b 4096 -T ext4 /dev/block/mmcblk0p7
mke2fs -b 4096 -T ext2 /dev/block/mmcblk0p8
If you run ./parted /dev/block/mmcblk0 p It will show you the list, as shown below:
Number Start End Size File system Name Flags
1 4194kB 25.2MB 21.0MB ext4 efs
2 25.2MB 33.6MB 8389kB param
3 33.6MB 50.3MB 16.8MB boot
4 50.3MB 83.8MB 33.5MB recovery
5 83.8MB 83.9MB 65.5kB metadata
6 83.9MB 88.1MB 4194kB misc
7 88.1MB 400MB 312MB ext4 cache
8 400MB 1481MB 1081MB ext2 system
9 1481MB 15.8GB 14.3GB ext4 userdata
Step 11: Now run the command: mount -a (This command didn't work for me. Gave me errors. I rebooted from TWRP in to Recovery mode again) and then type exit.
Now you can follow your guide to flash your custom rom with GAPPS. Enjoy!!!!
Biomus
https://mega.nz/#!Rk0VCKrY!E84TJmMa9_MD5a8Wn9V7KMGgF-_SCCmXKbLahPneqKg
Thank you man, it works perfectly!
biomus said:
I have made a workaround/guide for the Nexus 10 Pie/Gapps problem (modified Nexus 4; Tnx to bmg1001).
Modified and corrected , for installation of Pie (Android 9.0) with Gapps.
Source: https://forum.xda-developers.com/nexus-4/general/guide-increase-nexus-4s-partition-space-t3800264
Big thanks to bmg1001 on XDA-Dev!
REQUIREMENTS:
parted (in the ZIP-file on mega.nz or link above)
adb and fastboot, and preferably knowledge on how they work
Step 1: Install TWRP onto your Nexus 10 and reboot into it.
Step 2: Open up command prompt / terminal (Right mouse click) in the folder were the "parted-script" is located and check to see if your Nexus 10 is connected properly with the command "adb devices".
Step 3: Once you've confirmed that adb is fully working and your Nexus 10 is properly connected to your PC, download parted and use adb to push it to your Nexus 10 using the command: "adb push parted /"
(Without the " )!!!
Step 4: Now enter the following command: adb shell
and then the command: 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: ./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 32gb or 16gb Nexus 10). It should look a bit like the table below:
Number Start End Size File system Name Flags
1 4194kB 25.2MB 21.0MB ext4 efs
2 25.2MB 33.6MB 8389kB param
3 33.6MB 50.3MB 16.8MB boot
4 50.3MB 83.8MB 33.5MB recovery
5 83.8MB 83.9MB 65.5kB metadata
6 83.9MB 88.1MB 4194kB misc
7 88.1MB 612MB 523MB ext4 cache
8 612MB 1481MB 869MB ext2 system
9 1481MB 15.8GB 14.3GB ext4 userdata
Step 6: Now run the following three commands: umount /data umount /sdcard umount /cache
Step 7: So, on my Nexus 10, the system partition is number 8, and cache is 7. 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: ./parted /dev/block/mmcblk0 rm 7 ./parted /dev/block/mmcblk0 rm 8
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 cache starts at 88.1 and ends at 612, while system starts at 612 and ends at 1481. The following two commands will rebuild /system starting at 88.1, but ending at 400, while rebuilding cache at 400, and ending at 1481. We are essentially stealing a large chunk from cache, since we don't really need that anymore on newer ROMs. I choose the "system-/cache-size" randomly, so you may size it, the way you like!
Command: ./parted /dev/block/mmcblk0 mkpart primary 88.1 400 and ./parted /dev/block/mmcblk0 mkpart primary 400 1481
Step 9: Now run this command: ./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): ./parted /dev/block/mmcblk0 name 8 system and ./parted /dev/block/mmcblk0 name 7 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.
mke2fs -b 4096 -T ext4 /dev/block/mmcblk0p7
mke2fs -b 4096 -T ext2 /dev/block/mmcblk0p8
If you run ./parted /dev/block/mmcblk0 p It will show you the list, as shown below:
Number Start End Size File system Name Flags
1 4194kB 25.2MB 21.0MB ext4 efs
2 25.2MB 33.6MB 8389kB param
3 33.6MB 50.3MB 16.8MB boot
4 50.3MB 83.8MB 33.5MB recovery
5 83.8MB 83.9MB 65.5kB metadata
6 83.9MB 88.1MB 4194kB misc
7 88.1MB 400MB 312MB ext4 cache
8 400MB 1481MB 1081MB ext2 system
9 1481MB 15.8GB 14.3GB ext4 userdata
Step 11: Now run the command: mount -a (This command didn't work for me. Gave me errors. I rebooted from TWRP in to Recovery mode again) and then type exit.
Now you can follow your guide to flash your custom rom with GAPPS. Enjoy!!!!
Biomus
Hi,
Click to expand...
Click to collapse
Thanks for this article,
I am having problems.
I have opened a terminal in the folder where the parted script is ( I am using linux )
The command adb push parted, returns the error ''usage requires an argument''
I regularly push files to my nexus 10 , but use the argument adb push xxxx /sdcard.
This pushes it to the sd card.
Consequently, I cannot go beyond the first part of this tutorial :-(
If I can push parted to sdcard, I am not sure how to chmod it from the sdcard.
many Thanks
Pootler
biomus said:
https://mega.nz/#!Rk0VCKrY!E84TJmMa9_MD5a8Wn9V7KMGgF-_SCCmXKbLahPneqKg
Click to expand...
Click to collapse
pootler said:
Thanks for this article,
I am having problems.
I have opened a terminal in the folder where the parted script is ( I am using linux )
The command adb push parted, returns the error ''usage requires an argument''
I regularly push files to my nexus 10 , but use the argument adb push xxxx /sdcard.
This pushes it to the sd card.
Consequently, I cannot go beyond the first part of this tutorial :-(
If I can push parted to sdcard, I am not sure how to chmod it from the sdcard.
many Thanks
Pootler
Click to expand...
Click to collapse
I just followed the instructions (I am using a Windows 10 PC and Nexus 10).
Step 1 - just follow the instructions
Step 2 - in TWRP open terminal (Advanced->Terminal) and then on your PC open a command prompt where you have adb installed and enter "adb devices" (without the quotes) and expect to get a line printed with your device number and "recovery" in the text. From what you said I guess you are familiar with this bit.
Step 3 - from the downloaded ZIP file (from mega.nz or the link provided) extract the "parted" file to somewhere on your PC, e.g. c:\users\me\desktop\parted and then in the PC command prompt enter "adb push c:\users\me\desktop\parted /" (without the quotes)
Step 4 - I originally did this in the PC command window "adb shell" and "chmod +x parted"
Steps 5-11 - these are done in the TWRP terminal. I too got an error when doing "mount -a" (couldn't mount 3 things) but I then entered "mount -a" again and then it only failed to mount the USB-OTG which was to be expected.
IMPORTANT
I used these instructions to resize the /system to install the following 3 files
lineage-16.0-20210620-UNOFFICIAL-manta.zip
Magisk-v23.0.apk
open_gapps-arm-9.0-pico-20210717.zip
from https://forum.xda-developers.com/t/rom-unofficial-9-lineage-16-0-manta-nexus-10.4175477/ but found the 400 value still left too small a /system so changed it to 330 (the GApps log file, at bottom, said I needed an additional 56712 bytes [approx 55.4KB] so I increased the system size by 70KB by changing 400 to 330). Remember you need to use the 330 in both of the 2 "mkpart" commands. After doing that all 3 files were installed OK, I then chose the "Wipe Cache/Dalvik" button (on the Install Zip page) and then "Reboot System" button to start the initial ROM setup.
I hope that helps.
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
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]