DISCLAIMER: Nobody -- and I do mean nobody -- is responsible for a bricked device except for the person attempting this modification. Do not contact me, Firerat, Cyanogen or anyone else to complain that you borked your Slide by not following instructions.
ORIGINAL THREAD
All credit for this work goes to Firerat and lbcoder -- especially to Firerat for making this so darn easy!
This post will provide instructions for resizing your device's MTD partitions.
PREREQUISITES:
An understanding of basic arithmetic
Familiarity with disk partitioning
S-OFF
The Espresso has 465.1 MB to play around with and it ships with the following partition layout:
System: 240 MB
Data: 145.1 MB
Cache: 80 MB
You can check your current layout by launching an ADB SHELL and entering the following command:
Code:
busybox df -h
You will likely notice that the system partition has a *lot* of free space, likely well over 100 MB available! The instructions in this post will walk you through requisitioning that available space and putting it into the data partition, avoiding the need to ever use Apps2SD or Apps2EXT.
So let's get started...
Step 1: Downloading the necessary files
Firerat's Mediafire repository can be found here... You will need two files from it:
Custom MTD recovery zip
Custom MTD boot zip
Download those files and place them on your sdcard.
Step 2: Configuring your partition scheme
As I mentioned earlier, by executing the busybox command you'll get an idea of how much empty space you have on your system partition. Your choices in the section depend entirely on the rom you are using -- for the sake of simplicity I will be assuming the use of a CM6-based rom.
So, once again, launch an ADB SHELL...
You're going to be executing an echo command to create a text file on the root of your sdcard -- this text file will contain the information needed to re-partition your internal memory. This is where you have to make your own choice about sizing -- here is the format of the command you must enter:
Code:
echo "mtd [SYSTEM SIZE IN MB] [CACHE SIZE IN MB]" > /sdcard/mtdpartmap.txt
For my partition scheme on an Espresso running CM6.1.1 I executed the following:
Code:
echo "mtd 140 1.5" > /sdcard/mtdpartmap.txt
NOTES:
If you're using a CM6-based rom you do not need a large cache partition as a script will bind-mount cache -- the smallest size you can set is 1.5 MB -- other roms have their own cache size requirements, so do your research before setting this to a low value.
All partition sizes must be rounded up to the nearest 0.125 MB, but I recommend using increments of 0.5 MB.
All the excess storage not set aside for system and cache will be used for the data partition.
Step 3: Getting your hands dirty
NOTE: If you had previously configured your device to use apps2ext you will need to perform one additional restoration in step 7. See below for more details...
So assuming you've now downloaded the two zip files (step 1) and added the mtdpartmap.txt file to the root of your sdcard (step 2), you're ready to proceed with the nitty-gritty work. For the sake of simplicity I'm assuming that during the S-OFF procedure you opted to [permanently] flash ClockworkMod Recovery 2.5.0.1 on your device.
Boot your Slide into recovery -- my preferred method is to use ADB REBOOT RECOVERY.
Execute a Nandroid Backup -- within recovery: nandroid->Backup
Wipe your data and cache partitions -- within recovery: wipe data/factory reset
Flash the recovery patcher -- within recovery: install zip from sdcard->choose zip from sdcard->recovery-v1.5.8-Beta-CustomMTD_S.zip
Format the system, data and cache partitions -- within recovery: partitions menu->format [system/data/cache]
Reboot into recovery -- within recovery: advanced->Reboot Recovery
Execute an advanced Nandroid restore of system and data* -- within recovery: nandroid->Advanced Restore->[CHOOSE THE BACKUP]->Restore [system/data]
Flash the boot patcher -- within recovery: install zip from sdcard->choose zip from sdcard->boot-v1.5.8-Beta-CustomMTD_S.zip
Reboot -- within recovery: reboot system now
* Devices with apps2ext configurations must remember to nandroid restore the sd-ext partition as well.
And that should do it. Be patient on first boot as it may take a little longer than expected. To verify that your changes have worked you can repeat the busybox command I listed earlier:
Code:
busybox df -h
Moving forward, let's say you want to flash the latest CM6 nightly -- simply flash the nightly zip (and gapps if necessary) and, immediately after that, flash the boot patcher (boot-v1.5.8-Beta-CustomMTD_S.zip).
I do not plan to field questions in this thread, so if you're looking for support I suggest that you visit the #mytouchslide channel on Freenode IRC.
And, once again, ALL CREDIT goes to Firerat and lbcoder.
Additional Notes (provided by Firerat)
Removal
There are two ways to remove customMTD ( to return to stock layout ):
Flash an unmodified recovery.img (NOTE: You must format system, cache and data)
Edit the mtdpartmap.txt to have a system size of 0 -- e.g. echo "mtd 0" > /sdcard/mtdpartmap.txt -- and flash the recovery patcher (NOTE: You must format system, cache and data)
Resizing
If you wish to resize, change the mtdpartmap.txt and flash recovery patcher (NOTE: You must format system, cache and data)
Recovery Upgrade
The easiest way to upgrade recovery is to flash manually in recovery via an ADB SHELL while booted into recovery:
Code:
mount /sdcard
flash_image recovery /sdcard/RECOVERY_VERSION#.img
NOTE: You do not need to format system, cache and data in this case as you are not resizing.
Again, thanks go out to Firerat for these additional notes.
Damn I was going to post this later, well done bro thank you
Sent from my T-Mobile myTouch 3G Slide using XDA App
Many thanks for the clear instructions that were surprisingly easy to follow and the phone did boot up again just fine (as noted in the OP, the boot up took longer the first time around, but there is always
Code:
adb logcat
for anyone worried about what the phone is doing when it looks bored). Total data space is now 320 MB (and sleepykit is one happy kitten).
Many thanks, sir!
Sent from my HTC Espresso running CM6.
Ty very much
Sent from my T-Mobile myTouch 3G Slide using XDA App
@HebrewToYou
very good post
I think it's the clearest I have seen to date
just couple of points which I think would prove useful
Removal
there are two ways to remove customMTD ( to return to stock layout )
the first is to simply flash an unmodified recovery.img
Note You *must* format system, cache and data with clockwork or use
fastboot erase system -w
the second is to edit the mtdpartmap.txt to have a system size of 0
e.g.
echo "mtd 0" > /sdcard/mtdpartmap.txt
flash the recovery patcher
again you must format system, cache and data
Resizing
if you wish to resize
change the mtdpartmap.txt
flash recovery patcher
format system, cache and data
Recovery Upgrade
the easiest way to upgrade recovery is to flash manually
in recovery ( adb shell )
mount /sdcard
flash_image recovery /sdcard/recovery<version>.img
via running recovery ui
flash recovery patcher
Note, you don't need to format system, cache and data, as you are not resizing
Thanks for this!
myTouch 3G Slide using XDA App
Firerat said:
@HebrewToYou
very good post
I think it's the clearest I have seen to date
just couple of points which I think would prove useful
Click to expand...
Click to collapse
Firerat, thank you for the compliment! It means a lot.
I'll add your notes to the second post of the thread.
On Cm based roms you should be able to shrink system to atleast 100, mines is currently 100MB, but actual usage is 89MB(I removed some stuff)
Ace42 said:
On Cm based roms you should be able to shrink system to atleast 100, mines is currently 100MB, but actual usage is 89MB(I removed some stuff)
Click to expand...
Click to collapse
You're free to make system whatever size you like -- my recommendations are just that: recommendations. The size I suggested will likely be large enough to accommodate CM7 when it is released -- I cannot say the same about 100 MB...
Thank you for this clear, concise, well formatted tutorial. Easy to read and follow extra /data/ memory made my day.
nice tutorial. too bad im using cr-mod and current system usage is at 204. does this ever change or does it only change with different roms because I want to shrink it to about 210 but i dont want any hidden surprises
lilshortwun said:
nice tutorial. too bad im using cr-mod and current system usage is at 204. does this ever change or does it only change with different roms because I want to shrink it to about 210 but i dont want any hidden surprises
Click to expand...
Click to collapse
Sense roms always have large system sizes, vanilla ones are normally under 100~. You can always delete some apps from sys that you dont want to shrink it even more, but there should be no hidden traps if you make it 210. I am so happy that we finally have mtd cause i dont use ext anymore and i dont like apps2sd either. On Cm I have 372 in total for data, which is more than enough for me.
does it make the phone faster or just more space to install the app?
chiensibut said:
does it make the phone faster or just more space to install the app?
Click to expand...
Click to collapse
It doesn't make the phone faster... It gives you fine control over how your phone's internal memory is allocated. If you're running a non-stock rom, there's no reason to have such a huge /system partition. This will allow you to remedy that.
thank you for this. didnt even know we had all the extra space on our phones
only thing is i didnt understand what was said about the cache. i noticed my phone was using >60MB so i gave it 80. wish i could have gotten it down to 1.5 like you did
guitarist5122 said:
thank you for this. didnt even know we had all the extra space on our phones
only thing is i didnt understand what was said about the cache. i noticed my phone was using >60MB so i gave it 80. wish i could have gotten it down to 1.5 like you did
Click to expand...
Click to collapse
Cache is not permanently stored data -- it's just a temporary repository. CM6-based roms will bind-mount /cache to /data if the size is too small, which it will be if you set it to 1.5 MB. That way you can repurpose the 80 MB of /cache and put it directly towards /data -- then /data becomes a shared space /data and /cache which is much better (IMHO).
HebrewToYou said:
Cache is not permanently stored data -- it's just a temporary repository. CM6-based roms will bind-mount /cache to /data if the size is too small, which it will be if you set it to 1.5 MB. That way you can repurpose the 80 MB of /cache and put it directly towards /data -- then /data becomes a shared space /data and /cache which is much better (IMHO).
Click to expand...
Click to collapse
ahhhhh, now i get it. thx for breaking it down
Does this make the phone think that space on an SD card is in /data? So if lets say I have a 4GB partition on my sd card I can make the phone think that partition is /data?
Related
I have a Droid Eris but I made the fatal mistake of putting clockwork recovery on it :'( and now I can't do anything with it because of the following:
1.) Can't install PB00IMG.zip from HBOOT because: "Main version is Older!" (I've checked the md5sums and everything lines up)
PB00100 XC SHIP S-ON
HBOOT-1.49.0000 (PB0010000)
MICROP-0111
TOUCH PANEL-SYN0104
RADIO-2.42.01.04.27
Feb 8 2010,00:08:56
2.) Clockworkrecovery 2.5.0.1 (I get the error message below)
3.) A bad deployment of GSB Gingerbread (2/18/2011) {Stays on Android skateboard screen and never does anything}
Is there anything I can do with this combination of stuff to get my phone booting into Android again?
Any help (even a "you're screwed" message) would be of help. Thanks guys
ttp://img834.imageshack.us/img834/8232/img20110221103304.jpg
KannedFarU said:
I have a Droid Eris but I made the fatal mistake of putting clockwork recovery on it :'( and now I can't do anything with it because of the following:
1.) Can't install PB00IMG.zip from HBOOT because: "Main version is Older!" (I've checked the md5sums and everything lines up)
PB00100 XC SHIP S-ON
HBOOT-1.49.0000 (PB0010000)
MICROP-0111
TOUCH PANEL-SYN0104
RADIO-2.42.01.04.27
Feb 8 2010,00:08:56
2.) Clockworkrecovery 2.5.0.1 (I get the error message below)
3.) A bad deployment of GSB Gingerbread (2/18/2011) {Stays on Android skateboard screen and never does anything}
Is there anything I can do with this combination of stuff to get my phone booting into Android again?
Any help (even a "you're screwed" message) would be of help. Thanks guys
ttp://img834.imageshack.us/img834/8232/img20110221103304.jpg
Click to expand...
Click to collapse
Don't do anything further to your phone until you have answered a couple of questions. In the meantime, plug your phone onto the charger and keep it fully charged. The steps you take at this moment are extremely critical. In particular, I would recommend that you avoid attempting to flash a PB00IMG.ZIP file or run an RUU until you have investigated a few more things.
First, let's find out about your skills and resources:
Q1) Do you know how to use "adb" and the command line?
Q2) You are still able to boot into recovery, HBOOT, and Fastboot modes, right?
I'll post another entry in a minute or two - I want this to get up on the board ASAP.
OK, so here's the deal about that symlink error.
It can result from two different conditions - one of which is innocuous, and one of which is "near-death".
In the "near-death" case, flashing a PB00IMG.ZIP file or running an RUU sometimes results in a hard brick, so, for the moment you should avoid that.
So, if it is the "innocuous case", what happens is that you simply flashed a ROM file which was truncated or corrupted. The installer script performs a lot of "symlink" installations after files have been unpacked from the "system" area in the ROM file; if that fails so that the target of the symlink is not found, you get an error similar to what you see in your .jpg file.
(BTW, this is the exact reason that newbs are advised to stay away from Clockwork - it does not perform signing verification of ROM files to check that they are complete and uncorrupted. Amon_RA does this, so that it is impossible to flash a corrupted ROM using Amon_RA - but ClockworkMod does not provide you that protection).
The second cause is much more sinister - we have observed cases where something in Clockwork ends up causing the MTD driver in the kernel to mark a massive number of pages in flash memory as if they had fatal flaws - they can not be reclaimed by the standard erasure methods that the custom recoveries normally use. The net effect is that when you try and load a new ROM onto the phone (assuming that the ROM file is correct, complete, and uncorrupted), the installer runs out of space and the installation fails.
[SIZE=+2]We will need to be able to discriminate between those two cases to determine how to proceed next.[/SIZE]
The most direct way to detect this more critical problem is to boot into ClockworkMod recovery, create a shell on the phone using "adb", and then attempt to "mount" the /system mount point. It is possible that this will fail; but if it succeeds, you then erase everything in /system, and do a "df" command to look at available space on the phone, as in:
Code:
C:\WindozeSucks> [COLOR=green]adb shell[/COLOR]
# [COLOR=green]mount /system[/COLOR]
[COLOR=grey](If the above command fails, proceed no further)[/COLOR]
# [COLOR=green]cd /system[/COLOR]
# [COLOR=green]df -k /system[/COLOR]
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/block/mtdblock3 174080 112128 61952 64% /system
# [COLOR=green]rm -rf /system/*[/COLOR]
# [COLOR=green]df -k /system[/COLOR]
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/block/mtdblock3 174080 112128 61952 64% /system
# [COLOR=green]cd /[/COLOR]
# [COLOR=green]umount /system[/COLOR]
The example output of the "df -k" command above is from my phone where I did not erase the /system folder. Note that its total size is about 174,000 kB (roughly 170 MB). If you have a bunch of bad pages, your total size will be quite a bit smaller than this. Note also that it reports the "Use%". If you are showing 100% use when you first run the "df" command, this likely also indicates a problem of this nature.
When you actually erase all the files in the /system folder, the 2nd time you run the "df -k /system" command, you should see a very low total "Use%" - about 1%. Note that his erasure does not correct the problem - we are only trying to find out what state your phone is in at the moment.
2) If you are not familiar with using adb, there is an indirect route you can take, which is to determine if the ROM file on your SD card is corrupt or not.
Ahhh, ****, I forgot that ClockworkMod doesn't have a MS-USB mode
Again, boot into Amon_RA, connect to the PC, and then toggle "MS-USB toggle" from the Amon_RA menu. Then use a file explorer on the PC to find out the exact size of the ROM file on the SD card (down to the very last byte). If it is exactly the correct size, it is somewhat unlikely that this is a simple problem of a corrupted ROM file. If you know how to do it, compute the "MD5" signature of this ROM, and report both the exact total file size (in bytes) and the MD5 signature.
I'll provide more instructions after you respond.
bfb0
PS You didn't mention WHICH PB00IMG.ZIP file you were trying to flash, nor the exact version of GSB you used - I presume you mean the ROOT version/GSB v1.6, but you ought to clear that up to avoid any ambiguities.
I can post up a flashable zip that will allow you to replace your ClockworkMod recovery boot with Amon_RA, so don't get discouraged yet.
Such a thing is trivial to do - it's never been done so far on the Eris forum because the emphasis of rooting was on getting any custom recovery in place, rather than replacing a custom recovery with another custom recovery.
But, I think it is important to use non-destructive methods first to investigate as thoroughly as possible; because your current recovery boot is your lifeline to getting the phone back, we should avoid that until I've received some feedback from you.
bftb0
Nevermind.
bftb0 said:
Ahhh, ****, I forgot that ClockworkMod doesn't have a MS-USB mode
Click to expand...
Click to collapse
In ClockWork Mod Recovery it's under the Partitions menu, I think at the bottom of the list.
roirraW "edor" ehT said:
In ClockWork Mod Recovery it's under the Partitions menu, I think at the bottom of the list.
Click to expand...
Click to collapse
Thanks - I wasn't aware of that.
I have been using both Clockwork and Amon_RA - I think you saw the hack/trick I am using that allows me access either one I choose from a cold boot.
I tend to use Clockwork for Nandroid backup/restore (because it is far more complete), and Amon_RA for almost everything else. I want my installer to perform signing verification, dammit!
bftb0 said:
Thanks - I wasn't aware of that.
I have been using both Clockwork and Amon_RA - I think you saw the hack/trick I am using that allows me access either one I choose from a cold boot.
I tend to use Clockwork for Nandroid backup/restore (because it is far more complete), and Amon_RA for almost everything else. I want my installer to perform signing verification, dammit!
Click to expand...
Click to collapse
You're welcome!
Yes, actually even with ROM Manager installed I most often use QuickBoot or any other app/ROM's reboot to recovery option and then load ClockWork from there. Most of the time it seems actually less time consuming than bothering to load ROM Manager just to tell it the same thing. I don't keep any other zips in the root of the SD card besides FlashBack21 and 15, so the update.zip for ClockWork is always right there easily accessible without scrolling through a list.
And I won't lie, ClockWork Mod definitely has a different approach to the naming of it's menu options and organization, and even naming of those menu items, so it doesn't surprise me that you didn't know that the USB mount option did exist - in a weird place, if you ask me. Makes sense only in hindsight.
Something just rang a bell so I loaded ClockWork Mod re: signature verification. I would have brought this up a LONG time ago, but I honestly just didn't remember it until now, I swear.
ClockWork Mod DOES have signature verification, at least as a menu toggle.
In CWM's main menu, choose "install zip from sdcard". You'll see the third option in the list is "toggle signature verification". If I choose it now it then says at the very bottom of the recovery screen "Signature Check: Enabled". This setting doesn't stick between reboots (tested), although they could probably set it up so that it does by one of two methods:
1. Writing a settings file on the SD card which the recovery reads when loaded.
2. Actually modifying the update.zip as necessary to make this setting permanent until it's re-toggled.
I think where the confusion lies is that if you actually use ROM Manager the way that it's meant to when flashing a ROM, you'll never get the opportunity to see the menu option for signature verification as I believe that ROM Manager causes CWM to automatically reboot after the flash.
I rarely even enter ROM Manager as I mentioned above, so I guess that's how I got a little bit more familiar with the varying contents of the CWM menus. I never toggled sig verification on before except a very long time ago as a test to see what it did - but I just didn't ever think about it ever again after that.
I will probably toggle it on from now on, though.
I don't know what the "toggle script asserts" option below that is, though. Any idea so that I don't have to search?
Back to how I originally started this post. I was going to say that despite CWM not verifying the signature (by default - now that I know), I like the ability to organize my various flashable items in my favorite hierarchy of folders too much to revert back to Amon RA for typical flashing. Now that I know there's no reason to, I won't feel as lazy.
Also, I see now that in CWM v2.5.0.7 that they renamed the "partitions" menu to "mounts and storage". Still slightly confusing, but oh well.
Wasn't it speculated or more that Amon RA may not wipe Dalvik correctly when Cache To Cache is used? Did anyone come to any definitive conclusion regarding that?
roirraW "edor" ehT said:
Something just rang a bell so I loaded ClockWork Mod re: signature verification. I would have brought this up a LONG time ago, but I honestly just didn't remember it until now, I swear.
ClockWork Mod DOES have signature verification, at least as a menu toggle.
Click to expand...
Click to collapse
While I have seen this before myself, the one time that I tried to use it in Clockwork with a known-good .zip file it gave an error message. In other words, this passed Amon signature check, successfully installed on both recoveries, yet gave an error when I tried to set it.
Maybe I was reading the error message wrong, though.
Wasn't it speculated or more that Amon RA may not wipe Dalvik correctly when Cache To Cache is used? Did anyone come to any definitive conclusion regarding that?
Click to expand...
Click to collapse
I can't see how it wouldn't. Wiping Dalvik formats the /cache partition, and the /cache partition with cache2cache is holding both the system Dalvik cache (the one that you want to wipe when there has been a change in the Android system files) as well as the third party app cache (normally in /data.) It's definitely true, though, that Clockwork does a more thorough Nandroid backup and restore, as it backs up and restores /cache, the SD card's /.android_secure folder (where Froyo/GB store apps moved to SD) as well as ext partitions on the SD card (where 2.1 ROMs store apps2sd.)
At this point in time it's beginning to look like the OP did a "drive-by" posting, so I suppose it's Ok to continue with the OT discussion.
doogald said:
While I have seen this before myself, the one time that I tried to use it in Clockwork with a known-good .zip file it gave an error message. In other words, this passed Amon signature check, successfully installed on both recoveries, yet gave an error when I tried to set it.
Click to expand...
Click to collapse
Same experience here. From that I concluded that it doesn't work correctly.
I suppose it could be set up to reject the "test key" signature, as it really isn't a private key (cuz everybody has it), but that would make it useless for Eris dev ROMs.
doogald said:
While Wiping Dalvik formats the /cache partition
Click to expand...
Click to collapse
Eh?
That's counterintuitive. I thought Amon_RA only wipes /cache when you do a "wipe data/factory reset". Is clockwork different in this regard?
bftb0 said:
That's counterintuitive. I thought Amon_RA only wipes /cache when you do a "wipe data/factory reset". Is clockwork different in this regard?
Click to expand...
Click to collapse
I was actually talking about Amon's, and I am probably very wrong about that - I hadn't really checked. Still, all that cache2cache does is move /data/dalvik-cache to /cache/dalvik-cache and create a symlink so /data/dalvik-cache points to /cache/dalvik-cache, so any procedure that wipes /cache/dalvik-cache and even /data/dalvik-cache is going to wipe Dalvik just fine with cache2cache installed, right?
doogald said:
I was actually talking about Amon's, and I am probably very wrong about that - I hadn't really checked. Still, all that cache2cache does is move /data/dalvik-cache to /cache/dalvik-cache and create a symlink so /data/dalvik-cache points to /cache/dalvik-cache, so any procedure that wipes /cache/dalvik-cache and even /data/dalvik-cache is going to wipe Dalvik just fine with cache2cache installed, right?
Click to expand...
Click to collapse
Well, when Amon_RA is performing installs or Nandroids, it mounts the "data" and "system" partitions on the normal mount points, namely /data and /system, respectively.
So, yeah - if someone had cache2cache installed on their ROM, there would be a symlink
/data/dalvik-cache -> /cache/dalvik-cache
So if Amon_RA's strategy for "wiping dalvik cache" is to "mount /data and rm -rf /data/dalvik-cache", then yes - the folder at /cache/dalvik-cache would get wiped.
But if someone was NOT using cache2cache ( me! ), then the /cache/dalvik-cache folder, which normally contains entries for apps in /system/app (for Froyo and GB) would be preserved if you were "overflashing" a ROM, assuming that the dev did not place an explicit "format CACHE:" directive in his installer script.
When I am "overflashing" a ROM, I always look at the result with an adb shell to Amon_RA after everything is flashed, but before the first boot, and I manually remove /cache/dalvik-cache if it is there.
In that specific case (no use of cache2cache), there is no need to wipe the /data/dalvik-cache (because none of the apps in /data/app have changed), and a very good reason to wipe /cache/dalvik-cache (because many of the apps in /system/app could have changed).
Arguably, if someone is NOT using cache2cache, then a "wipe dalvik-cache" in Amon_RA wipes the wrong cache if the intent is to overflash a Froyo or Gingerbread ROM - because the /cache folder does not get wiped ... and that is precisely the location that you do want to wipe, because what is being replaced is the system apps.
I wonder how many rooters understand that subtlety.
And then, after that, I wonder if it is even necessary to worry about it - I thought that Android does a variety of signature checks on every boot, and if there is a mismatch between the .apk and the .dex, the .dex gets re-created automatically.... I think. (Ugh. I know how to check this experimentally, but it's a lot of work.)
doogald said:
While I have seen this before myself, the one time that I tried to use it in Clockwork with a known-good .zip file it gave an error message. In other words, this passed Amon signature check, successfully installed on both recoveries, yet gave an error when I tried to set it.
Maybe I was reading the error message wrong, though.
I can't see how it wouldn't. Wiping Dalvik formats the /cache partition, and the /cache partition with cache2cache is holding both the system Dalvik cache (the one that you want to wipe when there has been a change in the Android system files) as well as the third party app cache (normally in /data.) It's definitely true, though, that Clockwork does a more thorough Nandroid backup and restore, as it backs up and restores /cache, the SD card's /.android_secure folder (where Froyo/GB store apps moved to SD) as well as ext partitions on the SD card (where 2.1 ROMs store apps2sd.)
Click to expand...
Click to collapse
bftb0 said:
At this point in time it's beginning to look like the OP did a "drive-by" posting, so I suppose it's Ok to continue with the OT discussion.
Same experience here. From that I concluded that it doesn't work correctly.
I suppose it could be set up to reject the "test key" signature, as it really isn't a private key (cuz everybody has it), but that would make it useless for Eris dev ROMs.
Eh?
That's counterintuitive. I thought Amon_RA only wipes /cache when you do a "wipe data/factory reset". Is clockwork different in this regard?
Click to expand...
Click to collapse
It should also be noted that CWM wipes .android-secure (and /sd-ext, as well as Data and Cache) when you choose "wipe data/factory reset". Noticed this just now.
I wanted to test the signature verification since CWM had been updated recently for the Eris, at least with one ROM and it's associated files (GAPPS, zach.xtr's C2C). I flashed GSB v1.6 with verification turned on. It never reported any error flashing the zip. It did, however, claim that "gapps-gb-20110120-signed.zip" failed sig verification. I immediately flashed that zip via Amon RA and it flashed just fine.
zach.xtr's C2C passed CWM's sig verify, though.
I'm doing research to see if I can find any more information on this behavior.
bftb0 said:
Well, when Amon_RA is performing installs or Nandroids, it mounts the "data" and "system" partitions on the normal mount points, namely /data and /system, respectively.
So, yeah - if someone had cache2cache installed on their ROM, there would be a symlink
/data/dalvik-cache -> /cache/dalvik-cache
So if Amon_RA's strategy for "wiping dalvik cache" is to "mount /data and rm -rf /data/dalvik-cache", then yes - the folder at /cache/dalvik-cache would get wiped.
But if someone was NOT using cache2cache ( me! ), then the /cache/dalvik-cache folder, which normally contains entries for apps in /system/app (for Froyo and GB) would be preserved if you were "overflashing" a ROM, assuming that the dev did not place an explicit "format CACHE:" directive in his installer script.
When I am "overflashing" a ROM, I always look at the result with an adb shell to Amon_RA after everything is flashed, but before the first boot, and I manually remove /cache/dalvik-cache if it is there.
In that specific case (no use of cache2cache), there is no need to wipe the /data/dalvik-cache (because none of the apps in /data/app have changed), and a very good reason to wipe /cache/dalvik-cache (because many of the apps in /system/app could have changed).
Arguably, if someone is NOT using cache2cache, then a "wipe dalvik-cache" in Amon_RA wipes the wrong cache if the intent is to overflash a Froyo or Gingerbread ROM - because the /cache folder does not get wiped ... and that is precisely the location that you do want to wipe, because what is being replaced is the system apps.
I wonder how many rooters understand that subtlety.
And then, after that, I wonder if it is even necessary to worry about it - I thought that Android does a variety of signature checks on every boot, and if there is a mismatch between the .apk and the .dex, the .dex gets re-created automatically.... I think. (Ugh. I know how to check this experimentally, but it's a lot of work.)
Click to expand...
Click to collapse
I certainly didn't know this. Very interesting, thank you!
I Agree
roirraW "edor" ehT said:
It should also be noted that CWM wipes .android-secure (and /sd-ext, as well as Data and Cache) when you choose "wipe data/factory reset". Noticed this just now.
I wanted to test the signature verification since CWM had been updated recently for the Eris, at least with one ROM and it's associated files (GAPPS, zach.xtr's C2C). I flashed GSB v1.6 with verification turned on. It never reported any error flashing the zip. It did, however, claim that "gapps-gb-20110120-signed.zip" failed sig verification. I immediately flashed that zip via Amon RA and it flashed just fine.
zach.xtr's C2C passed CWM's sig verify, though.
I'm doing research to see if I can find any more information on this behavior.
I certainly didn't know this. Very interesting, thank you!
Click to expand...
Click to collapse
I agree yes, thank you!
A few weeks ago my SD card went bad on me. I have been using Gingershedbread as my ROM and see there are some updates, however, since I don't have an SD card, the "normal" method of loading the zip onto the SD card obviously won't work for me.
My question is: Is there a way to flash a ROM zip from a pc (windows) to my phone without an SD card? I know you can put the zip on the data partition, then use "recovery --update_package=DATA:rom.zip" (through adb), however, when trying to copy the rom I get a message saying that there is no space left.
As of now, the only thing I know of is to do a full wipe and factory reset, then push the ROM zip to my phone, but I don't necessarily want to do this every time.
I have also tried fastboot and using mkyaffs2image to create a system.img from the ROM's system folder in the zip file, but I am not doing something right.
I run "mkyaffs2image c:\rom\system\ c:\system.img"
then with my phone in fastboot, I "fastboot flash system c:\system.img"
and "fastboot flash boot c:\rom\boot.img".
I restart the phone in recovery mode, load gapps and xtrCache, but then it reboots, sits on black screen for a few seconds, then reboots into recovery.
I have tried erasing system and boot first, but that didn't seem to help.
I first tried just flashing system.img, but that didn't work.
Not sure what I am doing wrong. Is there a way to take a ROM zip and create a system.img and boot.img that can be flashed through fastboot without an SD card? OR, is it possible to flash a ROM zip without transferring the file to my phone first? Any help would be appreciated.
I don't think that there is an answer to your question which is both complete and also short.
So, here goes with the long answer.
First, a yaffs2 image file (e.g. system.img) is not compressed, so it is quite large - for things like the HTC factory/stock ROMs, it can be bigger than the cache partition. I don't know if the cache partition is actually used when you push things with fastboot, but experimentally, I have run into the problem that when attempting to do a
Code:
fastboot flash system my-yaffs2-system.img
fastboot gives you get an error about being out of room.
Second, and more importantly, the file modes (permissions) and user:group ownership of files in the /system mount point are extremely critical to proper operation of Android. If you have files sitting on a Windoze machine filesystem (either FAT32 or NTFS), all this information will be lost even before you create your "yaffs2" image file. (Not only that, but all symbolic links will be missing, too). This is why you observe that ROM files have instructions in their "update-script" (or "updater-script") command files for setting file & directory ownership, file permission modes, creating symlinks, et cetera.
Third - even if you use a linux OS to unpack yaffs2 images, and run as root when you are doing so, a lot of the "unyaffs" programs that are lying around do not even bother to extract things like user:group ownership or file modes - so you are basically screwed as soon as you unpack a yaffs2 image file on a PC, no matter whether it is Windows or Linux/Unix/OS-X.
Fourth, I am not sure that it is even a good idea in the first place to be "flashing" yaffs2 images. The "fastboot flash" command merely writes whatever you pass to it as a long linear blob of bytes, and there is no evidence to suggest that the yaffs formatting used in the archive is the same formatting used by the kernel. When "Nandroid" runs to restore a system.img or data.img file onto the phone, it does not write the image as a linear blob of bytes: it actually mounts the filesystem in question, cleans it up with a "rm -rf *" command, and then manually unpacks the yaffs2 image file into the mounted file system, one file at a time. (Fortunately in this case, it actually restores things like symlinks, file permissions, and file/directory user:group ownership information). This insures that the low-level yaffs2 formatting is *identical* to what the kernel expects, because it is the kernel that creates it.
There is a solution, but it is tedious enough that you really ought to ask the question, "Why don't I go out and buy a replacement SD card for 10 bucks instead of wasting a huge amount of time?"
Here's the solution:
You mount /system, clean it up manually, use adb to push the files recursively from wherever you have them stored on your PC, and then afterwards you run a custom (signed) installer .zip file which has been modified so that it only contains the "symlink" and permission-setting commands - you delete the "format" and "extract" commands from that command file, since you have manually put all the files into /system. Either that or you manually adjust the permissions and user:group ownership information by hand.
Obviously, since you don't have an /sdcard any longer, you will need to put this flashable, custom .zip file in /cache, and then create a one-line command file at /cache/recovery/command that points at the flashable .zip file in /cache. (This is the way the the OTAs work, and also how ROM Manager is able to customize the recovery when it boots).
Is this a lot of work? Yeah, you betcha.
It seems like running down to wally world to get a cheap SD card might be a little more fun.
Thanks for the info. I figured getting a new SD would be the best solution.
I knew about the symlink and file permission stuff and was trying to flash a system img then run a zip to ser that info., but couldn't get it to work. Sounds like using fastboot might be a bad idea.
For now I think I will just have to find a rom and stick with it for a while.
I am nearing an upgrade for a new phone and looking at the Thunderbolt, which comes with an SD so I don't want to buy one just yet.
Thanks for your help.
Sent from my ERIS GSBv2.1 using XDA App
kgunnIT said:
then run a zip to ser that info., but couldn't get it to work.
Click to expand...
Click to collapse
If you know how to sign ROMs, it's really not a hard hack to launch an installer of the type you mention.
And, now that I've just said that, I think I have another, simpler, idea.
But first:
[SIZE=+2]How To Launch a (smallish) .zip-based Flash That's Not On the SD Card.[/SIZE]
All of the recoveries - both the stock and custom recoveries - look for a "command" file when they first start up.
It literally is named "command", i.e.: /cache/recovery/command
... and it is a simple text file with as few as one line(s) in it.
Here is an example from the most recent OTA of the contents of /cache/recovery/command:
Code:
--update_package=CACHE:8e3b63f96149.OTA_Desire_C_Verizon_WWE_2.37.605.4_2.36.605.1_release.zip
basically, it's just a single line with the following format:
--update_package=CACHE:filename.zip
So, if you are trying to get an installer to run without an SD card, you would:
1) Boot to Amon_RA
2) Wipe the cache if necessary (wipe -> wipe data/factory reset also clears /cache)
3) Push your zip file to cache:
Code:
adb push mycustominstall.zip /cache/
4) Create a command file (say, named "command.txt") with the contents:
Code:
--update_package=CACHE:mycustominstall.zip
5) Push it to the phone:
Code:
adb push command.txt /cache/recovery/command
6) reboot directly back into recovery with
Code:
adb shell reboot recovery
When the recovery boots up again, it will immediately start unpacking your "mycustominstall.zip" file.
After I thought this all the way through, I realized, though: a lot of the ROM files are only about 100 MB, and cache is about 128 Mb, so
.... wait for it .....
... wait for it ....
it might be a worthwhile experiment to just push an untouched ROM file right to cache and then use that ROM file's name in your "command" file.
So long as /sbin/recovery does not unpack files to /cache (I can't remember if it does this or not!), you could use original ROM files -- just what you wanted originally. If it unpacks things to cache, though, it will only get part way through the install and fail.
It's worth a shot; if it fails, you'll have a mess that is no worse to clean up than what you've presently got. (If it fails, to be on the safe side it might be wise to go in using adb and clean things up in /cache a little bit so that the next recovery boot has some wiggle room in /cache - e.g. "adb shell rm -rf /cache/*" )
bftb0
bftb0 said:
If you know how to sign ROMs, it's really not a hard hack to launch an installer of the type you mention.
And, now that I've just said that, I think I have another, simpler, idea.
But first:
[SIZE=+2]How To Launch a (smallish) .zip-based Flash That's Not On the SD Card.[/SIZE]
All of the recoveries - both the stock and custom recoveries - look for a "command" file when they first start up.
It literally is named "command", i.e.: /cache/recovery/command
... and it is a simple text file with as few as one line(s) in it.
Here is an example from the most recent OTA of the contents of /cache/recovery/command:
Code:
--update_package=CACHE:8e3b63f96149.OTA_Desire_C_Verizon_WWE_2.37.605.4_2.36.605.1_release.zip
basically, it's just a single line with the following format:
--update_package=CACHE:filename.zip
So, if you are trying to get an installer to run without an SD card, you would:
1) Boot to Amon_RA
2) Wipe the cache if necessary (wipe -> wipe data/factory reset also clears /cache)
3) Push your zip file to cache:
Code:
adb push mycustominstall.zip /cache/
4) Create a command file (say, named "command.txt") with the contents:
Code:
--update_package=CACHE:mycustominstall.zip
5) Push it to the phone:
Code:
adb push command.txt /cache/recovery/command
6) reboot directly back into recovery with
Code:
adb shell reboot recovery
When the recovery boots up again, it will immediately start unpacking your "mycustominstall.zip" file.
After I thought this all the way through, I realized, though: a lot of the ROM files are only about 100 MB, and cache is about 128 Mb, so
.... wait for it .....
... wait for it ....
it might be a worthwhile experiment to just push an untouched ROM file right to cache and then use that ROM file's name in your "command" file.
So long as /sbin/recovery does not unpack files to /cache (I can't remember if it does this or not!), you could use original ROM files -- just what you wanted originally. If it unpacks things to cache, though, it will only get part way through the install and fail.
It's worth a shot; if it fails, you'll have a mess that is no worse to clean up than what you've presently got. (If it fails, to be on the safe side it might be wise to go in using adb and clean things up in /cache a little bit so that the next recovery boot has some wiggle room in /cache - e.g. "adb shell rm -rf /cache/*" )
bftb0
Click to expand...
Click to collapse
You always find the one thousand and ONETH way to skin a cat. Hehehehe...
Thankyou so much for this this alowed me to flash a rom on my phone which can't detect any sd cards and i stupidly wiped it before relising the sd card wasnt being detected!
sum_guy55 said:
Thankyou so much for this this alowed me to flash a rom on my phone which can't detect any sd cards and i stupidly wiped it before relising the sd card wasnt being detected!
Click to expand...
Click to collapse
very good, sum_guy55!
At least all that typing wasn' t in vain.
Out of curiosity, how big was the ROM file you used?
bftb0
Been meaning to post this:
Thanks for your posts roirraW "edor" ehT and bftb0 for posting this. I also was able to clear the cache and push the ROM and update.
However, I have xtrCMCache2cache on my phone, so the dalvik-cache was moved from /data/ to /cache/. After doing a wipe of dalvik-cache from Amon recovery, the folder in /cache/ was not emptied out. I went ahead and cleaned it manually, which freed up enough space to push the ROM.
Is this behavior expected using cache2cache and wiping dalvik-cache from recovery? I guess it would be since the dalvik-cache was moved.
Anyway, after clearing the dalvik folder, I was able to push GSBv2.4 to my phone, as well as gapps and xtrCMCache2cache, a total of almost 80 MB. Rebooted and all was well.
Thanks again for your help.
kgunnIT said:
Been meaning to post this:
Thanks for your posts roirraW "edor" ehT and bftb0 for posting this. I also was able to clear the cache and push the ROM and update.
However, I have xtrCMCache2cache on my phone, so the dalvik-cache was moved from /data/ to /cache/. After doing a wipe of dalvik-cache from Amon recovery, the folder in /cache/ was not emptied out. I went ahead and cleaned it manually, which freed up enough space to push the ROM.
Is this behavior expected using cache2cache and wiping dalvik-cache from recovery? I guess it would be since the dalvik-cache was moved.
Anyway, after clearing the dalvik folder, I was able to push GSBv2.4 to my phone, as well as gapps and xtrCMCache2cache, a total of almost 80 MB. Rebooted and all was well.
Thanks again for your help.
Click to expand...
Click to collapse
It was all bftb0. Interesting, I had once asked if cache was definitely wiped from Amon after it was moved. The consensus was that it should. I shall be anticipating some light shed on this.
Sent from my Gingerbread Eris via Tapatalk
Well, Amon_RA has no idea whether you are using cache2cache; I suppose we would need to look at the code to figure out how it behaves.
If it mounts /data and then does something like
rm -rf /data/dalvik-cache
there is a chance that the symbolic link is not followed, which would explain what kgunnIT observed.
Normally, if you are flashing a new ROM in a full-wipe fashion, the " wipe data/factory reset" menu option clears both /data and /cache, so in that case it is irrelevant that the "wipe dalvik-cache" is a no-op.
If you are overflashing, it's not obvious that you need to wipe the dalvik-cache... at least for the market apps normally stored in /data/app, although it seems like it would be a good idea to do so, as the system apps could be changing.
Note that even when cache2cache is not in use, the Amon_RA menu item "wipe dalvik-cache" never works as intended for froyo & gingerbread ROMs - the system apps have their dalvik-cache stored in /cache, and this never gets touched by Amon_RA with that menu operation.
BTW... for what it's worth, the ClockworkMod recoveryhas a menu entry for wiping only the cache.
bftb0
bftb0 said:
BTW... for what it's worth, the ClockworkMod recoveryhas a menu entry for wiping only the cache.
bftb0
Click to expand...
Click to collapse
Does ClockworkMod recovery work ok on the Droid Eris? I was going to load it on, but saw some people posting that it bricked their phones, so now I am skeptical. I will do more research and see if this is something I want to do. Thanks for your insight.
kgunnIT said:
Does ClockworkMod recovery work ok on the Droid Eris? I was going to load it on, but saw some people posting that it bricked their phones, so now I am skeptical. I will do more research and see if this is something I want to do. Thanks for your insight.
Click to expand...
Click to collapse
There is a version of Amon_RA (the trackball-optional version) that also allows you to format cache. You can find out more about it here: http://androidforums.com/eris-all-t...2-custom-recovery-trackball-not-required.html
That said, if you have ROM Manager, you can have Clockwork Recovery start as a stub within Amon_RA just from ROM Manager (the first option copies a file called update.zip to the root of your SD card, and the second, "Reboot into Recovery", starts Amon_RA with a script to flash update.zip, which starts Clockwork.) In fact, once update.zip is on the SD card, you can start Amon_RA as you always do, go to the Flash a zip from SD card menu, choose update .zip, and it will start Clockwork, if you want to do it that way. However, the drawback to this is that you can't go back to Amon_RA without shutting down the phone and then restarting in Recovery again, so I just find it easier to use the trackball-optional version of Amon_RA.
I think every person who has bricked their Eris while running Clockwork was running Clockwork Recovery as their main recovery image, and not in the way that I described in the last paragraph. (Though don't hold me to that ...)
kgunnIT said:
Does ClockworkMod recovery work ok on the Droid Eris? I was going to load it on, but saw some people posting that it bricked their phones, so now I am skeptical. I will do more research and see if this is something I want to do. Thanks for your insight.
Click to expand...
Click to collapse
I've been using it through ROM Manager since last August or so, I use it all the time.
I was on a hunt to make this work without losing any data and I've figured out a way that works quite nice, and all it involves is a TWRP backup, ADB, and a bit of commandline.
Thanks to TrevE for his ever evolving tweaks to Android and for making them readily available to the community at the cost of one thanks per post, and maybe a beer or two (how many people really buy beer with donations?!)
Required:
TWRP backup
ADB
The EXT4 tweaks for /data
The EXT4 tweaks for /system
(If your ROM doesn't already have them, I will be providing the zips for them courtesy of Synergy.)
Step 1:
Connect your phone to your PC and like all things of this nature, BACKUP! Use TWRP to create a nandroid of your entire phone. We will need this backup to restore data and system via commandline. TWRP is the only tested method that works, since it creates backups that are actually TAR files (God, I love TWRP for this). Stay in recovery after completing backup.
Step 2:
While still in recovery, enable USB storage mode and download the two EXT4 files below (or applicable if your ROM already has one of the partitions optimized) onto the root of your microSD card. To make things easier, you can temporarily move your data.win and system.win files to the root of your microSD card. They are located in the TWRP folder on your microSD card. Afterward, disable USB storage mode.
Next, there are TWO ways to accomplish this. Choose which way you want to go before continuing.
Method 1: Reflash your ROM(NOT RIGHT NOW, later on in the guide--depending on ROM, this may format your /system and/or data partitions, rendering the tweaks useless.)
Method 2: Use commandline to restore your ROM from TWRP backup.
Step 3:
From recovery, wipe dalvik and cache and format data and and depending on method, your system partitions as well. NOTE: formatting the partitions can be done from TWRP in the advanced menu.
Step 4:
Flash the applicable EXT4 file.
Step 5:
Mount /data, /system, (if applicable), and /sdcard with TWRP and launch an ADB shell by typing "adb shell" then press enter while in your ADB folder from command prompt/terminal.
Step 6:
Type "cd /sdcard" and press enter. To make sure you're in your sdcard, type "ls" then press enter to verify that it's listing your microSD card contents.
Step 7:
Type "cd /data" and press enter. To make sure you're in /data, type "ls" then press enter to verify that it's empty. It will probably contain a lost+found folder, if so then that's fine.
Step 8:
If you moved your data.win and system.win backups to the root of your microSD card to make this easier, simply type "tar xvpf /sdcard/data.win" then press enter and it will begin extracting the backup file onto the /data partition. Otherwise, you will have to type "tar xvpf /sdcard/TWRP/nameofHTCfolder/nameofdatefolder/data.win" then press enter. This will take a few minutes to complete.
NOTE: MAKE SURE YOU ARE IN THE /DATA PARTITION BEFORE TYPING THAT COMMAND, OTHERWISE THINGS WILL GO WRONG.
Step 9:
Either reflash your current ROM (checking to make sure it doesn't format /system before installing) OR type "cd /system" then press enter. To make sure you're in /system type "ls" then press enter to verify that it's empty. It may contain another folder, if so that's fine. It should however be empty of ROM related files.
Step 10:
If you moved your data.win and system.win backups to the root of your microSD card to make this easier, simply type "tar xvpf /sdcard/system.win" then press enter and it will begin extracting the backup file onto the /system partition. Otherwise, you will have to type "tar xvpf /sdcard/TWRP/nameofHTCfolder/nameofdatefolder/system.win" then press enter. This will take a few minutes to complete.
NOTE: MAKE SURE YOU ARE IN THE /SYSTEM PARTITION BEFORE TYPING THAT COMMAND, OTHERWISE THINGS WILL GO WRONG.
Step 11:
Once this is all complete, exit ADB shell by typing "exit" then pressing enter. Next, unmount /system, /data, and /sdcard from TWRP and head on over to the fix_permissions option in TWRP and let it run. It will take a few minutes to complete.
Step 12:
Go ahead and wipe dalvik and cache again just to make sure, then reboot.
It will take a while to boot back into android, but if all goes well, you should have your data intact with fully optimized EXT4 partitions thanks to TrevE/Synergy.
NOTE: This worked for me, and if you follow the guide precisely, it should work for you too.
NOTE2: I did not try this method with /system, ONLY data, and it worked fine. I assume the same for /system as well.
Awesome! I as many others are appreciative of Team Xposed and how you explain mods to everyone. Most of the time we get a .zip with no explanation on how the .zip is doing what it does. We just know flash this and this happens, lol. With these breakdowns we all get a better understanding on how things work in our devices
Perhaps a sticky with all Team Xposed mods/tweaks, that would be
I believe this is what i used the last time i flashed synergy. If so, then it works great.
Wow the step by step was GREAT!! Man I did this in like 5 minutes....Granted it took me about 30 minutes to download all the tools I needed. Thanks for this one!!
Edit: So how do you know it truly worked?? How do I check if I am ext4 or not?
wow. I had EXT4 on my samsung phones and I LOVED it compared to this! I will definitely try this and make a video on my success or failure! lol
so what if i didnt care to lose data could i flash this with another rom.
Ok. So just trying to gain a better understanding here. So say if the rom were running already includes the /system tweaks but not the /data tweaks and the rom doesn't erase on flash can I just flash both of the files and flash the rom?? Also if I wanted to apply the tweaks to and existing nand can I just flash both the files and do a nand restore??? Or is restoring the data from the command line needed in order for the tweaks to work effectively???
Locked & Loaded
" Shooter on Deck "
Great write up, thanks for that!
Not to be a party pooper, but isn't there a tweaked version of the EXT4 optimized zip that backs up data to sd card, formats /data with ext4, then auto restores /data for you? I found it somewhere in the Synergy thread.
Correct me if im wrong if this does something more/different.
here is a link to it:
Synergy_Format_Data_EXT4_Optimized_apps_autorestored.zip
http://forum.xda-developers.com/attachment.php?attachmentid=708982&d=1315062399
I used it to go from Warm2.3 to Steel2.3 without any issues what so ever, except having to restore XDA app, wifi/bt networks and some widgets. It kept all my screens and settings just the way i like it. YMMV! i take no credit, and assume no responsibility if it rips your phone a new one.
Our phones are already ext4, the optimization just turns on some more features for ext4.
And the tool linked before me doesn't backup everything in /data... It should probably work, but if it misses anything this method will catch it
I just took the opportunity to wipe clean and reset some things.
Sent from my PG86100 using XDA App
youngpro83 said:
Wow the step by step was GREAT!! Man I did this in like 5 minutes....Granted it took me about 30 minutes to download all the tools I needed. Thanks for this one!!
Edit: So how do you know it truly worked?? How do I check if I am ext4 or not?
Click to expand...
Click to collapse
Good question. I suppose you could run a few Quadrant benches to ease your mind. You should get much better scores than you would normally. I suppose the only real way to know for sure is if someone created an EXT4 tweak checker of some sort lol. But the Quadrant benchmark should be enough, that is if you remember what kind of scores you were getting before hand.
digitalcrash said:
so what if i didnt care to lose data could i flash this with another rom.
Click to expand...
Click to collapse
Glad you asked! If you don't care about losing data, just go ahead and format your system and data partitions with TWRP or whatever recovery you use, then apply the tweaks zips and go ahead and flash the ROM of your choice. You should double check the updater-script of your ROM to make sure it doesn't reformat the /system partition or it will render the /system tweak useless.
laie1472 said:
Ok. So just trying to gain a better understanding here. So say if the rom were running already includes the /system tweaks but not the /data tweaks and the rom doesn't erase on flash can I just flash both of the files and flash the rom?? Also if I wanted to apply the tweaks to and existing nand can I just flash both the files and do a nand restore??? Or is restoring the data from the command line needed in order for the tweaks to work effectively???
Locked & Loaded
" Shooter on Deck "
Click to expand...
Click to collapse
Well, if the ROM you're running already contains the /system tweaks then you're half-way there. You still want a backup though, because each of these zips will format its respective partitions. You only want the zip that applies. In your case, you'd only need the data tweaks, but you'd still have to follow the guide that pertains to restoring your data partition after tweaking.
MFD00M said:
Great write up, thanks for that!
Not to be a party pooper, but isn't there a tweaked version of the EXT4 optimized zip that backs up data to sd card, formats /data with ext4, then auto restores /data for you? I found it somewhere in the Synergy thread.
Correct me if im wrong if this does something more/different.
here is a link to it:
Synergy_Format_Data_EXT4_Optimized_apps_autorestored.zip
http://forum.xda-developers.com/attachment.php?attachmentid=708982&d=1315062399
Click to expand...
Click to collapse
Glad you linked that. I actually looked over this yesterday, and while it does do something similar to this guide, It actually only restores part of your data partition, which is why it's said that you will need to repair your bluetooth devices and reenter your WiFi network settings. IIRC, it doesn't restore the entire data partition, just most of the important folders. If it were to do the entire partition, well, this guide would be much shorter.
freeza said:
Glad you linked that. I actually looked over this yesterday, and while it does do something similar to this guide, It actually only restores part of your data partition, which is why it's said that you will need to repair your bluetooth devices and reenter your WiFi network settings. IIRC, it doesn't restore the entire data partition, just most of the important folders. If it were to do the entire partition, well, this guide would be much shorter.
Click to expand...
Click to collapse
Thanks for clearing that up, i will try your method as well. I need more ADB exposure to help me learn.
so my next question is if the rom does format system on boot then i would install with adb as your guide says?
digitalcrash said:
so my next question is if the rom does format system on boot then i would install with adb as your guide says?
Click to expand...
Click to collapse
Yup...pretty much.
Thank you for this. I was able to apply this without any issues.
freeza said:
Yup...pretty much.
Click to expand...
Click to collapse
What would be the process if I didn't care about losing data? Would I just flash, and resign into my Google account and go through that process again?
LiquidSolstice said:
What would be the process if I didn't care about losing data? Would I just flash, and resign into my Google account and go through that process again?
Click to expand...
Click to collapse
If you don't care about losing data, you'd format/wipe the data and system partition from recovery, apply both ext4 zips... wipe dalvik+cache, reflash your ROM, and reboot
Keep in mind that this is pretty much the same process as factory reset, so you might as well just perform one of those lol
freeza said:
If you don't care about losing data, you'd format/wipe the data and system partition from recovery, apply both ext4 zips... wipe dalvik+cache, reflash your ROM, and reboot
Keep in mind that this is pretty much the same process as factory reset, so you might as well just perform one of those lol
Click to expand...
Click to collapse
So just to be clear, all that I need to do is before I flash a ROM, Superwipe/XRON wipe like I always do, flash the ROM, flash the EX4 zips, and then clear dalvik/cache and boot?
LiquidSolstice said:
So just to be clear, all that I need to do is before I flash a ROM, Superwipe/XRON wipe like I always do, flash the ROM, flash the EX4 zips, and then clear dalvik/cache and boot?
Click to expand...
Click to collapse
You wanna flash the zips before flashing ROM, as they format the partitions with the tweaks. You also want to double check the updater-script of your ROM to make sure it doesn't format the /system partition before installing, as it would remove the tweaks.
Soo..
Superwipe/XRON
EXT4 tweaks
ROM
No need to wipe anything as Superwipe/XRON already does this.
freeza said:
You wanna flash the zips before flashing ROM, as they format the partitions with the tweaks. You also want to double check the updater-script of your ROM to make sure it doesn't format the /system partition before installing, as it would remove the tweaks.
Soo..
Superwipe/XRON
EXT4 tweaks
ROM
No need to wipe anything as Superwipe/XRON already does this.
Click to expand...
Click to collapse
EXT4 before ROM?
Bear with me, I'm still a bit confused :X. Wouldn't flashing a ROM after the EXT4 data/system zips negate the zips' function?
LiquidSolstice said:
EXT4 before ROM?
Bear with me, I'm still a bit confused :X. Wouldn't flashing a ROM after the EXT4 data/system zips negate the zips' function?
Click to expand...
Click to collapse
lol no problem.......Well, what the tweaks does is format the system and data partitions a certain way as to improve io functions and other stuff. It's like formatting a drive in Windows with cluster switches etc. It's still empty once you flash the tweaks. The ROM simply puts all the information on the newly formatted filesystem. If you were to apply the tweaks after flashing the ROM, it would format the partitions and erase all data, which is why you do it first. The updater-script in ROMs also have the ability to format partitions, which is why in Synergy ROMs, simply flashing their ROM also applies the tweak and which is why you should check your updater-script beforehand to make sure it doesn't have a format command in it, as it would negate the tweaks.
Hello you DualBooters and Triplebooters out there!
SDCacheMount for SD-Roms
Well, this idea came to me because many users of my triple-boot SD were getting tired of the rebuilding of system-cache when every time they had to switch between roms. What I have here is a small script that will install to /system/etc/init.d The script will run at boot time and create a 100mb .img file to be used for /cache. This way each rom will have its own dedicated /cache partition so to say. This will also benefit anybody that dualboots (eg. EMMC / SD-Rom). I've prepped two different versions. One for my triplebooters out there and the other for anyone running a rom off an SD card.
Things to note:
-This will dd a 100mb .img file to your /sdcard partition of your sd-rom on first boot. What this means is that before the system progresses any further the img file needs to be created so that the /system can use it as the /cache partition.
-It will sit at a black screen for up to 1 minute possibly. So please be patient!!!
-The dd'ing of the .img only happens on first boot. So once the cache .img is created. Boot time will be normal on successive boots.
-Make sure you have enough space on the /sdcard partition of your sd-rom.
-So for Dualbooters you will need at least 100mb free
-For Triplebooters you will need at least 200mb free
-Now you can switch between EMMC roms and SD roms without having to wait for /cache to rebuild every single time.
DOWNLOAD:
DUALBOOTERS ( EMMC / SD )
**You should be able to flash this from a standard CWM Recovery or rename the .zip file to begin with "update-" for Verygreens method.**
SDCacheMount_DualBooters.zip
Click to expand...
Click to collapse
TRIPLEBOOTERS ( EMMC / DUALBOOT-SD )
**You should only use the CWM Recovery that is included with my Dualboot-SD**
SDCacheMount_TripleBooters.zip
Click to expand...
Click to collapse
Big thanks to:
DizzyDen for helping me out with the script
Shumash for troubleshooting it for me
Inportb for some guidance
HacDan for his sense of humor
Hope this helps a few of you Nookers out there!
Thanks,
Racks
Reserved?!
Great job! gonna have a try on this
So the main advantage of this script is smaller booting time?
And this is the case when you switch Roms only between emmc and sd or also 2 different roms from same sd?
Unleashed from my Nook Color at 1.2G
RASTAVIPER said:
So the main advantage of this script is smaller booting time?
And this is the case when you switch Roms only between emmc and sd or also 2 different roms from same sd?
Unleashed from my Nook Color at 1.2G
Click to expand...
Click to collapse
The advantage of the script is that each AOSP will have its own dedicated cache and not all be utilizing the same space for all the cache.
RASTAVIPER said:
So the main advantage of this script is smaller booting time?
And this is the case when you switch Roms only between emmc and sd or also 2 different roms from same sd?
Unleashed from my Nook Color at 1.2G
Click to expand...
Click to collapse
The most obvious effect is that booting between the various ROM's is seamless (except for the minimal wait at the blank screen) and fast. It makes switching between the AOSP's very easy. The less obvious, behind the scenes effect is as Dizzy describes.
It should be noted that if you flash an updated or newer ROM, you will also need to reflash the SDcacheMount.zip.
shumash said:
The most obvious effect is that booting between the various ROM's is seamless (except for the minimal wait at the blank screen) and fast. It makes switching between the AOSP's very easy. The less obvious, behind the scenes effect is as Dizzy describes.
It should be noted that if you flash an updated or newer ROM, you will also need to reflash the SDcacheMount.zip.
Click to expand...
Click to collapse
Yes correct, thank you. I'll make note of that in the OP. Also note that once the .img cache is created, although you have to reflash the SDCacheMount after flashing a new rom. It won't have to create a new .img. The script will detect if one exist already and if so, proceed to boot. But if you don't flash the SDCacheMount right after flashing the new ROM. /cache will default back to /emmc
-Racks
I was Just reading about a Triple Swap (Ram) trick on XDA, It Uses Cache and Data and System partition as Swap Space.
Idea
Android devices have got RAM memory and internal eMMC memory. The eMMC is separated into several partitions (e.g. /system, /boot, /data, /cache). In former times of Android, the /cache partition was used for caching. Nowadays, in ICS times, the applications are using the /data partition to save information, libraries and cache data. So /cache is no longer used by the operating system or applications. Therefore, this partitions is empty except 4ext-logfiles, last recovery-log and an obligatory and empty lost+found directory. So we have got another 114 MB of space that can now be used as fast swap space for the kernel.
Also, the /system partition normally is not fully used - depending on the rom, a more or less amount of this area is free and unused.
As these areas all are internal memory, these swaps are faster, than a swap area on the sdcard!
There are also a lot of read/write requests to the /data partition as well and this is in Android “by design”. Furthermore there are devices, that have a preconfigured eMMC-swap space "by design", as for exaple the HTC One V.
Click to expand...
Click to collapse
Click to expand...
Click to collapse
So the Help I need is: To get our device supported for this is are the following things:
To do this, we will need your help. At fist you have to install the script manually to confirm that it's working. In the second step we will need a few details of your phones to modify the Aroma setup. Let's start with the first step:
Installation instructions:
Download the Aroma
Extract the file 98swap_cache_v300 from the folder \swap\cache\50\etc\init.d in the Aroma
What to do:
Enter ES-Explorer and:
Go to ES-Explorer settings/Root settings/check (root explorer ,up to root and mount file as writable).
Copy the script 98swap_cache_v300 to /system/etc/init.d
Don't reboot!
Open a terminal session and get superuser rights with the command: su
Command: cd /system/etc/init.d (now you are in the init.d folder, where the script is)
Command: chmod 775 98swap_cache_v300 (now the script has execution rights)
Reboot
Now:
Open a terminal session and get superuser rights with the command: su
Command: cat /proc/swaps (shall show the new swap file /cache/swap/swap.img)
With ES-Explorer navigate to /data/swap and look into the log file swap_cache.log
Please, sent Me the logfile swap_cache.log via PM!.
If it's working, we have to do the second step:
The second step is, to include your Device in the Aroma; we need the internal device name and the mount point of the file systems. Do the following:
Open a terminal session
Get a superuser shell with the command: su
Now the command:getprop ro.product.device
(that's the internal device name - I will need that name exactly)
Now the command: mount
(we need the mount points from /cache and /data and /system; if you do not find them, just use the command "mount > file" - this will write all output to "file" - then send me "file")
Please, sent above info to Me via PM!
Click to expand...
Click to collapse
Click to expand...
Click to collapse
The Two Files I will send to the developer, Then We can pray that He gets to Work on it..
HJain13 said:
I was Just reading about a Triple Swap (Ram) trick on XDA, It Uses Cache and Data and System partition as Swap Space.
Idea
So the Help I need is: To get our device supported for this is are the following things:
The Two Files I will send to the developer, Then We can pray that He gets to Work on it..
Click to expand...
Click to collapse
U can just skip ur second step by not checking the device
Hmm..... BUT
T3snake said:
U can just skip ur second step by not checking the device
Click to expand...
Click to collapse
Hmm.. but It would be nice if We could use Aroma.. easier to choose amount of swaps and where etc...
HJain13 said:
Hmm.. but It would be nice if We could use Aroma.. easier to choose amount of swaps and where etc...
Click to expand...
Click to collapse
It will be aroma allright...
I meant ur second step (getprop 1) isn't mandatory
Anyway info u need is in build.prop
Sent from my SM-T211 using Tapatalk