Partition layout change

[Guest Tom G]

it's this number which worry me

any advice ?

Remove stuff from system? Move some apps to /data.

[Guest oh!dougal]

i'm trying to make an easy way to restore a backuped phone

i have dowloaded fix.zip

replaced the imgs files in with the backup of clock

but ...... i have (jellyfish rom)

...

any advice ?

kk has taken the route of using the "spare" space on /system to store lots of 'pre-installed' apps.

To slim his /system to fit the 64mb smaller partition, you should dump some of the apps from /system/apps

[Guest Phoenix Silver]

not taken the route came as it in jellyfish

humm oki i have to take a look in system/app to clean this

just moving the apk in /data/app

is this oki ?

[Guest jt_mcg]

kk has taken the route of using the "spare" space on /system to store lots of 'pre-installed' apps.

To slim his /system to fit the 64mb smaller partition, you should dump some of the apps from /system/apps

Which caused a lot of people to unfairly criticise the ROM as bloated, but it was really the most rational thing to do at that point in time to avoid wasting otherwise empty MBs on System

[Guest isambard]

Which caused a lot of people to unfairly criticise the ROM as bloated, but it was really the most rational thing to do at that point in time to avoid wasting otherwise empty MBs on System

agreed. but now that repartitioning works, i think it now makes sense to make lean stable roms and then create a secondary add-on pack with favourite apps.

each user probably wants to create his own userdata.img and this should free up the rom creators from having to make decisions on which apps to include.

now, let's see what the minimum possible rom is... :unsure:

[Guest Phoenix Silver]

oki this is what i have now

# df -h

Filesystem Size Used Available Use% Mounted on

tmpfs 208.3M 12.0K 208.3M 0% /dev

/dev/block/mtdblock5 207.5M 127.3M 80.2M 61% /system

/dev/block/mtdblock6 208.1M 99.6M 108.5M 48% /data

preparing a try

[Guest isambard]

oki this is what i have now

# df -h

Filesystem Size Used Available Use% Mounted on

tmpfs 208.3M 12.0K 208.3M 0% /dev

/dev/block/mtdblock5 207.5M 127.3M 80.2M 61% /system

/dev/block/mtdblock6 208.1M 99.6M 108.5M 48% /data

preparing a try

good luck, if you use my volcano mod, you'll end up with something like this:

Filesystem                Size      Used Available Use% Mounted on

tmpfs                   208.3M     12.0K    208.3M   0% /dev

/dev/block/mtdblock5    128.0M    123.8M      4.2M  97% /system

/dev/block/mtdblock6    287.6M        0M    287.6M 100% /data[/codebox]

Edited January 2, 2011 by isambard

[Guest jt_mcg]

agreed. but now that repartitioning works, i think it now makes sense to make lean stable roms and then create a secondary add-on pack with favourite apps.

each user probably wants to create his own userdata.img and this should free up the rom creators from having to make decisions on which apps to include.

now, let's see what the minimum possible rom is... :unsure:

Agree 100%, I haven't done your volcano yet (will probably tweak the process a bit myself), but your removals on Seb's are along my lines of thinking.

Create a slim bulletproof system partition and have loads of space on data to play around with.

[Guest oh!dougal]

agreed. but now that repartitioning works, i think it now makes sense to make lean stable roms and then create a secondary add-on pack with favourite apps.

each user probably wants to create his own userdata.img and this should free up the rom creators from having to make decisions on which apps to include.

now, let's see what the minimum possible rom is... :unsure:

Absolutely -- I had been considering a "rom strategy" thread.

But here goes anyway.

/system should have "nothing that could better go elsewhere".

But equally, it shouldn't be so stripped as to remove phone usefulness from users.

The idea ought to be to put into system, things that need to be there and might cause hassle for users trying to put them there.

So, I don't see advantage in limiting the keyboard choice, for example.

But as far as possible, all apps (apart from core ZTE - unlikely to be upgraded - apps) should be moved out of /data.

Does it make sense to leave 'core' Gapps? Or would they (could they) all start off in /data ??

How much 'headroom' is needed in /system?

Since its ordinarily ro, not much would be expected to write to it ... so how tightly 'fitted' could it be?

Does it make sense to have the Hungarian TPT ("total phone transplant") method as the standard install, and expect rom-devs to set their own optimised partitioning? Or should a "new-standard, v1" partitioning be agreed, continuing to use Clockwork to flash in the rom? While this would be less phone-storage-efficient, it would make for smaller downloads, and less bandwidth usage problems.

[Guest superkryo]

4.: download this: http://toxicdog.hu/fix.zip (basically its the t-mobile low level firmware update tool with the hex-edited partition table information file)

What's the md5 for fix.zip? I've got unpacking error with the download (3 times). Thanks

[Guest kallt_kaffe]

Absolutely -- I had been considering a "rom strategy" thread.

But here goes anyway.

/system should have "nothing that could better go elsewhere".

But equally, it shouldn't be so stripped as to remove phone usefulness from users.

The idea ought to be to put into system, things that need to be there and might cause hassle for users trying to put them there.

So, I don't see advantage in limiting the keyboard choice, for example.

But as far as possible, all apps (apart from core ZTE - unlikely to be upgraded - apps) should be moved out of /data.

Does it make sense to leave 'core' Gapps? Or would they (could they) all start off in /data ??

How much 'headroom' is needed in /system?

Since its ordinarily ro, not much would be expected to write to it ... so how tightly 'fitted' could it be?

Does it make sense to have the Hungarian TPT ("total phone transplant") method as the standard install, and expect rom-devs to set their own optimised partitioning? Or should a "new-standard, v1" partitioning be agreed, continuing to use Clockwork to flash in the rom? While this would be less phone-storage-efficient, it would make for smaller downloads, and less bandwidth usage problems.

Everything that can be found in Market can be trimmed off a ROM. Still I suppose ROMs propably should continue to be built for Clockwork. That way, a slim ROM can always be installed wether you have changed your partitions or not. Perhaps we could have a number of dummy "partition changing" installs with a number of steps between a lower limit, perhaps at 128Mb, system up to the default system size. Perhaps 128Mb and then steps of 16Mb?

ROMs then will have to specificy what the lowest system size they support and they will work on that and all the steps above (and most importantly, they will work for those who don't want to change their partition sizes at all). You could even make one "bloated" version for non modified parition sizes and a lite version with the bare minimum for the hard core parition changing users.

Btw, nice work guys!

Edited January 2, 2011 by kallt_kaffe

[Guest Phoenix Silver]

worked like a charm with my own bakuped imgs

great job guys

tyvm

[Guest isambard]

/system should have "nothing that could better go elsewhere".

But equally, it shouldn't be so stripped as to remove phone usefulness from users.

The idea ought to be to put into system, things that need to be there and might cause hassle for users trying to put them there.

But as far as possible, all apps (apart from core ZTE - unlikely to be upgraded - apps) should be moved out of /data.

agreed.

How much 'headroom' is needed in /system?

Since its ordinarily ro, not much would be expected to write to it ... so how tightly 'fitted' could it be?

Does it make sense to have the Hungarian TPT ("total phone transplant") method as the standard install, and expect rom-devs to set their own optimised partitioning? Or should a "new-standard, v1" partitioning be agreed, continuing to use Clockwork to flash in the rom? While this would be less phone-storage-efficient, it would make for smaller downloads, and less bandwidth usage problems.

my last proof of concept rom has 4mb headroom.

for mean the hungarian method has several advantages:

- no need to install adb/clockwork. particularly useful if you are new and you are installing your first rom

- easy for users to mix and match: e.g. can separate BOOT, RECOVERY, SYSTEM and USERDATA.

- users can customise their own mix of apps into a customer userdata.img and add to whatever is the latest (system/boot) ROM of their choice

- reduced bandwidth (only need to download needed components AND system images should be smaller as they get stripped down to minimum with apps being left in userdata by default).

- faster install

Edited January 2, 2011 by isambard

[Guest jt_mcg]

Absolutely -- I had been considering a "rom strategy" thread.

But here goes anyway.

/system should have "nothing that could better go elsewhere".

But equally, it shouldn't be so stripped as to remove phone usefulness from users.

The idea ought to be to put into system, things that need to be there and might cause hassle for users trying to put them there.

So, I don't see advantage in limiting the keyboard choice, for example.

But as far as possible, all apps (apart from core ZTE - unlikely to be upgraded - apps) should be moved out of /data.

Does it make sense to leave 'core' Gapps? Or would they (could they) all start off in /data ??

How much 'headroom' is needed in /system?

Since its ordinarily ro, not much would be expected to write to it ... so how tightly 'fitted' could it be?

Does it make sense to have the Hungarian TPT ("total phone transplant") method as the standard install, and expect rom-devs to set their own optimised partitioning? Or should a "new-standard, v1" partitioning be agreed, continuing to use Clockwork to flash in the rom? While this would be less phone-storage-efficient, it would make for smaller downloads, and less bandwidth usage problems.

I don't think that there's all that much overhead added to the Hungarian TPT, 98 or 99MB on what I'm guessing was a hungarian ROM with usual operator bloat and I think that clockwork can't be much larger than standard recovery etc.

I think there's obviously a lot of benefit in the TPT, especially for new users and those coming from stock. There's nothing stopping updates, bugfixes, themes etc from being installed as they are now with clockwork after the TPT has been done.

[Guest oh!dougal]

Everything that can be found in Market can be trimmed off a ROM. Still I suppose ROMs propably should continue to be built for Clockwork. That way, a slim ROM can always be installed wether you have changed your partitions or not. Perhaps we could have a number of dummy "partition changing" installs with a number of steps between a lower limit, perhaps at 128Mb, system up to the default system size. Perhaps 128Mb and then steps of 16Mb?

ROMs then will have to specificy what the lowest system size they support and they will work on that and all the steps above (and most importantly, they will work for those who don't want to change their partition sizes at all). You could even make one "bloated" version for non modified parition sizes and a lite version with the bare minimum for the hard core parition changing users.

Btw, nice work guys!

Yes, if the rom is supplied for a Clockwork install, it brings along compatibility questions.

One beauty of the TPT install is that it expects only standard phone hardware - apart from the three-fingered salute, its very simple to use.

Clockwork looks like being the best thing (for now) in the recovery side, nandroid backups being even more worthwhile!

Maybe the thing to do is to publish the r1 as a TPT package, and issue patches,tweaks and bugfixes as zip updates to fit the initial partitioning?

Edited January 2, 2011 by oh!dougal

[Guest StevenHarperUK]

Perhaps we could have a number of dummy "partition changing" installs with a number of steps between a lower limit, perhaps at 128Mb, system up to the default system size. Perhaps 128Mb and then steps of 16Mb?

I agree; this could be a good standard.

The Partition changing installs (Zip files) just contain

/image/partition_zte.mbn

And are named something like

ZTE_Blade-System_128MB.zip

ZTE_Blade-System_136MB.zip

ZTE_Blade-System_144MB.zip

ZTE_Blade-System_152MB.zip

ZTE_Blade-System_160MB.zip

ZTE_Blade-System_STOCK.zip

Then ROM developers can simply add the

system.img

and optionally the

boot.img

recovery.img

How does that sound. Just the less versions of the ZTE_Blade-System_* files we have been created (and people getting them wrong) - the less chance there is that we are going to end up with bricked devices?

Is that correct?

[Guest rjm2k]

What's the md5 for fix.zip? I've got unpacking error with the download (3 times). Thanks

me too! :S

[Guest toxicdog]

MD5 hash for fix.zip (101 117 405 bytes) :

07AF1B2851CC22189BA6127B14F31E63

EDIT: I've got the same unpack error! dont know what happened, uploading again.

EDIT2 Finished uploading, http://www.2shared.com/file/e9vdb0pa/romsize.html

(just fix.zip, renamed :unsure: )

need mirrors B)

actually you can make your own fix.zip, just download resize.zip from this thread, and the other zip from the 512mb memory unlock thread (t-mobile hungarian firmware update), and just extract the firmware update zip, THEN resize.zip, OVERWRITING files.

Thats what i've done in fix.zip

Edited January 2, 2011 by toxicdog

[Guest IronDoc]

When you guys say that users can create their own userdata images, how do you mean? Do you get that from installing your chosen apps etc and doing a nandroid or can you edit the img using unyaffs or similar.

[Guest isambard]

When you guys say that users can create their own userdata images, how do you mean? Do you get that from installing your chosen apps etc and doing a nandroid or can you edit the img using unyaffs or similar.

easiest way is to install your own and then do a clockworkmod backup. you can then rename the data.img produced to userdata.img

for example, i have 2 phones, one for use and one for development. when i'm happy with the stability of the development version, i create the system.img from the development and copy userdata.img from my normal phone. then i can upgrade both phones to have the lastest system but also with my choice of user apps and data.

[Guest rickywyatt]

if this has been asked before im sorry but cant we add some of the cache space as mine is 40mb?

[Guest oh!dougal]

if this has been asked before im sorry but cant we add some of the cache space as mine is 40mb?

I don't believe anyone knows the answer to that, as yet.

Do you want to do some experimentation?

[Guest isambard]

if this has been asked before im sorry but cant we add some of the cache space as mine is 40mb?

yes, it's possible. is this a common problem? i haven't hit any cache space issues yet.

[Guest oh!dougal]

my last proof of concept rom has 4mb headroom.

Themes.

Plenty people seem to want to "theme" their phones.

That's going to take more space on /system, isn't it?

And is it going to need space for doing the install?

I think 4mb is too tight for most "themers".

But how much is a reasonable amount of space to leave?

Any theme-makers care to suggest how much space they think should be left?

[Guest fonix232]

yes, it's possible. is this a common problem? i haven't hit any cache space issues yet.

I think he meant to move /cache to /data!

But that's not possible, the two partitions aren't next to each other, and you can't move the boot partition (/cache is before boot, so you can't resize), as you would need a new boot base address...