Partition layout change

[Guest Tom G]

I made the cache 3 sectors, same size as that misc partition, I'm not sure how big a sector is ... but I think it might be a little too small, it wont mount at all. The only problem I can find is that error message, everything still works in seb's recovery & there are no problems with the rom, once it's symlinked to a directory in data.

I even let a plain jj8 boot with the modified cache size, but no symlink & it booted, but I'd expect problems with app installs without the symlink.

The way to find out what uses the /cache partition is to break it & see what else breaks. That's what I've done & it doesn't seem like much breaks, although there's still further testing to be done.

If anybody else wants to try it, I attached the files to add to a tpt image & the commands to add to /system/bin/userinit.sh just don't blame me if you break your phone (hopefully another known working tpt image will fix it). Anyone is free to use it in their tpt rom.

You shouldnt need to mount the cache partition at all, so it shouldn't matter that it doesn't mount.

Just mount mtd6 at /cache.

The bits before the recovery partition are the bootloaders, amss etc. Look at partitions_zte and you will understand (or the bootloader output I have posted).

PS. I started writing a java app to resize partitions a couple of weeks ago, but will probably never finish it. At the moment it just reads the bootloader and displays the partition info. I've moved onto other things for now, but might get back to it one day. Attached is a pic if anyone is interested. I wrote it at work one day when I had nothing to do.

Edited January 24, 2011 by Tom G

[Guest isambard]

Here is today's partition layout, it seems to work well.

335mb seems to be the most I can get onto /data without making /system or /cache too small. I found out that a 1mb /cache partition is too small & gives errors, but 1.5mb works, this seems to be the minimum possible working size for /cache. I didn't alter recovery, boot or splash, possibly another couple of mb to be gained there, but I didn't want to risk it. I shrunk /system to 120mb, jj8 is only ~116mb, so there's still some breathing room there.

so

/cache = 1.5mb

/system = 120mb

/data = 335.35mb

I also noticed there is 42mb before the first partition (recovery), I assume that's where the hidden partitions are & what gets written to by the mbm files in the hungarian update...

		start	size

?????		0x000	0x156 = 42.75mb

recovery 		0x156	0x024 = 4.5mb

boot		0x17A	0x024 = 4.5mb

splash		0x19E	0x00C = 1.5mb

misc		0x1AA	0x003 = 0.375mb

cache		0x1AD	0x00C = 1.5mb

system		0x1B9	0x3C0 = 120mb

userdata		0x579	0xA7B = 335.375mb

persist		0xFF4	0x00C = 1.5mb

[/codebox]

from what i remember, the amss etc. files didn't take so much space and since they are not regularly updated (if at all) it might be another source to really push for more space. maybe save another 20mb+ from here and break the 350mb mark.

[Guest Tom G]

from what i remember, the amss etc. files didn't take so much space and since they are not regularly updated (if at all) it might be another source to really push for more space. maybe save another 20mb+ from here and break the 350mb mark.

They have a little more space allocated to them than they need but I wouldn't try moving them. You won't get much extra space out of it and there is a good chance you will break something.

[Guest wbaw]

You shouldnt need to mount the cache partition at all, so it shouldn't matter that it doesn't mount.

Just mount mtd6 at /cache.

The bits before the recovery partition are the bootloaders, amss etc. Look at partitions_zte and you will understand (or the bootloader output I have posted).

PS. I started writing a java app to resize partitions a couple of weeks ago, but will probably never finish it. At the moment it just reads the bootloader and displays the partition info. I've moved onto other things for now, but might get back to it one day. Attached is a pic if anyone is interested. I wrote it at work one day when I had nothing to do.

How do I prevent the cache partition from mounting? Any idea what I need to edit? At the moment I'm unmounting it & creating a symlink towards the end of the boot process, using /system/bin/userinit.sh

The cache partition is used by recovery programs to store their log files, so it does need to be able to mount it otherwise seb's recovery program gives errors, I expect clockwork will be similar. As I said, 1.5mb seems to be the minimum, 1mb or below wont mount.

Partition_zte.mbn is the file i edited, partition.mbn contains the bootloaders, etc. I can't see the part of appsboot.mbn that I'd need to edit for the bootloader partitions, I'm not sure only editing partition.mbn would do it.

I think reclaiming space from the first partitions would be too risky for me to try, especially if there's nothing in appsboot.mbn to be able to repartition them. I just posted about that in case somebody want to try to dump it.

Edited January 24, 2011 by wbaw

[Guest isambard]

Partition_zte.mbn is the file i edited, partition.mbn contains the bootloaders, etc. I can't see the part of appsboot.mbn that I'd need to edit for the bootloader partitions, I'm not sure only editing partition.mbn would do it.

the radio partition info is probably in a different mbn file, though i agree with Tom that the risk is higher if you make a mistake.

[Guest oh!dougal]

...

The cache partition is used by recovery programs to store their log files, so it does need to be able to mount it otherwise seb's recovery program gives errors, I expect clockwork will be similar. As I said, 1.5mb seems to be the minimum, 1mb or below wont mount.

...

If you were to copy *.* from /cache to /data/cache (before erasing*.*) then any such log files COULD still be inspected ... :) (until the next normal boot when /data/cache would be cleared)

And if there was nothing there (as normally the case), then even you :lol: wouldn't notice the delay!

Edited January 24, 2011 by oh!dougal

[Guest wbaw]

If you were to copy *.* from /cache to /data/cache (before erasing*.*) then any such log files COULD still be inspected ... :) (until the next normal boot when /data/cache would be cleared)

And if there was nothing there (as normally the case), then even you :lol: wouldn't notice the delay!

New version for you. The old version didn't clear the recovery logs on each boot, this one will, but it'll copy the old ones to /data. They're no use on data, they can't be accessed by recovery mode easily there & it'd make them harder to inspect, but if that's how you want it to work, add this to userinit.sh . otherwise the current version of my redirect script seems to have got it right, imo.

#### START - Redirect cache partition to /data ####

mkdir /data/cache

chown system.cache /data/cache

chmod 770 /data/cache

rm /cache/*.apk

rm /data/cache/*.apk

mv /cache/* /data/cache/

mkdir /data/cache/recovery

chown system.cache /data/cache/recovery

chmod 770 /data/cache/recovery

mkdir /data/cache/lost+found

chown root.root /data/cache/lost+found

chmod 770 /data/cache/lost+found

ln -s /data/dalvik-cache /data/cache/dalvik-cache

umount /cache

rmdir /cache

ln -s /data/cache /cache

#### END - Redirect cache partition to /data ####

[/codebox]

Edited January 24, 2011 by wbaw

[Guest Tom G]

How do I prevent the cache partition from mounting? Any idea what I need to edit? At the moment I'm unmounting it & creating a symlink towards the end of the boot process, using /system/bin/userinit.sh

edit init.rc

change

mount yaffs2 mtd@cache /cache nosuid nodev

to

mount yaffs2 mtd@userdata /cache nosuid nodev

it looks like it will allow a partition to be mounted at two mount points.

Partition_zte.mbn is the file i edited, partition.mbn contains the bootloaders, etc. I can't see the part of appsboot.mbn that I'd need to edit for the bootloader partitions, I'm not sure only editing partition.mbn would do it.

I think reclaiming space from the first partitions would be too risky for me to try, especially if there's nothing in appsboot.mbn to be able to repartition them. I just posted about that in case somebody want to try to dump it.

Sorry, I got the file names mixed up :lol:

I doubt it uses a lookup table to find the bits at the start (like the table in appsboot.mbn). It probably just loads the various pieces from fixed adresses, so moving them would break things.

[Guest wbaw]

edit init.rc

change

mount yaffs2 mtd@cache /cache nosuid nodev

to

mount yaffs2 mtd@userdata /cache nosuid nodev

I could just comment that line out, if it'd let me change init.rc. I think / is mounted on tmpfs, any changes are lost on reboot.

Need to find what generates that part of init.rc ...

It will mount the same partition at 2 points, I've done that through ssh, but i'd rather stick with the symlink.

Edited January 24, 2011 by wbaw

[Guest Tom G]

I could just comment that line out, if it'd let me change init.rc. I think / is mounted on tmpfs, any changes are lost on reboot.

Need to find what generates that part of init.rc ...

It will mount the same partition at 2 points, I've done that through ssh, but i'd rather stick with the symlink.

Nothing generates it, it is in the boot image ramdisk. You just need to repack the boot image with what ever changes you want to make. The /cache directory doesn't exist in the ramdisk, it is created in the rootfs by init.rc, so you could remove the mkdir /cache and replace it with a symlink to where ever yoou want it to go which would be a bit tidier.

[Guest wbaw]

Nothing generates it, it is in the boot image ramdisk. You just need to repack the boot image with what ever changes you want to make. The /cache directory doesn't exist in the ramdisk, it is created in the rootfs by init.rc, so you could remove the mkdir /cache and replace it with a symlink to where ever yoou want it to go which would be a bit tidier.

ah, i see. i'd tried editing it on the phone & lost any changes. i've not messed with boot.img yet. i'll stick with my current method for now, it works.

[Guest wbaw]

I'm now wondering if there might be a small performance gain if we keep the /cache partition & use it for the dalvik cache instead of the download cache. Would 42mb be enough for dalvik cache? In theory it'd be to make fragmentation of the dalvik-cache less likely. I'm just not sure if it's worth bothering with, with it being flash, fragmentation doesn't have a huge effect, yaffs might make it not an issue at all. Thoughts?

Edited January 28, 2011 by wbaw

[Guest womble_sanfran]

I am happy on the stock rom I am currently on but want to use the spare space in /system. Would the following process mean I end up with my existing stock ROM as it is currently but with a 128MB /system partition (I am currently using 122MB on /system so it should fit fine):

1. Do a clockwork nandroid backup
   
2. Download the JJ9 image.zip
   
3. Unzip the image file and copy to /sdcard/image
   
4. Replace the *.img files in /sdcard/image with the ones I created in my nandroid backup
   
5. Follow the TPT procedures to install the image
   

That seems like a simple process which would mean I end up with my existing ROM but with changed partitions, is life really that simple though?

Thanks

[Guest rjm2k]

I am happy on the stock rom I am currently on but want to use the spare space in /system. Would the following process mean I end up with my existing stock ROM as it is currently but with a 128MB /system partition (I am currently using 122MB on /system so it should fit fine):

1. Do a clockwork nandroid backup
   
2. Download the JJ9 image.zip
   
3. Unzip the image file and copy to /sdcard/image
   
4. Replace the *.img files in /sdcard/image with the ones I created in my nandroid backup
   
5. Follow the TPT procedures to install the image
   

That seems like a simple process which would mean I end up with my existing ROM but with changed partitions, is life really that simple though?

Thanks

Yep, that's what I did previously

[Guest womble_sanfran]

Yep, that's what I did previously

Thanks that sounds very simple, fingers crossed it turns out that way!

[Guest ztedd]

@womble_sanfran & @rjm2k: I realized that you don't need all of the *.mbn files from an TPT image. It's enough to have the files 'appsboot.mbn' and 'partition_zte.mbn', perhaps also these 2 files are needed: 'appsboothd.mbn' and 'partition.mbn'. I just tried it with the four files (+ *.bin from my nandroid backup) and it worked. Perhaps it would even be enough with only the 2 files.

I just postet a howto on how to get free space, including how to change partition layout (for ALL ROMs). Have a look here:

[GUIDE] How to get more FREE SPACE for your apps

@rjm2k: perhaps you can edit your first post in this thread to include a howto like this?

Edited February 1, 2011 by ztedd

[Guest CSeh Zoltán]

Hello

FLB-ROM cache exists to redirect script?

JJ9 to find, but it does not work FLB-ROM.

[Guest ztedd]

Hello

FLB-ROM cache exists to redirect script?

JJ9 to find, but it does not work FLB-ROM.

In FLB, the location of the user boot scripts is different. It's /etc/init.d/ so there you have to put the JJ cache redirector script (using Rootexplorer or ES File Explorer).

Sorry for forgetting this, I will update my Guide ( http://android.modaco.com/content/zte-blad...-for-your-apps/ ) this evening.

[Guest CSeh Zoltán]

In FLB, the location of the user boot scripts is different. It's /etc/init.d/ so there you have to put the JJ cache redirector script (using Rootexplorer or ES File Explorer).

Sorry for forgetting this, I will update my Guide ( http://android.modaco.com/content/zte-blad...-for-your-apps/ ) this evening.

Ok, I wait for your help. I follow your topic.

Thanks.

[Guest wbaw]

If you add these lines to /system/etc/init.qcom.post_boot.sh then it should work with more different roms.

#### START - Redirect cache partition to /data ####

mkdir /data/cache

chown system.cache /data/cache

chmod 770 /data/cache

mkdir /data/cache/recovery

chown system.cache /data/cache/recovery

chmod 770 /data/cache/recovery

mkdir /data/cache/lost+found

chown root.root /data/cache/lost+found

chmod 770 /data/cache/lost+found

ln -s /data/dalvik-cache /data/cache/dalvik-cache

rm /cache/*.apk

rm /data/cache/*.apk

umount /cache

rmdir /cache

ln -s /data/cache /cache

#### END - Redirect cache partition to /data ####

[/codebox]

[Guest suriya83]

can someone explain how i can get this partition layout currently i'mn running de-crossed 2.2 with 128mb system partition (from japanese jellyfish)

thanks in advance

P.S. i have the .zip file from the original post

New partition layout :P

~ # cat /proc/mtd

dev:	size   erasesize  name

mtd0: 00480000 00020000 "recovery"

mtd1: 00480000 00020000 "boot"

mtd2: 00180000 00020000 "splash"

mtd3: 00060000 00020000 "misc"

mtd4: 02940000 00020000 "cache"

mtd5: 08f80000 00020000 "system"

mtd6: 11020000 00020000 "userdata"

mtd7: 00180000 00020000 "persist"

~ # df -h

Filesystem				Size	  Used Available Use% Mounted on

tmpfs				   207.5M		 0	207.5M   0% /dev

/dev/block/mtdblock4	 41.3M	  1.2M	 40.1M   3% /cache

/dev/block/mtdblock6	272.1M	 38.0M	234.1M  14% /data

/dev/block/mtdblock5	143.5M	 92.8M	 50.7M  65% /system

Use the attached modified appsboot.mbn and partition_zte.mbn if you don't want to do it yourself.

It looks like both partitions still successfully mount after the change without rewritting them, but I would expect some corruption. It would be a good idea to rewrite the system and userdata partitions.

PS. I take no responsibility for any bricked devices using the attachment. It worked for me, but that doesn't mean it'll work for everyone. That said it does appear fairly safe, I'm just not sure if appsboot.mbn is actually the bit that is doing the flashing so playing with it potentially could brick the phone.

Edited February 13, 2011 by suriya83

[Guest wbaw]

can someone explain how i can get this partition layout currently i'mn running de-crossed 2.2 with 128mb system partition (from japanese jellyfish)

thanks in advance

P.S. i have the .zip file from the original post

That zip file would give you a larger system partition, so i don't think it's of any use to you, it's just going to give you less room for apps.

Anyway, if you want to change partition sizes, without changing roms or losing your data, then follow this.

First do a nandroid backup, then copy boot.img system.img & data.img from your latest backup to your computer. Rename data.img to userdata.img

Make sure that all the .img files you flash aren't bigger than the partitions you're flashing them to.

Unzip the japanese jellyfish image install on your computer, then copy your nandroid backup .img files over the ones in the japanese jelly /image folder.

Download the zip file with the partition layout you want, extract those files into your /image folder too, overwriting the jj files.

Copy your new image folder to your phone's sdcard & install using the volume up & power on key combination.

[Guest oh!dougal]

With the advent of CyanogenMod7, there ought to be an interest in a suitable, and suitably conservative, partitioning tool.

I was thinking of a TPT install to deliver something along the lines of standard 42mb /cache, and a /system that was maybe 140mb - so it isn't going to become tight as development/theming/adding-in/etc progresses.

That would provide a significant, useful expansion of /data (compared to standard) and that benefit would be without any compromise to the easy installability of modern/current developments, and without any need of additional special patching.

If CM7 is going to be going through a period of 'nightly' builds, then it would be much easier to be able to use those builds, as is, rather than requiring to patch or trim each of them because of the way one was partitioned

Putting Clockwork3 as the content of the recovery partition would make for the easiest possible adoption of CM7.

But overall, the idea would be to optimise for ease of use, while usefully expanding the user data partition.

Any offers? :D

Edited February 17, 2011 by oh!dougal

[Guest wbaw]

Dougal, I did it yesterday. Most of it at least.

CM doesn't use the /cache partition if it's small, it uses the sdcard*, so theres no reason to have a /cache partition for cm. So you don't need any patch with cm to get rid of the cache partition. The patches are just for the older zte based roms (and it should work with all of those now).

So you can just download my partitioning tool from here, latest version is 1.5mb cache, 136mb system, 319mb data - http://android.modaco.com/content-page/330...nation/page/60/ I've also removed the excess hungarian firmware files to make it faster & safer, it's just the bare minimum required to repartition.

The boot image in that is seb's clockworkmod 2, but you can easily replace it with clockwork 3 if you prefer, just rename the clockwork 3 recovery image to boot.img & overwrite the one in the mod. It wont overwrite any recovery program that you already have installed, so you can just boot with volume - to get into your existing recovery. It just writes clockworkmod 2 to the boot partition, so it boots straight into that after it's repartitioned, theres no need to change the recovery partition.

It's not hard to edit your own partition sizes, if you can use a hex editor & have a calculator that works in hex.

The CM RC1 build has a system partition that is 112mb, it'll be a bit bigger with the google apps & it's a bit bigger when it's on the phone, but it should be no more than 120mb. 136mb system gives plenty of room to play with, there's even 2.5mb free with the basic modaco r12 & there is quite a lot of extras added to that, it seems to be the biggest current popular rom. You should have room for all but the fattest custom roms or stock roms with 136mb.

Added later ...

*The RC1 of CM7 uses /data instead of /cache if /cache is too small, the older versions used the sdcard. It still doesn't need a patch though, the script to do it is built in, as it was in cm6 & the earlier cm7 builds.

Edited February 17, 2011 by wbaw

[Guest oh!dougal]

Dougal, I did it yesterday. Most of it at least.

CM doesn't use the /cache partition if it's small, it uses the sdcard*, so theres no reason to have a /cache partition for cm. So you don't need any patch with cm to get rid of the cache partition. The patches are just for the older zte based roms (and it should work with all of those now).

...

*The RC1 of CM7 uses /data instead of /cache if /cache is too small, the older versions used the sdcard. It still doesn't need a patch though, the script to do it is built in, as it was in cm6 & the earlier cm7 builds.

Thanks, that was one missing piece of the jigsaw!

It was for easing the back and forth process that I was thinking a standard /cache might help. Has the cache-relocation script been looked at for Seb's deCrossed? While I'm not rushing to jump onto Cyanogen7 yet (tho a lot of people are), I wouldn't mind having a look at it, and that's sufficiently awkward as to be discouraging. (You plan your moves ahead when your computer won't run adb and fastboot! PPC Mac, BTW.)

And I was thinking that preloading Clockwork3 in /recovery of a TPT would allow an easy install with appropriate (and versatile) partitioning in one hit.

Edited February 17, 2011 by oh!dougal