Related
malezRecovery_0.2.img
Here you can find my custom recovery wich works with both liquid 1.6 and liquid E 2.1 rom. It was originally base and Lickonn work.
The recovery images will not work on factory AAP, CSL or FET devices untill you do a full flash
An updgrade via acer download tools is needed. You will have to flash to an EMEA rom (thanks to Nova2.1 for his help)
Important notes to rom providers
In order to make your rom compatible with apps2sd, you need to add the lines in bold in the init.rc of your boot.img otherwise, system won't boot if apps are stored on the sd card ext partition.
chown system system /cache/recovery
chmod 0770 /cache/recovery
# APP2SD (Malez)
mount ext2 /dev/block/mmcblk0p2 /system/sd/ rw
mkdir /data/misc 01771 system misc
mkdir /data/misc/hcid 0770 bluetooth bluetooth
Click to expand...
Click to collapse
Community rom already provides 2 scripts
/system/etc/init.d/30apps2sd
/system/xbin/apps2sd
in LCR 1.1 they failed but might do the job soon.
Changelog V0.2.1 :
- nandroid updated to 2.2.2.2 (fixed backup when no ext2 partition and using standard recovery menu)
Changelog V0.2 :
Many changes in this release
- compliant to any 1.6 or 2.X rom
- added bart
- added free sd card partitionning tool
- updates bysybox to 1.15.3
- modified nandroid to 2.2.2.1 (personnal version)
-you can choose whick backup restore, now only the next one (in recovery utilities)
- add ext2 partiton backup by default (usefull when using app2sd)
- 1.6 and 2.1 compatible
- fs check and mount corrected
- ext2 / noext2 options added
- full rewrite of apps2sd (move or copy apps stored in your phone to your sd card)
- created sd2apps (move or copy apps stored in you sd card back to your phone (only in recovery utilities)
- fixed wype
- added bart script
- created back office recovery utilies which allow to do a lot more operation (to launch it, adb shell (enter) malez )
Recovery Utilities by Malez v0.1
[1] Convert ext3 > ext4 no data loss
[2] Fix Permissions 2.03 experimental
[3] Backup APPS on ext to FAT32
[4] Restore APPS from FAT32 to ext
[5] Partition SD 3 partitions (can set sizes)
[6] Fix auto-rotate problems
=====================
[7a] Move phone apps to sd card
[7b] Move phone apps to sd card (keep files on phone)
[7c] Move sd card apps back to phone
[7d] Move sd card apps back to phone (keep files on sdcard)
=====================
[8a] Run BART 1.0.1 Backup
[8b] Run BART 1.0.1 Restore
=====================
[9] Reset/delete Battery Stats
=====================
[10a] Backup Nandroid
[10b] Backup Nandroid (without ext2)
[10c] Restore latest Nandroid
[10d] Restore latest Nandroid (without ext2)
[10e] Restore specific Nandroid
[10f] Restore specific Nandroid (without ext2)
=====================
[q] Quit to Console Prompt
Boot me out of here! (reboot)
Enter Number>
- and more...
Click to expand...
Click to collapse
Initial release v0.1 :
Nandroid backup/restore only works with the acerLiquid E rom (I have tested of course) !!
Menu item explanation
- Reboot system now -> reboot in phone mode
- Apply sdcard:update.zip -> apply the update.zip file stored at root of the sdcard
- Apply any zip from sd -> apply any zip file (update format) from sd. A menu will le you choose which one
- Nandroid : backup -> perform a backup of all your system and data partition and also ext2 from sd (if exists)
- Nandroid : restore latest backup -> restore the latest made nandroid backup
- UMS on -> enable Usb Mass Storage so you can acces sd card as a usb key on you computer
- UMS off -> disable Usb Mass Storage
- Root current system -> root you system phone
- Remove root in current system -> remove root in you system phone. If an error occurs, choose install root before uninstalling it (Some roms auto root system on each startup so it might not be enough)
- Split sd for apps 2 sd -> create 2 partitions on you sd card : 500Mo ext + free left space fat). All data on sd are lost
- Move apps2sd -> move application from phone to sd card. You need compatible rom for this to work. If system don't boot after, it's not compatbile (see developper note in front of this post for info). To move apps back from sd card to phone, during boot failure, do "adb reboot recovery", then "adb shell" and "utility". Choose "Move sd card apps back to phone". Reboot
- Fix package uid mistmatches -> fixes permissions on Android data directories after upgrade
- Wipe data (factory reset) -> erase all you personnal apps and info. Sometimes needed after a system upgrade. May fix lots of instability problems. First boot takes a long time.
- Wipe dalvik-cache -> erase the dalvik-cache. First boot takes a long time.
- Copy recovery.log to sdcard. -> Copy the recovery log file to the root of your sd card so can see more detailes information.
If any of this comand failed, you can try to launch them via the utility menu. More detailed informations will be displayed.
To enter utility menu : adb shell (enter) utility (enter)
Download links
V0.2.1
http://rapidshare.com/files/358814947/malezRecovery_0.2.1.img
MD5 sum
909c6d08739cec3064ac0b9093d13b6a malezRecovery_0.2.1.img
V0.2
http://rapidshare.com/files/357929849/malezRecovery_0.2.img
MD5 sum
3003cb31c3859b898de1736599956a34 malezRecovery_0.2.img
V0.1
http://www.megaupload.com/?d=WNTQR36F
http://rapidshare.com/files/355642457/male...ery_2.1-0.1.img
MD5 sum
fb44320003c6b335df63b740208a287e malezRecovery_2.1-0.1.img
How to install
Boot phone in normal mode
adb reboot bootloader
fastboot-linux -i 0x0502 flash recovery malezRecovery_0.2.img
sending 'recovery' (4876 KB)... OKAY
writing 'recovery'... OKAY
fastboot-linux -i 0x0502 reboot
To enter recovery : adb reboot recovery
To enter recovery utilities :
- Connect usb
- boot in recovery
- from computer adb shell (enter) malez (enter)
If need any help, don't forget to copy recovery log to sd and send it.
Click to expand...
Click to collapse
Original thread by malez: MoDaCo
Just saw that 0.2.1 is released
http://android.modaco.com/content/a...com/303405/malezrecovery-v0-2-1-nandroid-fix/
I just arrived home, will update this later
Latest version added.
Thanks to malez!
is this working ok in donut too??
Yep, it does on both 1.6 & 2.1
I like this recovery, but why it don' t have wipe battery stats option??Is very very usefull!!!
Version 0.4.1 is out with many changes, see here for info (its includes wipe battery stats)
I can't post the link,
its in google code.google.com/p/acer-liquid-malez-recovery/
Hi, how i can remove this recovery?
Excuse me BrOw..
i've Acer Liquid E (512) Using The Official Froyo.
but when i try to install Malez Recovery, when my Phone Reboot and begin for installing MalezRecovery in recovery Mode, its always writen "fail" <in Red>
even in
- Malez 6.1.
- Malez 6.0
- Malez 5.3
my question is,
is this version work in My Acer Liquid E???
I didn't want to trouble anyone, but I really couldn't find any thread on the same topic as this one.
Also, I don't have ten posts, so I can't post direct links. I'll have to post them in plain text.
I'm a generally disk-space conservative person.
When Android version 4.2.2 was released, I tried updating but without any luck (update failed).
So a couple of days later, I factory reset my Nexus 7, then I truly wiped it and proceeded to flash 4.2.2 and root the device.
No custom ROM:s.
Yesterday, I randomly checked my storage information, just to find that 4 gigabytes out of max 6 gigabytes storage was used.
See puu.sh/2fe9V for an image.
I'm a newcomer to both xda and Android and I followed several tutorials whilst doing this. One of them led to me bricking my device.
I wish I could, but I was only able to track up one of the ones I followed;
blog.laptopmag.com/how-to-hard-reset-a-bricked-nexus-7-with-your-pc (this is the one that was successful).
I'm guessing that I may possibly have accidentally created some other partion or something similar.
I would really appreciate some help in this (to me) confusing topic.
Re: [Q] Nexus 7 32GB down to 6GB internal memory
Sounds like you flashed an 8 gig image. Where did you get the image?
Sent from my Nexus 7 using xda app-developers app
rmm200 said:
Sounds like you flashed an 8 gig image. Where did you get the image?
Sent from my Nexus 7 using xda app-developers app
Click to expand...
Click to collapse
Thank you. That definitely sounds like a possibility.
I got mine from developers.google.com/android/nexus/images#nakasijdq39
(Sorry again for plain text links)
Zsded said:
...
So a couple of days later, I factory reset my Nexus 7, then I truly wiped it and proceeded to flash 4.2.2 and root the device.
No custom ROM:s.
...
Yesterday, I randomly checked my storage information, just to find that 4 gigabytes out of max 6 gigabytes storage was used.
See puu.sh/2fe9V for an image.
I'm guessing that I may possibly have accidentally created some other partion or something similar.
Click to expand...
Click to collapse
rmm200 said:
Sounds like you flashed an 8 gig image. Where did you get the image?
Click to expand...
Click to collapse
Could be, but then the Google factory images do not discriminate between 8/16/32, and in this case the OP used a factory image.
@Zsded
I had this happen to me the other night (in the middle of doing something else). The long & boring story follows, but let's begin with a solution: The partitioning data did not get changed, but mysteriously the /data filesystem got created with with only about 6-7 GB of capacity. Re-creating the /data filesystem using the "Format data" operation in TWRP will create an ext4 filesystem of 29 GB or so.
You need to backup everything worth saving and re-create the /data filesystem. This can be accomplished (for instance) using the "Format data" operation in TWRP. But - again - this destroys everything in /data including everything in /sdcard. (Note it does not touch /system or /cache though - so your bare ROM is still there)
What you might want to do is the following:
1) back up everything in /sdcard that you want to save
2) make a full Nandroid backup of your current ROM
3) get copies of the TWRP Nandroid backup off the device (on to the PC)
4) perform the "format data" operation in TWRP (iirc it is in the Wipe sub-menu)
5) copy your Nandroid backup back to the tablet***
6) restore the Nandroid backup (or just the data partition if you prefer)
7) Boot into the ROM and copy the saved contents of /sdcard back onto your device from your PC
*** This is a mouthful. On a fresh /data filesystem, TWRP (v2.4.1.0, anyway) wants to find its backup folders at
/data/media/TWRP/BACKUPS/<device-id>/*
But if you use MTP with the OS to copy the nandroid backup files, you will only have access to /data/media/0/* (the "sdcard" mount point) using MTP So, you might need to copy the files and then using a root shell or the custom recovery, get a copy of your TWRP folder into /data/media/ e.g. with TWRP recovery booted:
Code:
adb shell cp -R /data/media/0/TWRP/ /data/media/
OK, now for the long and boring story.
I had something identical happen to me the other night - I have a 32G N7, and it ended up showing only 6.5 GB total in /data. Because of the sequence of events involved, I don't know the exact cause, but using TWRP to re-create the /data filesystem as explained above solved the problem.
First, some background so you will know why I don't know the cause (get a beverage, this is going to be a long post):
The other night, I decided to capture Nandroid backups of every N7 factory ROM from JZO54K through JDQ39 (4.1.2 - 4.2 - 4.2.1 - 4.2.2). My plan was to do a factory install of JZ054K (4.1.2) and then apply each of the OTAs in sequence. So, I backed everything up (including using a certain busybox version of "tar" to backup about 2.5 Gigs of stuff from the /sdcard mount point), and completely wiped the device and did a fastboot install of 4.1.2 (JZO54K) nakasi (WiFi N7) factory ROM.
The ony thing that I did not do in the initial step was flash the bootloader - I left the 4.18 bootloader in place (initially). I did not follow the factory install script; instead I used the following sequence:
Code:
fastboot erase boot
fastboot erase recovery
fastboot erase system
fastboot erase userdata
fastboot erase cache
fastboot flash boot boot.img
fastboot flash recovery recovery.img
fastboot format system
fastboot format userdata
fastboot format cache
fastboot flash system system.img
fastboot flash userdata userdata.img
The above installed the JZO54K factory ROM - but with the newer 4.18 bootloader still in place.
For each of the OTA package installs & nandroid backups, I would "soft-boot" TWRP (thus leaving the factory recovery still flashed on the tablet), e.g.:
Code:
C:\foo> fastboot boot openrecovery-twrp-2.4.1.0-grouper.img
C:\foo> adb push 094f6629314a.signed-nakasi-JOP40C-from-JZO54K.094f6629.zip /cache/update.zip
C:\foo> adb shell sha1sum /cache/update.zip
C:\foo> adb shell
# cd /cache/recovery
# echo '--update_package=/cache/update.zip' > command
# exit
C:\foo> adb reboot recovery
... (OTA runs, device reboots into OS, perform shutdown, boot to bootloader) ...
C:\foo> fastboot boot openrecovery-twrp-2.4.1.0-grouper.img
... take a Nandroid backup (including recovery partition!)...
Now, as it turned out, before any of this had taken place I had noticed filesystem corruption in my /system partition. Because I was making Nandroid backups for reference/archival purposes, after each OTA install, just prior to making the nandroid backup (with TWRP soft-booted as shown above), I did a filesystem check on system and data:
Code:
adb shell e2fsck -f -n /dev/block/mmcblk0p3
adb shell e2fsck -f -n /dev/block/mmcblk0p9
(for Wifi/nakasi/grouper devices, mmcblk0p3 is /system and mmcblk0p9 is /data).
The reason I mention this is that I was focused on making sure that there were no filesystem errors (there were none). Had I been paying attention, I might have noticed that something was wrong with the allocation size. But, read on...
When I finally got finished (3 OTAs and 3 Nandroid backups) I decided to restore the contents of my 2.5 Gb tarball. Nothing should been in /data except for a couple (TWRP) Nandroid backups. So, I start restoring the tarball... and after a good long wait ... tar exits due to lack of space. WTF?
Well, /data and /sdcard were mounted (in TWRP), so I did a
Code:
adb shell df -k /data
and it showed a little over 4.5 GB used ... in a 6.5 GB partition - WTF?
Now, because I wasn't watching carefully, I can't be sure what caused the small filesystem in a big partition, but here's my theory:
Because the OTAs are designed to leave /data and /data/media/* alone (more or less), that means that the /data filesystem was only created once: it would not have been destroyed & re-created by the successive application of the 3 OTA bundles that took me from JZ054K -> JOP40C -> JOP40D -> JDQ39.
To me, that says that one of the two following initial operations was the culprit:
Code:
fastboot erase userdata
fastboot format userdata
OR
Code:
fastboot flash userdata userdata.img
What is rather shocking about this is because of the way that I did things, I had the newest bootloader on the device when I did this - v4.18. I wouldn't have been surprised if an older bootloader had a bug that got fixed... but it surprises me that the very newest bootloader seems to be implicated.
But anyway - to recap - your partition data has not been altered. AFAIK, nobody (but Asus/Google) knows how to do that as it probably requires talking to the device in APX mode. Somehow, whatever recreated your filesystem in /dev/block/platform/sdhci-tegra.3/by-name/UDA ( userdata ) mysteriously created a filesystem substantially smaller than the physical partition size.
My suspicion is that it is a bug in the bootloader.
good luck
Actually all you had to do is do a factory reset in the recovery, and reboot. BAM - all your actual storage is back
Fatal1ty_18_RUS said:
Actually all you had to do is do a factory reset in the recovery, and reboot. BAM - all your actual storage is back
Click to expand...
Click to collapse
Factory Reset in the recovery does not recreate the ext4 filesystem, it only does deep removal (rm -rf) excluding /data/media. That won't solve the problem of having a tiny filesystem in a huge partition; same filesystem - same max capacity.
bftb0 said:
Factory Reset in the recovery does not recreate the ext4 filesystem, it only does deep removal (rm -rf) excluding /data/media. That won't solve the problem of having a tiny filesystem in a huge partition; same filesystem - same max capacity.
Click to expand...
Click to collapse
Strange. After I flashed the stock 4.2.1 after playing with some custom ROMs - I, too, had only 6GB available, but then I did either factory reset/wipe data or something else - and BOOM everything was fixed
bftb0 said:
Could be, but then the Google factory images...
Click to expand...
Click to collapse
Snipped to save people's screen space.
Thanks a lot! This solved my problem and I'm now back to 27 gigabytes (which should be somewhere around the promised 32 gebibytes).
I truly appreciate it. I would do more than just to thank your post, but I'm kinda out of ideas (and money).
And of course I'd like to thank everyone else for the help.
This thread can be regarded as closed.
@Fatal1ty_18_RUS
There have been a couple of other reports about "6 Gigs in a 32 GB device". I just dismissed them as folks not being aware of how much space they were using (e.g. Nandroid backups) - until it happened to me.
Enough strangeness seems to be present to make me nervous for folks that don't have a lot of *nix experience to sort things out when they get mucked up.
The other thing I didn't mention in my story was that restoring a tar file into the /sdcard mount point using a root shell in TWRP (v2.4.1.0) was sufficient to massively corrupt the ext4 filesystem on /data every time I did that (based on looking at the output of "e2fsck -f -n" in TWRP). After cleaning things up (ugh - recreating userdata ext4 from scratch means shuttling everything back onto the tablet again) I booted into the (stock) OS, and restored the same tar file into /sdcard as an unprivileged user - and no problems. No clue how/why that would happen, as tar files contain no inode information; but it suggests that there is some strangeness in the way that that emulated /sdcard mount works when a root user writes things... at least in the TWRP version of things. Very bizarre indeed.
Suffice it to say the whole exercise blew away a massive chunk of my time, even though I'm comfortable with this kind of stuff (I have used *nix systems for 30+ years). I can only imagine how folks with less experience feel when they get into a jam.
---------- Post added at 12:01 PM ---------- Previous post was at 12:00 PM ----------
Zsded said:
Snipped to save people's screen space.
Thanks a lot! This solved my problem and I'm now back to 27 gigabytes (which should be somewhere around the promised 32 gebibytes).
I truly appreciate it. I would do more than just to thank your post, but I'm kinda out of ideas (and money).
And of course I'd like to thank everyone else for the help.
This thread can be regarded as closed.
Click to expand...
Click to collapse
Cool!
Change your thread title to include the token "[SOLVED]" - maybe it can help others.
bftb0
bftb0 said:
Cool!
Change your thread title to include the token "[SOLVED]" - maybe it can help others.
bftb0
Click to expand...
Click to collapse
Good idea and thanks for your help!
is there any alterations in ghrese steps for CWM users? I too am having this problem after installing a stock image friom the same sources as posted above, but i used onw of the nexus 7 toolkits to help asist me with this.
Thabnks, i am leaving for a trip tomorrow, so i was sorta shpcked to see 6 gb of storage on my device.
GH0 said:
is there any alterations in ghrese steps for CWM users? I too am having this problem after installing a stock image friom the same sources as posted above, but i used onw of the nexus 7 toolkits to help asist me with this.
Thabnks, i am leaving for a trip tomorrow, so i was sorta shpcked to see 6 gb of storage on my device.
Click to expand...
Click to collapse
Well, given that you need to rebuild the filesystem in the userdata partition, you may not have enough time to work on this tonight, as it means getting everything worth saving backed up to a PC, and then transferring it all back after /data is rebuilt (back to the size that it should be). At that point you can either boot the "factory reset" OS to push your backups back to the tablet, or push them with adb & the recovery running so you can restore the backup before the first time you boot.
You saw how long the TWRP post was; can't say I want to do the same thing for a CWM version. Nor do I know even the first thing about any "toolkit" or what their operational hazards are.
But basically, the bottom line is re-building the /data ext4 filesystem from scratch. Even though TWRP has "mke2fs" & "tune2fs" utilities in it's ramdisk, it appears that they use a custom-built "make_ext4fs" utility for rebuilding ext4 filesystems. CWM probably has something similar - maybe a "format data" menu pick/button or something that sounds like that.
If you think you have enough time for this, you could perform the format using fastboot, as in:
Code:
fastboot format userdata
bearing in mind that this wipes EVERYTHING in /data including the psuedo-SD card (just as will any other procedure which rebuilds /data). So, if you make a Nandroid backup before starting this process, make SURE you've got your backups in a safe place off of the tablet before the format occurs.
Not having an external SD card on the N7 sure makes everything like this a pain in the a**, especially when it's potentially 20+ Gigs of stuff to move around.
good luck
So... I currently did this:
erasing 'userdata'...
OKAY [ 9.107s]
formatting 'userdata' partition...
Creating filesystem with parameters:
Size: 30080499712
Block size: 4096
Blocks per group: 32768
Inodes per group: 8160
Inode size: 256
Journal blocks: 32768
Label:
Blocks: 7343872
Block groups: 225
Reserved block group size: 1024
Created filesystem with 11/1836000 inodes and 159268/7343872 blocks
sending 'userdata' (139157 KB)...
writing 'userdata'...
OKAY [ 30.145s]
finished. total time: 39.254s
Click to expand...
Click to collapse
I had to pull my CWM backup (however, doing a format data/cache using CWM didn't fix it). Eventually, the fastboot command fixed it. However, now when I try to transfer files over MTP/USB, it fails on the Internal Storage. So I am not sure why it is complaining. It doesn't give me an error, it just says the device has stopped responding, even though it is still listed and I have folders that are accessbile.
I guess I will just have to use adb push
EXT4
bftb0 said:
Factory Reset in the recovery does not recreate the ext4 filesystem, it only does deep removal (rm -rf) excluding /data/media. That won't solve the problem of having a tiny filesystem in a huge partition; same filesystem - same max capacity.
Click to expand...
Click to collapse
So where can u find the ext4 file to delete? I did this once, it was a while agao but i need to find it
fixed on my nexus 7 but not sure what happened
thanks to you guys I solved my problem, same thing after installing a stock image from google i got 8gb of storage instead of 32. I did format data on CWM and than i got all of the storage back...i was really worried of not finding a way to solve this a big thanks to you guys.
In case u have the same problem you need to do format data on CWM and NOT wipe data/factory reset.
-----------------------------------------------------------------------------------UPDATE---------------------------------------------------------------------------------
The same problem happened again, i was not worried I did everything i did the first time but for some reason this time nothing got fixed...so after trying many things i asked myself "well what happen if I do not flash in my device the stock userdata after i erased them with the command >>fastboot erase userdata<< ?"
I tried and apparently it solved the problem i had all of my GB back. A little bit scare because during the boot in while i was on the image of the nexus logo (the X with four colors) it went back to the google screen (that one that appears when you turn on your device) but than it kept going normally. I did this two times first flashing in the stock stuff of the 4.1.2 of android and than with the 4.3 version (stock images downloaded from google)
Here the list of commands I used:
fastboot erase boot
fastboot erase cache
fastboot erase system
fastboot erase userdata
fastboot flash boot (I flashed the boot image of android 4.3)
fastboot flash system (I flashed the system image of android 4.3)
For the 4.1.2 I did the same except that i flashed in the userdata image of the 4.1.2 version I turned on the device to check the space on the settings and than i came back and used >>fastboot erase userdata<< and than turned on the device to check if there were some issues but it worked and the storage was back at full size.
I ask to someone a little bit more skilled than me to explain better what happened, and what I really did, because I'm really not sure about this I mean why not flashing the userdata image that came with the full pack from google is not creating problems and flashing it makes my device loose space? I would like to understand more about this.
Thanks bftb0 for this excellent working solution.
My Nexus 7 recently wouldn't boot (bootloop after a power off for no good reason...) and I used the Nexus Root Toolkit in force mode to put 4.4 on (I was on some older version to keep Stickmount working as it didn't work straight off the bat with new Androids). I had to use force because my bootloader is 4.18 I think and the update procedure via the Root Toolkit threw an error about bootloader version. 4.4 appeared to go on fine with force. I have no idea how to update the bootloader. Just playing with GPS apps today and putting maps on and found out I couldn't do it due to lack of space. Found the box for my Nexus 7 as I wasn't 100% what size I had but thought it was a 32G... Your solution worked fine. I didn't have to move the TWRP backups, just copied them over MTP and TWRP found them.
Hello.
This is my 1st post here. Well I have the same probelm. Just bought nexus 7 32GB and 6GB is missing...
Desperion9 said:
Hello.
This is my 1st post here. Well I have the same probelm. Just bought nexus 7 32GB and 6GB is missing...
Click to expand...
Click to collapse
Does it say something like 27GB total? It's not at 32GB total because it needs room for the OS and everything.
NiteFang said:
Does it say something like 27GB total? It's not at 32GB total because it needs room for the OS and everything.
Click to expand...
Click to collapse
Also manufacturers advertise memory in base10 the decimal system so 1MB =1,000,000 bytes but computers don't work like that they operate in base2 the binary system so 1MB is actually 1,048,576 bytes. This is the brainchild of marketing gurus who think people can't understand binary.
On average for every GB advertised in base10 you get on average 70 mb less
Sent from my C5303 using xda app-developers app
Sorry for the slight necro
The same thing happened to me: coming from a custom rom and installing Nexus 7 4.4.4 factory image my 16gb device only showed 6.58gb total.
So i locked the bootloader (using WUG's) and unlocked it again. Result: it now shows 27.58Gb TOTAL SPACE LOL... I tried doing the data wipe in TWRP and i'm all out of ideas...
Anyone?
Expand Your Data partition
Hello dear friends! Welcome
I am happy to share with you a new trick for our lovely U8800PRO.
I am presenting to you a flashable zip tool that can be useful for who wants to customize their "/data" partition for more space without use of sdExt
So now the waiting is over now finally you can customize - expand your /data partition by shrinking your 1.5GB internal storage
so far you all know this trick is already available for U8800 but not work on U8800PRO.
thanks for genokolar who made expanding partition possible for U8800 and inspired me to make this available for U8800PRO. I modified that to work for U8800Pro
Nowadays we have Kitkat Available for our device. But for the great feel of that, Of course for ART run time, ~ 800 MB as /data partition not good
with this you can expand your /data partition at max ~2300 MB
so here you go --
1] Important ! make nandroid backup of your device. [ use latest Teamwin recovery ]
2] use 5irom App to make a backup of your imei [optional]
3] make sure you have backed up your internal storage as this method wipe your internal storage
4] Download one of attached Zip file to External SDcard and flash it from Teamwin recovery [make sure you have unmounted /data , /system , /emmc] !
5] reboot to RECOVERY
6] after booting in recovery go to "wipe" ==>> "Advanced Wipe" and make following from recovery [very important]
wipe /data
wipe /internal_sd
wipe /cache
7] restore your /data partition from nandroid [optional]
8] reboot device and Voila!!!!:cyclops:
this is permanent solution for /data partition, this will not change by changing roms.
tested working on Cm11 CrysisLtu Rom
probably work for any rom test it your self
if you facing problems,
post your partition table
Code:
su
fdisk /dev/block/mmcblk0
now when u see "Command (m for help)"
enter "p" for partition table
Code:
fdisk /dev/block/mmcblk0
Command (m for help): p
this is the safest method however i take no responsibility if you have done incorrectly to your device.
Enjoy!!
Don't Forget to hit Thanks !
Excellent work! I tried with "Data2300Mb-internal_200Mb" but it messed up my partitions.. I do not longer have mmcblk0p13 and it looks like internal storage is now in mmcblk1p2 with ext4 file system.. Restored a whole phone backup so everything ok now but you're sure the script works?
Thank you!
Hello! I also tested this, and as the previous poster, it broke my partition scheme. However, I used the commands found in your scripts to be able to make the system work again, and I now have space available on my data partition!
I am not sure what messed up my partitions, my block numbers matched yours perfectly. Upon running the script for the first time, it seems the script was somehow unable to create partitions 13 and 14. When running it again the next time, the script didn't even start correctly, since its first commands are to mount /data and /emmc. -So at this point, I copied your "partition" script, and put it on my SD-card to run manually. That worked well, and running the make_ext4fs and mkfs.vfat commands afterwards worked to recreate filesystems
Thanks again!
Lihis said:
Excellent work! I tried with "Data2300Mb-internal_200Mb" but it messed up my partitions.. I do not longer have mmcblk0p13 and it looks like internal storage is now in mmcblk1p2 with ext4 file system.. Restored a whole phone backup so everything ok now but you're sure the script works?
Click to expand...
Click to collapse
of course it works
tested with my own device [u8800pro]
please follow steps carefully
other wise if you still facing problems send me your partition table
Code:
su
fdisk /dev/block/mmcblk0
now when u see "Command (m for help)"
enter "p" for partition table :good:
Code:
fdisk /dev/block/mmcblk0
Command (m for help): p
mayank88288 said:
of course it works
tested with my own device [u8800pro]
please follow steps carefully
other wise if you still facing problems send me your partition table
Code:
su
fdisk /dev/block/mmcblk0
now when u see "Command (m for help)"
enter "p" for partition table :good:
Code:
fdisk /dev/block/mmcblk0
Command (m for help): p
Click to expand...
Click to collapse
Code:
Partition 1 does not end on cylinder boundary
/dev/block/mmcblk0p2 * 32769 32831 500 4d Unknown
Partition 2 does not end on cylinder boundary
/dev/block/mmcblk0p3 32831 33206 3000 46 Unknown
Partition 3 does not end on cylinder boundary
/dev/block/mmcblk0p4 33206 483328 3600980 5 Extended
Partition 4 does not end on cylinder boundary
/dev/block/mmcblk0p5 40961 42496 12288 59 Unknown
/dev/block/mmcblk0p6 49153 65792 133120 4c Unknown
/dev/block/mmcblk0p7 73729 73984 2048 5a Unknown
/dev/block/mmcblk0p8 81921 82304 3072 58 Unknown
/dev/block/mmcblk0p9 90113 90987 7000 50 Unknown
/dev/block/mmcblk0p10 98305 98688 3072 4a Unknown
/dev/block/mmcblk0p11 106497 106880 3072 4b Unknown
/dev/block/mmcblk0p12 114689 163840 393216 83 Linux
/dev/block/mmcblk0p13 163841 278528 917504 83 Linux
/dev/block/mmcblk0p14 278529 483328 1638400 69 Unknown
There you go.. I will make some test when I have time.
Deleted
Hi, I tried to flash the zip and my partitions disappeared. At least, I could recover the phone with the official ICS rom. Can anyone tell me how to expand the memory?? It would be very usefull, thanks.
How I got this working
This is a first draft of this guide!
Requirements:
- Recovery TWRP (or something similar), I have "twrp-v2860-260415-u8800pro.zip" (http://forum.xda-developers.com/ideos-x5/pro-development/5-1-cm-12-1-t3099390)
- ADB in Linux or Windows etc (http://developer.android.com/tools/help/adb.html)
- SD card
- One of the partition zip files above (depending on if you want to shrink or restore partitions)
- A rom to flash (restoring from nandroid backup didn't work for me, but by all means, do try )
Steps (READ ALL of this before you start):
1. Download and unzip a partition ZIP file from OP, "Data2300Mb-internal_200Mb.zip" for instrance.
2. Reboot mobile into recovery, TWRP (POWER + Vol up)
3. Do a backup, and manually copy the files from "Internal Storage" to somewhere. Remember to NOT backup TO internal storage!!
4. Unmount all partitions except SD Card!
5. Connect mobile to pc via USB cable
6. Start "adb shell" in the command line on your PC (Linux, Windows whatever)
7. In a text editor, open the "partition" file from your unzipped partition zip, "Data2300Mb-internal_200Mb.zip" in my case.
8. Begin with the command "cd /sbin" and run the commands in the file.
- BUT, skip the "<<EOF" text.
- Also skip the "t" part, line 14, 15 and 16 (not important, but not necessary either )
- Finish with the "w" at line 17 (Important! ).
- The ADB shell commands I ran:
Code:
cd /sbin
./fdisk /dev/block/mmcblk0
d
14
d
13
n
163842
278528
n
278530
483328
w
9. Run "exit" in the adb shell
10. Reboot the recovery
11. Open Wipe -> Advance Wipe -> Check "Data" -> Repair or Change File System -> Change File System -> ext4
12. Open Wipe -> Advance Wipe -> Check "Internal Storage" -> Repair or Change File System -> Change File System -> FAT
13. Reboot Recovery
14. Wipe all partitions except SD Card for good measure
15. Reinstall ROM or try and restore nandroid backup
My recovery is complaining about the "Android Secure" partition not being mounted, but installing a fresh ROM and booting works fine.
Restoring a nandroid backup not so much
Thank you very much!!! I have done it!! Now I have 2GB for apps!!
I am going to explain the easiest way. We can flash the zips by mayank, but at the end of the process is very important to do the steps 7 and 8 to recover our partitions with the new sizes working.
REMEMBER: I didn't backup because I wanted a new installation of a new rom. So, in my process I lost all my information. Save your photos and other important files before do that.
So, I am going to tell you exactly what I did and it works perfect:
1. Download the zip you prefer, I used "Data2200Mb-internal_300Mb.zip" and copy it to your SD Card.
2. Reboot mobile into recovery, TWRP (POWER + Vol up)
3. Unmount all partitions except SD Card
4. Connect mobile to pc via USB cable
5. Flash the zip Data2200Mb-internal_300Mb.zip or the one you prefer.
6. Reboot the recovery
7. Open Wipe -> Advance Wipe -> Check "Data" -> Repair or Change File System -> Change File System -> ext4
8. Open Wipe -> Advance Wipe -> Check "Internal Storage" -> Repair or Change File System -> Change File System -> FAT
9. Reboot Recovery
10. Wipe all partitions except SD Card for good measure
11. Install the new rom, in my case cyanogenmod 4.4
If you have any problem, you can recover your phone with the official rom ICS 4.0 ( U8800pro,Android 4.0,V100R001C00B928 ) . Just install it by the typical method of the folder "dload" in the SD card(POWER + VOL UP + VOL DOWN).
I am very happy with the result, my old u8800pro has a new life with 2gb for apps + kitkat 4.4 + nova launcher
Update (from memory):
I deleted partition 14 (its empty space atm), so now Spotify correctly saves the offline files to the SD card
LVM is a logical volume manager. It joins underlying physical partitions into a pool which can be divided to virtual partitions. Since there are no real partition layout changes, hard bricking is a lot more difficult (but not impossible).
You may have BlePart installed previously, it makes no difference. You can use stock partition layout.
WARNING: LVM requires you to install LVM compatible ROMs. Do not install non-LVM ROM if you have LVM installed.
All your data will be wiped.
Current space division
If you would like to change this, open the zip META-INF/com/google/android/update-binary, find the partition sizes, and modify data partition size (the total space is nearly 3GiB so watch the space).
System - 800MiB
Cache - 10MiB
Data - 2000MiB
Internal SD - rest of the free space
Requirements
LVM-compatible recovery installed
Strongly recommended: Unlocked pink screen
How to install
Download the zip from downloads below
Save it to your phone's EXTERNAL SD card
Reboot to recovery (if you notice errors it is normal, since LVM is not yet installed)
Install the zip from your external SD
Your phone will automatically reboot in 3 seconds
How to uninstall
Method 1
Download the zip from downloads below
Save it to your phone's EXTERNAL SD card
Reboot to LVM recovery
Install the zip TWICE (first time it will notify you LVM is installed, second time it uninstalls it)
Your phone will automatically reboot in 3 seconds
Method 2
Install any non-LVM recovery (TWRP recommended as some older CWM recoveries cannot format vfat properly)
Reboot to recovery
Wipe/Format system, data, cache, internal storage partitions (and repair file system if errors occur)
Reboot recovery
Method 3
Install stock ROM
Downloads
BlePart-LVM-11
Hello, Blefish
These lines i need to change? When i clean applications i have empty space in "System" 220mb, and "Data" i have 270mb empty space.
/sbin/lvm lvcreate -L 700M -n system lvpool;
/sbin/lvm lvcreate -L 10M -n cache lvpool;
/sbin/lvm lvcreate -L 2350M -n userdata lvpool;
/sbin/lvm lvcreate -l 100%FREE -n media lvpool;
Click to expand...
Click to collapse
P.S. Can i delete directly application from system.new.dat?
Good,thanks!
BlePart-LVM-11 uploaded.
This change is minor. It only simplifies installing/uninstalling and makes it easier for the end user. It also adds necessary checking mechanism to make sure the user is installing LVM from a proper location with proper tools.
My external sd card don´t work, can I still get it done?
MazdaGTI said:
My external sd card don´t work, can I still get it done?
Click to expand...
Click to collapse
Through ADB sideload you can do it . You need to install necessary drivers and ADB if you are on windows. Technically it is possible to use ADB and push the zip to /tmp/ for example, and install from there aswell.
Disclaimer:
THIS TUTORIAL IS PROVIDED ''AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES,
INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY
AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL I
BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER
IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
ARISING IN ANY WAY OUT OF THE USE OF THIS TUTORIAL, EVEN IF ADVISED OF
THE POSSIBILITY OF SUCH DAMAGE.
Motivation and idea
Starting with Android 3.x, the system theoretically supports encrypting the personal data on your device. But this has several caveats:
- it turns out that AOSP only supports encrypting /data, leaving other personal data (e.g. your pictures or storage from varios messengers) completely unencrypted on internal (emulated) or external SD storage.
- ever since, the partitioning of /data to a small, limited area leads to "no space left" issues (that's why many people go for app2sd etc.)
- in case your device suffers from physical damage, you usually loose all data you didn't backup previously.
- in case you want to sell or dispose your broken device you never know who will get access to your data anywhere in the future.
- securely wiping flash memory is complicated due to the fact that many controllers do not let you access their trim areas. Having built-in flash makes the situation even worse, especially because almost no manufacturer provides even a "manufacturer-declared-secure" wiping method - unlike some SSD drive vendors.
In this tutorial I will describe how I managed to move all personal data (probably excluding cached data, but this could be enhanced) to my external microSD card, overcoming these issues at the expense of a few drawbacks:
- (micro)SD cards are usually much slower than internal flash: boot time is about 2x slower and some apps feels a little slower, though not sluggish
- the mod requires root
- on most devices the mod also requires a modified boot image (due to change in initial RAM disk)
- it's pretty complicated to set it up (but following this guide can save you many efforts I already invested)
- mounting storage over MTP / USB is currently broken
Although this is more a proof-of-concept, I have been running this setup for a couple of days now as my daily driver without significant issues. I had some force-closes in Firefox, but I don't relate them to this mod and other browsers seem to work fine.
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
Enough said, let's get to work and move all personal data to your external SD card!
CURRENTLY, THIS GUIDE IS TARGETED AT ADVANCED USERS / DEVELOPERS / EXPERTS AND THUS ONLY COVERS THE ESSENTIAL BASICS, NOT THE DETAILS!
FOLLOWING THE PROCESS, YOU WILL LOOSE ALL YOUR PERSONAL DATA ON YOUR DEVICE! MAKE BACKUPS FIRST!!!
Compatibility
The tutorial is based on OmniROM 4.4 and TWRP. With not too much effort, it could be adopted to earlier Android Versions based on AOSP 4.0, probably even 3.0. (most likely, the location and internal layout of some configuration files will vary). Please note that I tried it only on one device, your milage may vary!
Step 1: Find out your partition layout
First off, you need to find out which devices are used for holding which data partitions. You can play around with "mount" or simply look in your fstab files which are located in /fstab.vendor in KK. While in some cases the devices are listed i.e. "by-name", the fstab files of custom recoveries often list the "real" device names. I.e. on my Xperia V they are as follows:
Code:
Internal Data partition: /dev/block/platform/msm_sdcc.1/by-name/Userdata
Internal, emulated SD card: /dev/block/mmcblk0p15
First partition of external SD card: /dev/block/mmcblk1p1
Step 2: Encrypt internal data
After backing up everything, run the usual Android encryption process so your data partition (in this case: /dev/block/platform/msm_sdcc.1/by-name/Userdata) will be encrypted by means of standard 128bit AES Android encryption.
Step 3: Extract the cryptofooter
Boot into TWRP recovery (don't unlock your /data if prompted!) and connect via ADB as root. Usually, the crypto footer is stored in the last 16384 bytes of your partition (but check your fstab to be sure). Now determine the size of your partition with:
Code:
Code:
fdisk -l /dev/block/platform/msm_sdcc.1/by-name/Userdata
In my case:
Code:
Disk Userdata: 2147 MB, 2147483648 bytes
255 heads, 63 sectors/track, 261 cylinders, total 4194304 sectors
Units = sectors of 1 * 512 = 512 bytes
...
In my case, the size is 2147483648 bytes. Subtracting 16384 bytes, you know the starting offset for the extraction. Now extract the footer using dd:
Code:
dd if=/dev/block/platform/msm_sdcc.1/by-name/Userdata of=/cryptofooter bs=1 seek=2147467264 count=16384
Please note, that due to a limitation in dd which supports only up to 2GB this may file - you will need a modified busybox dd command in this case - or just download the file to your UNIX machine and use the normal dd from there.
Step 4: Prepare the external SD card:
We de not want to partition the SDcard, thus we will not put any partition table on it. Nevertheless, we need to determine its exact size using fdisk:
Code:
fdisk -l /dev/block/mmcblk1p1
Disk mmcblk1: 31.9 GB, 31914983424 bytes
255 heads, 63 sectors/track, 3880 cylinders, total 62333952 sectors
Units = sectors of 1 * 512 = 512 bytes
...
Again, subtract the 16384 bytes from 31914983424 and use dd to write the cryptofooter on the end of SD:
Code:
dd if=/cryptofooter of=/dev/block/mmcblk1= bs=1 skip=31914967040 count=16384
Again, this might fail due to dd limitations.
For later testing, we copy over the existing (encrypted) data partition to the SD card:
Code:
dd if=/dev/block/platform/msm_sdcc.1/by-name/Userdata of=/dev/block/mmcblk1p1
Finally, we can wipe the internal data partition:
Code:
dd if=/dev/zero of=/dev/block/platform/msm_sdcc.1/by-name/Userdata
Step 5: Modifying fstab and init files:
Now we will need to modify the fstab files and init so they will reflect the new layout. On most devices, this requires compiling a new rootfs. This can be either done by uncompressing your boot.img, making the changes and recompressing it or recompiling it from sources. The modified boot.img has to be flashed back to the device, usually via fastboot.
In particular, we need to tell Android not to use the internal userdata partition at all, to mount the emulated sd card as usual and to use the external storage for /data using an encrypted ext4 filesystem. In my case, the modified fstab.qcom looks like this:
Code:
/dev/block/mmcblk1 /data ext4 noatime,nosuid,nodev,barrier=1,data=ordered,noauto_da_alloc wait,check,encryptable=footer,length=-16384
/devices/platform/msm_sdcc.1/mmc_host/mmc0 auto ext4 defaults voldmanaged=sdcard0:15,nonremovable,noemulatedsd
#/devices/platform/msm_sdcc.3/mmc_host/mmc1 auto auto defaults voldmanaged=sdcard1:auto
/devices/platform/msm_hsusb_host auto auto defaults voldmanaged=usbdisk:auto
You will also need to modify the twrp.fstab file accordingly.
We also need to modify init (in my case through sony.init.rc) to avoid getting the external sd card being treated as sdcard during boot by uncommenting the relevant lines:
Code:
chmod 0701 /mnt/media_rw
mkdir /storage 0775 system system
mkdir /mnt/media_rw/sdcard0 0700 media_rw media_rw
# mkdir /mnt/media_rw/sdcard1 0700 media_rw media_rw
mkdir /mnt/media_rw/usbdisk 0700 media_rw media_rw
mkdir /storage/sdcard0 0775 system system
# mkdir /storage/sdcard1 0775 system system
mkdir /storage/usbdisk 0775 system system
export EXTERNAL_STORAGE /storage/sdcard0
# export SECONDARY_STORAGE /storage/sdcard1
# for backwards compatibility
symlink /storage/sdcard0 /sdcard
symlink /storage/sdcard0 /mnt/sdcard
# symlink /storage/sdcard1 /ext_card
# symlink /storage/sdcard1 /mnt/ext_card
symlink /storage/usbdisk /usbdisk
symlink /storage/usbdisk /mnt/usbdisk
Step 6: First booting test
With all this set up, we can now boot again into our system. It should ask you for your encryption password (it's the same as you've set it in step 2) and you should notice that it runs a little slower - because SD cards are usually slower than internal flash. You will notice that the size of the internal space and external storage has not changed - we will fix this in the next step.
Step 7: Tweak the cryptofooter and reformat the SD card:
Now comes the fun part: Android determines the size of encrypted filesystems not by information from the filesystem, but by the size as it is stored in the cryptofooter. Therefore, we need to modify the information there. The cryptofooter is a complicated mess. Luckily, there is a great guide which describes its structure much better than the source code itself:
http://nelenkov.blogspot.de/2014/10/revisiting-android-disk-encryption.html
You will need to use a hex editor to edit the from bytes between Offset 0000:0018 and 0000:001B to match the size of your SD card. But please leave enough bytes at the end, at least for the cryptofooter!
Write back your modified cryptofooter as outlined in step 4 and boot into TWRP. Unlock your /data (which is now served from SD), connect via ADB and check the size of your encrypted device using fdisk:
Code:
fdisk -l /dev/block/dm-0
It should reflect the size as you modded it in your cryptofooter. Now, reformat the partition so fills the whole space:
Code:
make_ext4fs /dev/block/dm-0
Step 8: Adjust internal SD.
Now, you are ready to reboot into your system serving its freshly wiped, encrypted data from your external SD! Be amazed by the space you now have for your internal Userdata! Unfortunately, it will still serve "internal SD" from internal flash. First, create a directory on the sdcard to hold it using a root shell:
Code:
# mkdir -p /data/sdcard0
I tried various things to fix this already in the boot process, but somehow vold always got in the way or the device was mounted too early. Also, the media server indexes the internal flash instead of the stuff on the external SD. Therefore, I bind-mount the sdcard0 after every boot and rerun the media server by running the following commands in a root shell:
Code:
# busybox mount -bind /data/sdcard0 /mnt/media_rw/sdcard0
# am broadcast -a android.intent.action.MEDIA_MOUNTED -d file:///storage/sdcard0
Now, you can copy back all your data from the backup to the device and enjoy your new setup!
Final notes:
- Suggestions for correctly mounting the sdcard0 inside data at boot time without the bind-mounting is warmly welcome.
- Some (Stock) ROMs allow you to encrypt both SD "cards", but the implementations I have seen so far seem to be vendor-specific and closed source. Although I noticed that encrypting internal SD seems to work with AOSP out-of-the-box on some devices without external SD (e.g. Nexus S) I didn't find any Custom ROM for my Xperia V which worked with encrypted any of the SDs when putting the "encryptable=sdcard" flag in the fstab file: The storage seems to have been encrypted, but Android simply fails to mount it.
XDA:DevDB Information
All data 2 encrypted, removable SD, Tool/Utility for the Android General
Contributors
Defier525, Defier525
Version Information
Status: Alpha
Created 2015-01-08
Last Updated 2015-01-08
It's old though, I was experimenting on old devices; a KK (Nokia X2) and a LL (QMobile Z8). In summary, what this guide tells is:
Move /data partition (including internal sd card: /data/media) to external sd card
Extract crypto-footer from encrypted internal /data partition
Write crypto-footer to new /data partition on external sd card
I have tested this on QMobile with Stock Android 5. This device has a bricked eMMC and all my partitions reside on external sd card including /data. So, I tried encrypting using built-in "Encrypt Phone" Settings which fails with a simple reset of UI.
On my other phone with KK (CM-11), to overcome the shortage of internal memory, I Disabled Internal Memory (DIM) i.e. use device in "Physical Primary Only" mode instead of "Emulated primary, physical secondary". I tried same "Encrypt Phone" Settings which failed in same manner. So, I was wondering where this "encryptable=sdcard" thing works? I edited fstab in boot.img to add this flag but that makes no difference.
My second question, will this dumped crypto-footer hack work with both approaches? i.e. with DIM and with whole /data on external sd card?
Currently I'm using another working solution; an encrypted (EncFS) directory placed on external sd card. An initd script (replacing /system/bin/sdcard) mounts this directory using FUSE kernel module on the default sd card path i.e. /storag/sdcard0. Since "dm-crypt" (kernel module) is the default FDE used by AOSP, there must be a way out to use dm-crypt for SD card or any other (than /data) partition encryption like this.
EDIT:
One possible reason for in-encrypt-able /data partition on external SD card is the absence of footer space at the end of partition i.e. filesystem must be smaller than partition size by at least 16KB.
Reference:
Android Device-Specific Code:
If the length value is negative, then the size to format is taken by adding the length value to the true partition size. For instance, setting "length=-16384" means the last 16k of that partition will not be overwritten when that partition is reformatted. This supports features such as encryption of the userdata partition (where encryption metadata is stored at the end of the partition that should not be overwritten).
Click to expand...
Click to collapse
FDE - Encrypt an existing device
Orig filesystem overlaps crypto footer region. Cannot encrypt in place.
encryptable=footer
CM12 will not encrypt /data on hlte if it has previously been formatted by TWRP