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
Related
~ # e2fsck -c /dev/block/mmcblk0p9
e2fsck 1.41.12 (17-May-2010)
/dev/block/mmcblk0p9: Updating bad block inode.
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Directory inode 46753, block #0, offset 0: directory corrupted
Salvage<y>?
Is this supposed to happen or do I indeed have a corrupted directory?
I went ahead anyway and this was my result
/dev/block/mmcblk0p9: ***** FILE SYSTEM WAS MODIFIED *****
/dev/block/mmcblk0p9: 1576/54544 files (0.2% non-contiguous), 71430/218112 blocks
Narada2XK said:
I went ahead anyway and this was my result
/dev/block/mmcblk0p9: ***** FILE SYSTEM WAS MODIFIED *****
/dev/block/mmcblk0p9: 1576/54544 files (0.2% non-contiguous), 71430/218112 blocks
Click to expand...
Click to collapse
hmmm what it shows? ;D it means that your emmc isnt fcked? or smt like that
EdgaBimbam said:
hmmm what it shows? ;D it means that your emmc isnt fcked? or smt like that
Click to expand...
Click to collapse
~ # umount /cache
~ # umount /system
~ # parted /dev/block/mmcblk0
GNU Parted 1.8.8.1.179-aef3
Using /dev/block/mmcblk0
Welcome to GNU Parted! Type 'help' to view a list of commands.
(parted) print
print
Model: MMC VYL00M (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 25.2MB 21.0MB ext4 EFS
2 25.2MB 26.5MB 1311kB SBL1
3 27.3MB 28.6MB 1311kB SBL2
4 29.4MB 37.7MB 8389kB PARAM
5 37.7MB 46.1MB 8389kB KERNEL
6 46.1MB 54.5MB 8389kB RECOVERY
7 54.5MB 264MB 210MB ext4 CACHE
8 264MB 281MB 16.8MB MODEM
9 281MB 1174MB 893MB ext4 FACTORYFS
10 1174MB 3322MB 2147MB ext4 DATAFS
11 3322MB 15.2GB 11.9GB fat32 UMS
12 15.2GB 15.8GB 537MB ext4 HIDDEN
(parted) quit
quit
~ # e2fsck -n -f -v /dev/block/mmcblk0p9
e2fsck 1.41.12 (17-May-2010)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
1568 inodes used (2.87%)
3 non-contiguous files (0.2%)
1 non-contiguous directory (0.1%)
# of inodes with ind/dind/tind blocks: 0/0/0
Extent depth histogram: 1293/1
70009 blocks used (32.10%)
0 bad blocks
0 large files
1190 regular files
103 directories
0 character device files
0 block device files
0 fifos
0 links
266 symbolic links (266 fast symbolic links)
0 sockets
--------
1559 files
~ #
I don't have any bad blocks and so far I don't see any problems, however, when I checked mmcblk0p10, that came back with errors, which I am not sure if I should have or not. I didn't bother to fix that though.
I suppose it's supposed to be that was because I re-install CM9, factory reset / wiped and...
~ # umount /cache
~ # umount /system
~ # e2fsck -n -f -v /dev/block/mmcblk0p9
e2fsck 1.41.12 (17-May-2010)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Directory inode 46753, block #0, offset 0: directory corrupted
Salvage? no
e2fsck: aborted
~ #
going to restore my nandroid now.
Since the gapps for 4.4 need very much space wee need bigger system partitions.
I've created a script which automates this process and increases them both to 840MB.
the space is taken from the userdata partition.
You should backup your whole phone before doing this(storage will not be touched but you shouldn't take the risk)
I tested it with 32GB version only so if you want to know if it will work for 16gb, too give me the output of this command:
parted -s /dev/block/mmcblk0 print
Download:
http://d-h.st/FWz
Instructions:
1) boot into CWM
2) adb push repartition.sh /tmp
3) adb shell chmod 0777 /tmp/repartition.sh
4) adb shell /tmp/repartition.sh
5) adb reboot recovery
6) now you can do all the usual stuff like enabling TDB and installing ROM's
Sounds great but I cannot test it, since I dont have any parted binaries (at least in my 4.1.1 Wajk Wiui ROM) ? Can you please tell me where I can get them.
Second Question:
Im currently running TDB:
System 1 latest WIUI 4.1.1 v5 ROM
System 2 MIUI v6 1.9.19
Both system partitions are completely full (usage 98 %) and the same with the data partitions ( usage 97 % )!
Would it be possible to decrease /sdcard space and repartition it like the following with TDB enabled:
system 800 mb
system1 800 mb
data 1500 mb
data1 1500 mb
sdcard *the rest*
thanks in advance
sounds like you tried to repartition from Android
You need to boot to CWM - you have parted there.
Sorry I hate people who just ask stupid questions before reading the instructions carefully ...silly me sorry for that...
What about the second question, is it possible to either increase the data partitions for less space on /sdcard ?
there isn't sth. like a data1 partition. we have one data partition only that's why we need the TDB hack.
other than that it's possible but you should backup all your data and restore it afterwards.
m11kkaa said:
there isn't sth. like a data1 partition. we have one data partition only that's why we need the TDB hack.
other than that it's possible but you should backup all your data and restore it afterwards.
Click to expand...
Click to collapse
Ok got it.
So following your instructions and editing script like the following should work ?
Code:
change_table() {
ui_print "parted: delete"
parted -s /dev/block/mmcblk0 rm 23 || return 1 # system
parted -s /dev/block/mmcblk0 rm 24 || return 1 # system1
parted -s /dev/block/mmcblk0 rm 25 || return 1 # cache
parted -s /dev/block/mmcblk0 rm 26 || return 1 # userdata
parted -s /dev/block/mmcblk0 rm 27 || return 1 # storage
ui_print "parted: create"
parted -s /dev/block/mmcblk0 mkpartfs primary ext2 336MB 1176MB || return 1
parted -s /dev/block/mmcblk0 mkpartfs primary ext2 1176MB 2016MB || return 1
parted -s /dev/block/mmcblk0 mkpartfs primary ext2 2016MB 2419MB || return 1
parted -s /dev/block/mmcblk0 mkpartfs primary ext2 2419MB 6515MB || return 1
parted -s /dev/block/mmcblk0 mkpartfs primary ext2 6515MB 31.3GB || return 1
ui_print "parted: name"
parted -s /dev/block/mmcblk0 name 23 system || return 1
parted -s /dev/block/mmcblk0 name 24 system1 || return 1
parted -s /dev/block/mmcblk0 name 25 cache || return 1
parted -s /dev/block/mmcblk0 name 26 userdata || return 1
parted -s /dev/block/mmcblk0 name 27 storage || return 1
return 0
}
Code:
ui_print "format partitions"
for NUM in 23 24 25 26 27
do
if ! format_partition "$NUM"; then
ui_print "Failed format partition $NUM"
exit 1
fi
done
already did full backup of sdcard, i just dont know if i should disable TDB before i stat repartitioning ... I dont know how TDB works to split the data partition thats my problem :/
yes that should work.
You don't need to disable TDB because your whole data partition will be wiped and it stores the TDB configuration(that means that TDB automatically gets disabled).
Had some errors but now its working fine ..thanks
unmount sdcard in CWM. It's a bug of this script.
Nice to hear it works now.
7 days ago Phone not start because partition corrupt
Hello
First do not panic is not the fault of your script but for you experience with mi2s and partitions are the few people in the world that can save my phone.
I'm playing a game phone(Xiaomi m2s 16GB) hang and one or more partitions are corrupt (I think this is the problem). But all de documentation than i find to delete o edit partition not work. Fastboot rom installation all ok but always only start with white logo. Mirecovery works perfectly and CWM by ivan works but temporally with this command sudo fastboot boot recovery.img
This is the result of your script
check environment
/sbin/mount
/sbin/umount
/sbin/parted
/sbin/tune2fs
/sbin/e2fsck
dump old table
unmount partitions
umount: can't umount /system: Invalid argument
umount: can't umount /system1: No such file or directory
umount: can't umount /data: Invalid argument
umount: can't umount /data_root: Invalid argument
umount: can't umount /sdcard: Invalid argument
change partition table
parted: delete
parted: create
Error: Unable to satisfy all constraints on the partition.
Failed changing table
OTHER TEST
/dev/block # e2fsck -fDp /dev/block/mmcblk0p24
e2fsck: Bad magic number in super-block while trying to open /dev/block/mmcblk0p24
/dev/block/mmcblk0p24:
The superblock could not be read or does not describe a correct ext2
filesystem. If the device is valid and it really contains an ext2
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
e2fsck -b 8193 <device>
/dev/block # tune2fs -O extents,uninit_bg,dir_index /dev/block/mmcblk0p24
tune2fs 1.41.14 (22-Dec-2010)
tune2fs: Bad magic number in super-block while trying to open /dev/block/mmcblk0p24
Couldn't find valid filesystem superblock.
I try to delete partition and create a new one but fail.
(parted) rm 24
rm 24
(parted) mkpartfs primary ext2 872 1409
mkpartfs primary ext2 872 1409
Error: Unable to satisfy all constraints on the partition.
I FOUND THIS IN XDA FORUM BUT I HAVEN'T IMAGE TO TEST
adb push mmcblk0p19_repaired.img /tmp/
adb shell dd if=/tmp/mmcblk0p19_repaired.img of=/dev/block/mmcblk0p19
adb reboot bootloader
MY PARTITION TABLE SYSTEM1 NOT HAVE FILESYSTEM EXT4
[email protected]:~/Escritorio/recovery$ sudo adb shell parted -s /dev/block/mmcblk0 print
Model: MMC SEM16G (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 17.4kB 89.1MB 89.1MB fat16 modem
2 89.1MB 178MB 89.1MB fat16 modem1
3 178MB 179MB 524kB sbl1
4 179MB 179MB 524kB sbl2
5 179MB 180MB 1049kB sbl3
6 180MB 181MB 1049kB rpm
7 181MB 182MB 1049kB tz
8 182MB 183MB 524kB DDR
9 183MB 187MB 4194kB aboot
10 187MB 188MB 1049kB misc
11 188MB 191MB 2990kB logo
12 191MB 192MB 799kB m9kefs1
13 192MB 193MB 799kB m9kefs2
14 193MB 193MB 1024B m9kefsc
15 193MB 201MB 8501kB bk1
16 201MB 202MB 799kB m9kefs3
17 202MB 268MB 66.3MB bk2
18 268MB 284MB 15.7MB boot
19 284MB 300MB 15.7MB boot1
20 300MB 316MB 15.7MB recovery
21 316MB 327MB 11.5MB bk3
22 327MB 336MB 8389kB ext4 persist
23 336MB 872MB 537MB ext4 system
24 872MB 1409MB 537MB system1
25 1409MB 1812MB 403MB ext4 cache
26 1812MB 5570MB 3758MB ext4 userdata
27 5570MB 15.8GB 10.2GB ext4 storage
Xiaomi Mi2 32GB
XIAOMI MI2 32GB ONLY
For those using a single MIUI ROM I've made a partition table with system1 set to 1024Mb.
Run the attached from CWM (in /tmp).
Aternus said:
XIAOMI MI2 32GB ONLY
For those using a single MIUI ROM I've made a partition table with system1 set to 1024Mb.
Run the attached from CWM (in /tmp).
Click to expand...
Click to collapse
Can you explain a little more? Does it only leave 1 system partition? Can I flash it like a regular zip?
Enviado desde mi MI 2S mediante Tapatalk
any step by step manual how to change partition? with all necessary downloads etc...
or.... is it possible to delete system2 with all its parts? - for me I'd to use system1 only
Why can not I change the size of the system partition?
Already tried several times, with disabled TDB and with enabled TDB.
Full wipe did and still no result.
P.S. I have already been able to do any repartitioning.
Code:
PS C:\Android> adb push repartition.sh /tmp
* daemon not running. starting it now on port 5037 *
* daemon started successfully *
21 KB/s (3797 bytes in 0.169s)
PS C:\Android> adb shell chmod 0777 /tmp/repartition.sh
PS C:\Android> adb shell /tmp/repartition.sh
check environment
/sbin/mount
/sbin/umount
/sbin/parted
/sbin/tune2fs
/sbin/e2fsck
dump old table
__bionic_open_tzdata: couldn't find any tzdata when looking for localtime!
__bionic_open_tzdata: couldn't find any tzdata when looking for GMT!
__bionic_open_tzdata: couldn't find any tzdata when looking for posixrules!
unmount partitions
umount: can't umount /system: Invalid argument
umount: can't umount /system1: No such file or directory
umount: can't umount /data: Invalid argument
umount: can't umount /sdcard: Invalid argument
change partition table
parted: delete
parted: create
parted: name
format partitions
format: /dev/block/mmcblk0p23
tune2fs 1.41.14 (22-Dec-2010)
tune2fs: No such file or directory while trying to open /dev/block/mmcblk0p23
Couldn't find valid filesystem superblock.
e2fsck 1.41.14 (22-Dec-2010)
e2fsck: No such file or directory while trying to open /dev/block/mmcblk0p23
Possibly non-existent device?
tune2fs 1.41.14 (22-Dec-2010)
e2fsck 1.41.14 (22-Dec-2010)
Adding dirhash hint to filesystem.
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 3A: Optimizing directories
Pass 4: Checking reference counts
Pass 5: Checking group summary information
/dev/block/mmcblk0p23: ***** FILE SYSTEM WAS MODIFIED *****
/dev/block/mmcblk0p23: 11/500856 files (0.0% non-contiguous), 62917/1000445 blocks
format: /dev/block/mmcblk0p24
tune2fs 1.41.14 (22-Dec-2010)
Creating journal inode: done
This filesystem will be automatically checked every 30 mounts or
0 days, whichever comes first. Use tune2fs -c or -i to override.
e2fsck 1.41.14 (22-Dec-2010)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 3A: Optimizing directories
Pass 4: Checking reference counts
Pass 5: Checking group summary information
/dev/block/mmcblk0p24: ***** FILE SYSTEM WAS MODIFIED *****
/dev/block/mmcblk0p24: 11/262144 files (0.0% non-contiguous), 49386/524289 blocks
tune2fs 1.41.14 (22-Dec-2010)
e2fsck 1.41.14 (22-Dec-2010)
Adding dirhash hint to filesystem.
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 3A: Optimizing directories
Pass 4: Checking reference counts
Pass 5: Checking group summary information
/dev/block/mmcblk0p24: ***** FILE SYSTEM WAS MODIFIED *****
/dev/block/mmcblk0p24: 11/262144 files (0.0% non-contiguous), 49386/524289 blocks
format: /dev/block/mmcblk0p25
tune2fs 1.41.14 (22-Dec-2010)
Creating journal inode: done
This filesystem will be automatically checked every 30 mounts or
0 days, whichever comes first. Use tune2fs -c or -i to override.
e2fsck 1.41.14 (22-Dec-2010)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 3A: Optimizing directories
Pass 4: Checking reference counts
Pass 5: Checking group summary information
/dev/block/mmcblk0p25: ***** FILE SYSTEM WAS MODIFIED *****
/dev/block/mmcblk0p25: 11/196608 files (0.0% non-contiguous), 32935/393217 blocks
tune2fs 1.41.14 (22-Dec-2010)
e2fsck 1.41.14 (22-Dec-2010)
Adding dirhash hint to filesystem.
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 3A: Optimizing directories
Pass 4: Checking reference counts
Pass 5: Checking group summary information
/dev/block/mmcblk0p25: ***** FILE SYSTEM WAS MODIFIED *****
/dev/block/mmcblk0p25: 11/196608 files (0.0% non-contiguous), 32935/393217 blocks
format: /dev/block/mmcblk0p26
tune2fs 1.41.14 (22-Dec-2010)
Creating journal inode: done
This filesystem will be automatically checked every 30 mounts or
0 days, whichever comes first. Use tune2fs -c or -i to override.
e2fsck 1.41.14 (22-Dec-2010)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 3A: Optimizing directories
Pass 4: Checking reference counts
Pass 5: Checking group summary information
/dev/block/mmcblk0p26: ***** FILE SYSTEM WAS MODIFIED *****
/dev/block/mmcblk0p26: 11/399200 files (9.1% non-contiguous), 28951/798348 blocks
tune2fs 1.41.14 (22-Dec-2010)
e2fsck 1.41.14 (22-Dec-2010)
Adding dirhash hint to filesystem.
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 3A: Optimizing directories
Pass 4: Checking reference counts
Pass 5: Checking group summary information
/dev/block/mmcblk0p26: ***** FILE SYSTEM WAS MODIFIED *****
/dev/block/mmcblk0p26: 11/399200 files (9.1% non-contiguous), 28951/798348 blocks
Done.
PS C:\Android> adb reboot recovery
PS C:\Android>
UPD. The problem was that I was using Windows Povershell
Run the script from the command line and everything turned out.
Thanks!
I have to format first system and system1 in recovery to apply this script, because I have and error :
tmp/repartition.sh lin 115 can´t create /sdcard/parted_12_06_2014_FDFD6F4CB043F4956D9CAD053C3738AA.
DO MOUNT your SDCARD
then Follow the instruction
duhh...
I modified the script a little bit for 1 ROM usage. System1 is 840MB as in the original and System2 is 5MB. The rest goes into userdata. This is for the 16GB version.
Ok! I did again and umount the sdcard abd it worked fine.
Thanks
I found a better way
If u reboot into dload mode, u can change the partition table from your computer
The problem is that most partition managers don't support changing the GPT Partition names and that's why I added support for that to GParted.
GParted supports booting from Live CD/USB so Windows/Mac users aren't left out.
http://i.imgur.com/3SwSXs2.png
I pushed the patch to GParted repo's and I'll inform u once there're any news.
from my point of view the best way for use is:
- system (system1) - let 1024 MB
- system1 (system2) - let 10 MB
- userdata (apps) - let 4096 MB (take it from sdcard) - but maybe more
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?
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]
I booted to TWRP recovery and tried to shrink /system and extend /data in the following way:
Code:
parted /dev/block/mmcblk0
(parted) unit s
(parted) print free
The output (original partition table):
Code:
Model: MMC H8G4u! (sd/mmc)
Disk /dev/block/mmcblk0: 15269888s
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags:
Number Start End Size File system Name Flags
34s 8191s 8158s Free Space
1 8192s 38911s 30720s apnhlos msftdata
2 38912s 156543s 117632s modem msftdata
3 156544s 157567s 1024s sbl1
4 157568s 157631s 64s ddr
5 157632s 161727s 4096s aboot
6 161728s 162751s 1024s rpm
7 162752s 163775s 1024s qsee
8 163776s 164799s 1024s qhee
9 164800s 170943s 6144s fsg
10 170944s 170975s 32s sec
11 170976s 192511s 21536s pad msftdata
12 192512s 212991s 20480s param
13 212992s 241663s 28672s ext4 efs
14 241664s 247807s 6144s modemst1
15 247808s 253951s 6144s modemst2
16 253952s 280575s 26624s boot
17 280576s 311295s 30720s recovery
18 311296s 336897s 25602s fota
19 336898s 351215s 14318s backup legacy_boot
20 351216s 357359s 6144s fsc
21 357360s 357375s 16s ssd
22 357376s 373759s 16384s ext4 persist
23 373760s 374783s 1024s persistent
24 374784s 393215s 18432s ext4 persdata
25 393216s 4653055s 4259840s ext4 system
26 4653056s 5062655s 409600s ext4 cache
27 5062656s 5206015s 143360s ext4 hidden
28 5206016s 15269847s 10063832s ext4 userdata
15269848s 15269854s 7s Free Space
Then I removed last 3 partitions and resized /system:
Code:
(parted) rm 28
(parted) rm 27
(parted) rm 26
(parted) resizepart 25 3186687
(parted) mkpart physical ext4 3186688 3596287
(parted) name 26 cache
(parted) mkpart physical ext4 3596288 3602431
(parted) name 27 hidden
(parted) mkpart physical ext4 3602432 15269847
(parted) name 28 userdata
(parted) quit
Then you need to sync changes to be able to mount /system again:
Code:
sync
blockdev --flushbufs /dev/block/mmcblk0
partprobe
However, nothing is changed. All sizes remained old.
Code:
parted /dev/block/mmcblk0 print free
After mounting partitions in TWRP or after reboot to system the partition sizes remain old.
What am I doing wrong? Has Samsung Galaxy J5 (SM-J500FN) any hardware lock? Do I need to perform resizing in download mode?
One more think to mention. Util parted downloaded from there. All changes were visible after "print free" before "quit". But I also tried parted from another thread and changes were not appliedd after "print free".
Anyone tried to shrink /system partition with this util?
GitHub - Lanchon/REPIT: A Device-Only Data-Sparing Repartitioning Tool For Android
A Device-Only Data-Sparing Repartitioning Tool For Android - GitHub - Lanchon/REPIT: A Device-Only Data-Sparing Repartitioning Tool For Android
github.com
Script looks good but there are some questions:
resize2fs - does it defrag file system before shrinking it? Otherwise system would be lost.
is this chunk-by-chunk data moving in function processParMove() necessary in 2021? No Linux tools that perform partitioning with data move on eMMC drives?
If resize2fs defrags files before shrinking file system, then it should be safe to use REPIT.
Note: For anybody who want to repartition its device manually (in devices where you may do it via adb but in Samsung Galaxy you can't) - do not shrink partitions without resize2fs first.
resize2fs(8) - Linux man page
The resize2fs program will resize ext2, ext3, or ext4 file systems. It can be used to enlarge or shrink an unmounted file system located on device. If the ...
linux.die.net
Edit: and will it even work? AFAIK you need PIT file to repartition Samsung Galaxy in Odin.
Edit 2: Is this forum dead? I'm postponing REPIT on my J5 because GPT seems signed and this may lead to hard brick. Until any other J5 users confirm REPIT is safe, i will stick to soft linking apps from /system to /data and cron job to keep links.
Port Request for HUAWEI Honor 4X Che1-CL20 · Issue #28 · Lanchon/REPIT
Hi Lanchon, Can I have a REPIT configuration file for my HUAWEI Honor 4X Che1-CL20? Thanks. your exact device and device codename. http://www.phonemore.com/phone/huawei-honor-4x-che1-cl20/2184 HUAW...
github.com
Edit 3: Not tried REPIT yet but if you want to try it, you need busybox installed. It will NOT work with toybox that is installed by default in stock ROMs.