[MOD] Move all your internal and external data to encrypted, external SD - Android Software Development

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

Related

(Q) A2SD: anyone interested in helping get a2sd to work.

I was just curious if anyone would be interested in making a step in the right direction dog such a new device. I have worked with a2sd on several other android phones(most of which already had froyo ported). I also have some experience in porting Roms to other devices. If anyone else that has already bought a flipside, and at least a pretty decent understanding on how the OS works and how to stuff like that. Also... it would be a huge plus if someone has experience in building Roms, as well as dumping them from our devices.
I'm planning on starting off with a clean and fast ROM for our phones... and hopefully with a2sd built in as well, or at least installable.
If you are interested then send me a PM and we can get to work... the sooner the better!
Looking at /proc/filesystems it seems that the stock kernel only has support for yaffs2 and vfat. The stock image doesn't include any .ko files so I'm assuming all of the needed functionality is compiled into the kernel with no support for external module loading.
Using Busybox 1.18 from the Market I can loop mount vfat images without any problem (I had partitioned my SD card under Linux but it seems that init and motobox are hard-coded to load mmcblk0p1 at /sdcard and then it kept unmounting /sdcard randomly when I had extra partitions after it... so loop-mounting is safer without breaking things).
The problem is of course permissions since vfat doesn't support ugo-style permissions. We can't loop mount yaffs2 images since the emulated block device is not NAND flash... and that's also the reason we can't just dd a yaffs2 filesystem into a partition on the SD card.
I'm going to experiment with init.rc a bit and see if I break anything by forcing it to mount /sdcard immediately after /system (because that's where it should be mounting /data). I don't want to run the risk of loop mounting a file from /sdcard onto /data only to have it forcibly unmounted when vold gets enumerated and remounts /sdcard.
It's really unfortunate that there's so little space on the internal memory of this device... /cache is ~140 Mb, /system is ~180 Mb, and /data is ~160 Mb, so even if we were to lean out /system and swap it around with the others, we only get 20 Mb more on /data... that's way too much work for such little gain.
OT - Why is there so much hatred against this device? It's more than fast enough to play Quake 3 and I'd trade all the screen real estate in the world for a hardware keyboard... oh, and the phone actually fits in my pocket (unlike my friend's Droid X which is so huge and unwieldy...). Anyway, I just think it's odd.
Update: It seems that the device checks that boot and recovery images are signed with a Motorola digital certificate at runtime... I can flash the partitions just fine, but it just boot-loops with "Error CC00 DBAD" and then eventually drops back to the bootloader. Unfortunately this means that I can't test any changes to mount points in init.rc at this time. Since I don't have any means to recover the device from a bad bootloader flash, this will have to be the end of the road for me at this time. Some other brave soul will have to experiment with replacing mbmloader or lbl to allow loading custom images signed with test certificates from the SDK.
EDIT: I should mention that I had to use sbf_flash to upload images since fastboot won't work until we have an unlocked bootloader on the device. I wish I had read up on and-developers.com before discovering all of this stuff the hard way. Oh well. Even the ramloader from the SBF image is signed with a Motorola digital certificate so I'm not sure that using sbf_flash (I haven't tried RDSlite, don't have Windows) is the way forward either. I don't think we can just dd the new images for the bootloader either since not all of the MTD partitions are exposed to the OS. This is going to be harder than I expected.
Init.rc executes /system/etc/install-recovery.sh as a privileged user. Lucky for us, this is at the end of the init script once everything is up and running and AT&T/Motorola have removed the file so we don't have to alter anything of value. I've tested it and adding install-recovery.sh will run commands as root. This is our way in.
Hopefully we can get apps stored on the SD card soon.
EDIT: The contents of this post are now deprecated and remain here for historical purposes only! Please see the posts below for the "proper" scripts.
So after playing with it some more, mounting a vfat filesystem on /data simply doesn't work because permissions and ownership can't be set. Even setting the most relaxed permissions possible I found bizarre side effects like apps won't install from the Market and wifi can't be toggled on/off. I found an ext2.ko compiled for the Milestone stock rom (I've attached it here for convenience, but I found it on android-hilfe.de) works just fine though, so now we can use a proper filesystem.
Right now I'm mounting a 512 MB ext2 filesystem onto /data and everything works great. The biggest problem I'm having though is that switching to USB Mass Storage mode forcibly unmounts my filesystem so that obviously causes problems, but I don't really see a way around this since UMS mode offers up the entire MMC device so there's no way to just pick one partition to expose...
I'm going to test more things to make sure nothing has broken before I post a full write up on this, but if you know what you're doing, it shouldn't be hard to figure it out on your own. I know most of the Apps2SD projects are using an application to manage data then setting up a separate partition on the SD card, but it usually relies on some custom recovery image and the goal for me is to do this against a stock rom. I'm also using a loop-mounted filesystem because it makes it easier to migrate to a new SD card without having to worry about partitions and what-not.
EDIT: Here's a quick-n-dirty version for those of you who would like to try it. This will show the proof of concept and let you see if it works for you without breaking anything major. All changes to /data will be undone on the next reboot. If you know what you're doing, then I would recommend making the changes permanent by mounting /data in install-recovery.sh. This is assuming you have rooted your phone (I used z4root) and have Busybox installed (I used 1.18 from the Market) and at least 512 MB free on your SD card.
Code:
adb push ext2.ko /sdcard
adb shell
su -
/system/bin/busybox mount -o rw,remount /system
/system/bin/busybox cp /sdcard/ext2.ko /system/lib/modules
/system/bin/busybox chown 0.0 /system/lib/modules/ext2.ko
/system/bin/busybox chmod 0644 /system/lib/modules/ext2.ko
/system/bin/busybox mount -o ro,remount /system
/system/bin/busybox insmod /system/lib/modules/ext2.ko
/system/bin/busybox dd if=/dev/zero of=/sdcard/userdata.ext2 bs=1M count=512
/system/bin/busybox losetup /dev/block/loop0 /sdcard/userdata.ext2
/system/bin/busybox mkfs.ext2 /dev/block/loop0
/system/bin/busybox mount -o rw,remount /
/system/bin/busybox mkdir /userdata
/system/bin/busybox mount /dev/block/loop0 /userdata
/system/bin/busybox chown 1000.1000 /userdata
/system/bin/busybox chmod 0771 /userdata
cd /data
/system/bin/busybox cp -r -f -H -p . /userdata
cd /
/system/bin/busybox umount /userdata
/system/bin/busybox rmdir /userdata
/system/bin/busybox mount -o ro,remount /
/system/bin/busybox umount -l /data
/system/bin/busybox mount /dev/block/loop0 /data -o rw,sync,nosuid,nodev,noatime,nodiratime
If you've done everything right, "lsmod" and "cat /proc/filesystems" will show "ext2", "mount" will show /dev/block/loop0 on /data, and "df" will show more space available on /data. You should also see the extra space in Settings -> SD card & phone storage -> Internal phone storage.
My install-recovery.sh currently looks like this:
Code:
#!/system/bin/sh
if [ -e /system/lib/modules/ext2.ko ] && [ "`/system/bin/busybox lsmod | /system/bin/busybox grep -c ext2`" -eq "0" ]
then
/system/bin/busybox insmod /system/lib/modules/ext2.ko
fi
# wait 30 seconds, /sdcard is being re-mounted by vold...
/system/bin/busybox sleep 30
if [ -s /sdcard/userdata.ext2 ] && [ "`/system/bin/busybox cat /proc/filesystems | /system/bin/busybox grep -c ext2`" -eq "1" ]
then
/system/bin/busybox losetup -d /dev/block/loop0
/system/bin/busybox losetup /dev/block/loop0 /sdcard/userdata.ext2
/system/bin/busybox umount -l /data
/system/bin/busybox mount /dev/block/loop0 /data -o rw,sync,nosuid,nodev,noatime,nodiratime
fi
You don't have to use this as-is, but it's at least a starting point.
UPDATE: Seems like we need a Busybox with a proper tune2fs utility as the one in the Market is pretty useless (only changes volume labels...). You'll want to run "tune2fs -c 0 -i 0 /dev/block/loop0" to disable mandatory fsck'ing, otherwise the kernel will reject the mount after a few times because it's dirty. Something funky is happening because any apps that I install once the image is mounted will not show up after reboot, but the files are there and they continue to take space. Maybe I'm breaking something with the lazy umount?
At the risk of sounding like I'm only talking to myself, I'll post another update...
I found that most of my troubles were stemming from waiting so long to remount /data, so I caved and put an ext2 partition on my SD card so that I don't have to wait 30 seconds before mounting over /data.
Oddly enough, mounting a native ext2 partition for /data from the SD card was actually MUCH slower than the loop mounted image. I should note that I'm not mounting the partition with the 'sync' option. I could get away with that on the loop device since it's just doing it in memory anyway and changes are only being written on the default commit interval for the host filesystem. Anyway, I'm using a 4 GB class 10 SD card, but it's still much slower than the internal flash. Just to confirm my results, I tried with a native ext2 partition on a 2 GB class 2 SD card... the phone took nearly 5 minutes finish booting to a responsive home screen!
But, at least I can mount /data right away when I'm using a physical partition... So I've done the best of both worlds by creating a ext2 partition on my SD card and then loop mounting an ext2 image onto /data. The result: I'm running my entire /data on a class 2 SD card and it's much faster than a native partition on a class 10! In fact, the difference in boot time compared to internal storage is only a few seconds! Now that I'm mounting /data right away I no longer have problems with missing apps or data after reboots. The only drawback is that you have to waste a bit of space to do it this way since the filesystem reserves 10% for itself, you need a 560 MB partition to hold a 512 MB image (in my case I'm actually running a 384 MB image since I don't really need that much space anyway). Personally, I don't mind since I'm running it off of a cheapo class 2 device and having everything in a single image file makes it super simple to migrate to a different SD card if I want to.
I'll keep running this setup for a couple days now to make sure that there's nothing else broken, but for right now I've got it setup just how I want it: no extra application to manage which apps are where and no random force closing from applications running off of SD card that weren't meant to be. Oh yeah, and I don't have to worry about dalvik-cache cannabilizing my internal storage either.
If anyone else is following along, I'd like to hear your experiences with this too. I'll post the final write-up once I'm certain that nothing else is broken.
I'm definitely following along appreciatively, but will have to wait for the step by step to give it a try.
Sent from my Liberty using Tapatalk
Well, here is the much-awaited write-up...
First, acknowledgements. This would not have been at all possible without the ext2 module provided by user Fnordi on android-hilfe.de. Unfortunately I can't read German so I have no idea if he actually compiled it for the Milestone or somebody else did, but I grabbed the file from his post about loading Debian Linux on the Milestone, so kudos to him and whomever else was involved. I also wouldn't have been able to write this up so neatly without the sdparted script by 51dusty. I had to make a few alterations because we're not running on CyanogenMod Recovery, but it's still mostly his work nonetheless. The parted and tune2fs binaries are from j_r0dd's Recovery image for the Motorola Backflip. Also, cheers to the folks on android-dls.com wiki, even though the information is mostly targeted at the G1 and ADP, it was still very good reading.
WARNING WARNING WARNING
I have not yet devised a way to migrate the SD card data back to internal storage! Once you've migrated /data to the SD card, anything new from that point forward will stay on the SD card. Additionally, I will not be providing support for anyone who deviates from the process outlined here. If you're clever enough to do it some other way, then you're clever enough to get out of trouble on your own. Do this at your own risk, I am not responsible for any harm or loss of data that may occur as a result of following this procedure. You have been warned!
WARNING WARNING WARNING
Requirements: Android SDK installed with working ADB, root access on your Motorola Flipside and Busybox 1.18 installed from the Market. There is plenty of information available on the forum on how to do these things so please don't post here asking how to root the phone. The assumption is that you know how to gain root access and that you're comfortable with ADB. If you're struggling with doing any of these things, then you should reconsider if you want to attempt this at all.
1. Backup your SD card and format it so that it's completely clean and has only a single, empty, FAT32 partition on it.
2. Grab the attached ZIP file and extract the files directly into the SD card (no sub-folders). Make sure these are the only files on there, everything else will be erased!
3. Set your phone's USB connection to "Charge Only".
4. Connect via ADB using "adb shell".
5. Now run the following:
Code:
su -
cp /sdcard/setup.sh /data/local
/data/local/setup.sh
6. The script will now setup a 512MB partition on your SD card with a 448MB image for /data. All of the other data on your SD card will be lost!
7. After the script is finished, restore any files that you backed up before to the FAT32 partition of your SD card.
8. Set your phone's USB connection to "Charge Only" and never change it again!
9. You should now have a lot more space for apps!
Please note that the phone will feel a little sluggish for a little bit after boot, but soon it will have everything buffered in memory and it will feel very smooth again.
Enjoy!
EDIT: I should mention, if you want to undo the changes, either shut down the phone and remove the SD card or delete /system/etc/install-recovery.sh. Either way, the phone will revert back to internal storage automatically on the next boot.
EDIT 2: I noticed that the Market install of Busybox doesn't link any existing commands, only new ones. I've been using the 1.18 binary from the Market but I had used my own script to link everything properly (mostly to replace "sh" since no tab completion was killing me!). I've now included the install script in the zip. So install the Busybox 1.18 from the Market, then run my install-busybox.sh, then reboot and follow the instructions above. Sorry for the mix-up!
Alright, just making sure. You're last Edit:, you said that we have to run your "install busy-box.sh". To run it, is it in the script in your post above, or is there some other way? I'm pretty new to runnin' all these scripts since I'm on a Captivate which is far easier than this (I'm doin' this for my girlfriends Flipside).
Just in general, what are the steps you run your install busy-box?
Thanks ahead of time.
thank!!!!!!!
can anybody help me do this because when i do it at the bottom it says failed
You leave it on "Charge Only" because otherwise it will unmount the /data image and cause it to crash.
This was stated previously in my posts. Please read carefully next time.
ErebusRaze said:
Just in general, what are the steps you run your install busy-box?
Click to expand...
Click to collapse
1. Install Android SDK on your computer.
2. Hook up via ADB and install z4root.
3. Run z4root on your phone. It will root the phone and reboot.
4. Install Busybox from the Market.
5. Copy the contents of the zip file to your SD card.
6. Log in as root via ADB ("adb shell" then "su -").
7. busybox mount -o rw,remount /system
8. cp /sdcard/install-busybox.sh /data/local
9. busybox sh /data/local/install-busybox.sh
10. reboot
11. Log in as root via ADB ("adb shell" then "su -").
12. ls -la /
If everything is done properly, the last step should result in an expanded directory listing in a color terminal. You can now proceed with the rest of the tutorial.
ok after i reboot i got look at my phone storage and it is still the same it didnt increase or anything
the method you've presented here sounds interesting, but i'd really hate to lose the memory card access function of my phone (i use it quite often...very often in fact). so i have a question or two:
would it be possible to get a bigger sdcard(say a 4GB or 8GB sdcard), and dd my current sdcard's partition to the new card, and then create another partition on the rest of the new card and have this method utilize that new partition in the manner described here? would the entire sdcard still get unmounted if i set the phone to memory card access?
<edit>: never mind...it seems this question would be answered by: "The script will now setup a 512MB partition on your SD card with a 448MB image for /data".....so apparently yes the sdcard would still be unmounted :/
igetsosickofregistering said:
the method you've presented here sounds interesting, but i'd really hate to lose the memory card access function of my phone (i use it quite often...very often in fact). so i have a question or two:
would it be possible to get a bigger sdcard(say a 4GB or 8GB sdcard), and dd my current sdcard's partition to the new card, and then create another partition on the rest of the new card and have this method utilize that new partition in the manner described here? would the entire sdcard still get unmounted if i set the phone to memory card access?
<edit>: never mind...it seems this question would be answered by: "The script will now setup a 512MB partition on your SD card with a 448MB image for /data".....so apparently yes the sdcard would still be unmounted :/
Click to expand...
Click to collapse
why would you even bother?...
search: link2sd
nuff said
I backed up my sdcard and copied the files over. I have busybox and it is rooted.
I accessed superuser and copied the files over per the write-up.
When I ran setup.sh, it gave me the following error:
----
busybox found.
Usage: mount [-r] [-w] [-o options] [-t type] device directory
grep: not found
:bad numbergrep: not found
:bad numbermodule insertion failed, aborting!
rm failed for /system/lib/modules/ext2.ko, Read-only file system
Usage: mount [-r] [-w] [-o options] [-t type] device directory
----
I understand that it is a read only error, but not sure how to edit the script (or if I even need to) to get it to work. It looks like the first line of the script remounts the system properties to -rw, but it still failed to write.

[HOWTO] Ideos S7 Froyo Android internal storage increase on stock ROM

Hi all, originally intending to post this tutorial to Ideos S7 Android Development but got a nice greeting from xda-developers.com unallowing newbies to post there
So I just got a brand-new-in-a-box, dead cheap, Ideos S7 tablet -- my first android tablet, and my second android device. I brought my last device about 2 years ago, a G1 that I only kept for a week and sold it afterwards. I was thinking that at that time Android isn't ready yet for replacing my E71.
Back to the Ideos S7, mine is already preloaded with TRZ-mod-0.2 ROM, which is nice. However, I had some issue with wireless network. Whenever I disable my wifi, I would ge trouble activating it as it constantly disabled by itself. Thus, I decided to go back to available stock ROM. Long story short, I've chosen the Froyo 2.2.2 Sweden coded S7V100R001C63B110, and made myself comfortable with repeating Huawei's flashing process.
The firmware seems more stable, and does not have the wireless network activation/deactivation issue. Stock ROM lover anyone
However, the stock ROM doesn't have apps2d+ or whatever that was called, to extend the internal storage. 137MB of free space is really pity for such device. I couldn't run Data2Ext* script successfully, as the default shell /system/bin/sh doesn't seems to support square brackets on scripts conditional parts. Busybox 1.18 supports it, but somehow it would cause all the commands executed in the script to ran by Busybox, causing "applet not found" errors. The other option would be Link2SD, which could probably saved me 10+ hours of hacking. It had its drawback though, the current version on the market expects the extended internal tablet storage partition to reside on the external SD card. Some hacking to mount the internal SD partition works, but not sure whether it would got correctly mounted on boot.
Also, the most important thing: nothing feels better than looking at "Available space" on "Internal tablet storage" of 5.5GB
So here it is, the tutorial for extending the internal storage. Most of the information used are gathered from various sources, and rewritten here for your enjoyment!
REQUIREMENTS:
=========
a) All hardware: Ideos S7 -- should work on Slim as well, data cable, charger, a living being..
b) Rooting -- I've used Gingerbreak from the market
c) Terminal Emulator -- Android Terminal Emulator works fine. Irritating blue background though.
d) Busybox -- 1.18 version is working fine
e) Root explorer -- Optionally used, for easier file editing and copying.
STEPS:
=========
0) Backup your data, as all data in internal storage will be lost!
---------
Well honestly I didn't do this as I got my contacts and mail synced on the internet. My S7 only got 5 days of lifetime so not much data there yet. Sorry no guide on how to do this
1) Partition the internal SD (or external SD card if you intend to do so).
---------
It is recommended to use a good class of memory card when using external SD card for the tablet storage partition.
There's possibly partitioning tools available for the architecture, but I did it with EASUS Partition Master on a Windows system. Mac OS's Disk Utiliy should work as well. Don't worry too much about the partition type, we'll reformat it later with busybox later anyway.
To partition the internal (or external) SD card, connect your data cable to your phone. When the USB connection notification came up, activate the USB storage mode. You don't need to install the Huawei S7 (or adb) drivers.
Fire up your partitioning application, and identify your storage. Delete (or) resize the existing FAT partition. Create another primary partition afterwards, with ext2 filesystem. ext3 and ext4 isn't supported in the stock ROM, so you probably have to either install a kernel module for the ext3,4 or replace your boot.img. Hey but that's not going to be a stock ROM
2) Root the device
---------
Install Gingerbreak from the market. Enable USB debugging in Settings -> Application -> Development, or else it won't work. Run Gingerbreak, root your device! The device will restart after successful process, and you are ready to modify your root filesystem.
3) Prepare the required tools
---------
You'll optionally need busybox to format and edit the files. Copy over the busybox binary file to /system/xbin/. The terminal login path would automatically points there so you can run busybox from anywhere inside the terminal.
4) Prepare the new data directory
---------
Fire up your terminal emulator. You'll need to be logged in as root to do the whole operation mentioned. Thus, type in:
Code:
su
Mount the new partition you've prepared on step (1). For internal SD, it's going to be /dev/block/mmcblk0p2 device, or for external SD, /dev/block/mmcblk1p2. You can also use other shorthand such as /dev/block/vold/179:2. But for simplicity, I'll use mmcblk*p* throughout the tutorial.
Prepare the mount point for your prepared data partition, and mount it. If it's currently mounted, unmount it first.
Code:
umount /dev/block/mmcblk0p2
mkdir /system/sd
You can also format the partition now if you didn't specify the partition type during the partition creation.
Code:
busybox mke2fs -m0 -b4096 /dev/block/mmcblk0p2
Now mount the extended data partition.
Code:
mount -t ext2 /dev/block/mmcblk0p2 /system/sd
We'll still need to be able to access the original data partition now and later, so, prepare the mount point and mount it as well.
Code:
mkdir /system/internal
mount -t yaffs2 /dev/block/mtdblock4 /system/internal
At this stage, you'll need to copy over all files inside the original /data directory to your new sd directory. You'll also need to make sure that the permissions isn't changed during the process. To do this, just tar the entire original data directory to your new one.
Code:
cd /system/internal
busybox tar -cvf /system/sd/old-data.tar *
cd /system/sd
busybox tar -xvf old-data.tar
busybox rm old-data.tar
The initialization for the new data directory mounting in the boot process does not modifies the boot image's init.rc. Thus, it seems that the initialization process is called after the radio initialization. I can't get my GSM to work without this step. We'll need to symbolic-link back the /system/sd/radio directory to the original internal storage /data/radio directory. And remember that on the boot process, we'll need to mount /system/internal *before* /system/sd.
Code:
cd /system/sd
busybox rm -rf radio
ln -s /system/internal/radio /system/sd/radio
After fiddling for several hours, I realized that the date and time settings gets reset on each boot. Fixed by symlinking the /data/date.time back to the internal storage.
Code:
cd /system/sd
busybox rm -rf date.time
ln -s /system/internal/date.time /system/sd/date.time
5) Prepare the boot init script
---------
The Froyo boot process runs init.rc script, which is replaced by the boot.img when system boots. So we can't put our new /data directory mount commands there, unless we extract, unpack, modify, repack the boot.img. Ok so I decided that modifying boot.img will be the last step if I can't get it working without it. There must be an easier way!
Also, there aren't any rc.d, rc3.d, bla bla directory in which we can put our custom initialization script.
Luckily, there is a script that is called from the init.rc script during boot, which is stored on the root filesystem and can be customized. It's called /system/etc/install-recovery.sh. Thus, we'll put the initialization script there. If you already got a /system/etc/install-recovery.sh, you can just add our initialization script in the beginning of the. Alternatively, you can create a separate script to perform init, and call it from your modified /system/etc/install-recovery.sh.
There will be drawback, for example, it seems that the script is called after radio initialization, so we'll need to use the old /data/radio directory from the original /data directory, prepared on step (4).
So now you'll need to create (or copy) the install-recovery.sh script. You can use vi from the busybox, or easier is to just copy and paste the install-recovery.sh script provided in this post. In case you're a vi expert, fire up these commands. Don't forget to remount the root filesystem as rw first!
Code:
busybox vi /system/etc/install-recovery.sh
Write in the install-recovery.sh script:
Code:
#!/system/bin/sh
mount -t yaffs2 /dev/block/mtdblock4 /system/internal
mount -t ext2 /dev/block/mmcblk0p2 /system/sd
mount -o bind /system/sd /data
Don't forget to set executable and readable attribute at least for root user, or else the system can't run the script!
Code:
chmod 755 /system/etc/install-recovery.sh
So now you're ready to reboot the system. Double check the install-recovery.sh script, make sure all commands mounts the partition exactly to where you intend it.
6) Reboot your Ideos S7!
---------
Reboot and enjoy the trendemous increase on your internal tablet storage
WARNING!!! Do not attempt to perform factory data reset while running with /data mounted. It seems that S7 will format the /data partition as yaffs2, not sure as I haven't checked it. But it worth to try to change the install-recovery.sh script to mount the data partition as yaffs2, and then performing factory data reset.
Sorry I can't post either an image or attachment yet
watch_mania said:
Sorry I can't post either an image or attachment yet
Click to expand...
Click to collapse
Btw, if someone with account capable of posting images and files would like to help, I can send the image links and files to your e-mail, so you can post it here
Should've post the title with [HOWTO] prefix. Sorry about the newbie-ish thing
Hey, sure i can post them! I've set up a site for the "Install GNU/Linux" anyway. I'll be looking to follow this howto sometime in the future. Tell ya what tho, i'd have saved 10+ hours hacking had i known gingerbreak was in market also!
threader said:
Hey, sure i can post them! I've set up a site for the "Install GNU/Linux" anyway. I'll be looking to follow this howto sometime in the future. Tell ya what tho, i'd have saved 10+ hours hacking had i known gingerbreak was in market also!
Click to expand...
Click to collapse
Unfortunately I don't own the Ideos anymore
Good luck on your site!
can you make a simple tutorial to us? i need it badly.
Could you help me.... do I have to label the drives as "mmcblk..." because it's not recognizing the directory
---------- Post added at 12:22 PM ---------- Previous post was at 12:21 PM ----------
I'm stuck after entering su in the emulator...please help
Nice guide
work perfectly on S7 slim
i do all the steps using sshdroid and putty so i can use cut&paste from web page
the only think that i've to add is mount syster as readwrite:
mount -o rw,remount -t yaffs2 /dev/block/XXXXXXX /system
Thanks for this guide i will do the same on all my device
i'm triing to increase internal memory on stock rom.
I successfully done on S7 slim (i found i guide writen by watch_mania) but on Vodafone Smart i've some trouble (i use sshdroid and putty).
I do the following step :
1) Partiton the external SD with two filesystem the the first one FAT32 the second one ext2
this is the output of fdisk :
/system/sd # fdisk -l /dev/block/mmcblk0 Disk /dev/block/mmcblk0: 7969 MB, 7969177600 bytes
255 heads, 63 sectors/track, 968 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes Device Boot Start End Blocks Id System
/dev/block/mmcblk0p1 1 509 4088511 83 Linux
/dev/block/mmcblk0p2 510 968 3686917+ b Win95 FAT32
2) mount system as read-write and create new mount point
mount -o rw,remount -t yaffs2 /dev/block/mtdblock4 /system
mkdir /system/sd
mkdir /system/internal
3) format ext2 partition created at 1)
mke2fs -m0 -b4096 /dev/block/mmcblk0p1
4) mounting the "original" /data on /system/internal and new ext2 partition on /system/sd
mount -t yaffs2 /dev/block/mtdblock6 /system/internal
mount -t ext2 /dev/block/mmcblk0p1 /system/sd
5) copy the content on "original" /data on /system/sd
cd /system/internal
tar -cvf /system/sd/old-data.tar *
cd /system/sd
tar -xvf old-data.tar
rm old-data.tar
6) create boot init script
vi /system/etc/install-recovery.sh
and write inside :
#!/system/bin/sh
mount -t yaffs2 /dev/block/mtdblock6 /system/internal
mount -t ext2 /dev/block/mmcblk0p1 /system/sd
mount -o bind /system/sd /data
Originally in the guide for S7 slim you have to do :
cd /system/sd
rm -rf radio
ln -s /system/internal/radio /system/sd/radio cd /system/sd
rm -rf date.time
ln -s /system/internal/date.time /system/sd/date.time
BUT if i try to do that the device does not recognize the sim.
If i try to don't do that the device loop during boot.
on S7 Slim in /system/internal/radio i found this file :
srwxrwxrwx 1 0 0 2048 Dec 31 06:49 qmux_connect_socket
the same file on vodafone smart is located in /system/internal/local/tmp/
but if i try to link it does not work and the device loop.
Will this also work on altek A14 LEO(an Android 2.1 phone)? It has less than 100MB internal storage, although it built-in dtapps2sd with the newest stock firmware, "/data/data" is still stored in internal storage. Because the version of dtapps2sd in stock firmware is not latest version, no "/data/data" mount on SD-EXT support. And I can't upgrade dtapps2sd myself due to no reflash tool for this phone.
Thank for the niec post, i,ll try it shortly
Increasing Internal Memory
Hi,
Has anyone tried a superb "setinstalllocation-xxx.apk" available in xda-developers.
I have been using it and it is really good. But as mentioned by watch-mania that 139 or 140 MB of available storage is a pity.
Your device must be rooted to use the above apk. You can successfully use gingerbreak available from this excellent forum.
more info
watch_mania said:
Hi all, originally intending to post this tutorial to Ideos S7 Android Development but got a nice greeting from xda-developers.com unallowing newbies to post there
So I just got a brand-new-in-a-box, dead cheap, Ideos S7 tablet -- my first android tablet, and my second android device. I brought my last device about 2 years ago, a G1 that I only kept for a week and sold it afterwards. I was thinking that at that time Android isn't ready yet for replacing my E71.
Back to the Ideos S7, mine is already preloaded with TRZ-mod-0.2 ROM, which is nice. However, I had some issue with wireless network. Whenever I disable my wifi, I would ge trouble activating it as it constantly disabled by itself. Thus, I decided to go back to available stock ROM. Long story short, I've chosen the Froyo 2.2.2 Sweden coded S7V100R001C63B110, and made myself comfortable with repeating Huawei's flashing process.
The firmware seems more stable, and does not have the wireless network activation/deactivation issue. Stock ROM lover anyone
However, the stock ROM doesn't have apps2d+ or whatever that was called, to extend the internal storage. 137MB of free space is really pity for such device. I couldn't run Data2Ext* script successfully, as the default shell /system/bin/sh doesn't seems to support square brackets on scripts conditional parts. Busybox 1.18 supports it, but somehow it would cause all the commands executed in the script to ran by Busybox, causing "applet not found" errors. The other option would be Link2SD, which could probably saved me 10+ hours of hacking. It had its drawback though, the current version on the market expects the extended internal tablet storage partition to reside on the external SD card. Some hacking to mount the internal SD partition works, but not sure whether it would got correctly mounted on boot.
Also, the most important thing: nothing feels better than looking at "Available space" on "Internal tablet storage" of 5.5GB
So here it is, the tutorial for extending the internal storage. Most of the information used are gathered from various sources, and rewritten here for your enjoyment!
REQUIREMENTS:
=========
a) All hardware: Ideos S7 -- should work on Slim as well, data cable, charger, a living being..
b) Rooting -- I've used Gingerbreak from the market
c) Terminal Emulator -- Android Terminal Emulator works fine. Irritating blue background though.
d) Busybox -- 1.18 version is working fine
e) Root explorer -- Optionally used, for easier file editing and copying.
STEPS:
=========
0) Backup your data, as all data in internal storage will be lost!
---------
Well honestly I didn't do this as I got my contacts and mail synced on the internet. My S7 only got 5 days of lifetime so not much data there yet. Sorry no guide on how to do this
1) Partition the internal SD (or external SD card if you intend to do so).
---------
It is recommended to use a good class of memory card when using external SD card for the tablet storage partition.
There's possibly partitioning tools available for the architecture, but I did it with EASUS Partition Master on a Windows system. Mac OS's Disk Utiliy should work as well. Don't worry too much about the partition type, we'll reformat it later with busybox later anyway.
To partition the internal (or external) SD card, connect your data cable to your phone. When the USB connection notification came up, activate the USB storage mode. You don't need to install the Huawei S7 (or adb) drivers.
Fire up your partitioning application, and identify your storage. Delete (or) resize the existing FAT partition. Create another primary partition afterwards, with ext2 filesystem. ext3 and ext4 isn't supported in the stock ROM, so you probably have to either install a kernel module for the ext3,4 or replace your boot.img. Hey but that's not going to be a stock ROM
2) Root the device
---------
Install Gingerbreak from the market. Enable USB debugging in Settings -> Application -> Development, or else it won't work. Run Gingerbreak, root your device! The device will restart after successful process, and you are ready to modify your root filesystem.
3) Prepare the required tools
---------
You'll optionally need busybox to format and edit the files. Copy over the busybox binary file to /system/xbin/. The terminal login path would automatically points there so you can run busybox from anywhere inside the terminal.
4) Prepare the new data directory
---------
Fire up your terminal emulator. You'll need to be logged in as root to do the whole operation mentioned. Thus, type in:
Code:
su
Mount the new partition you've prepared on step (1). For internal SD, it's going to be /dev/block/mmcblk0p2 device, or for external SD, /dev/block/mmcblk1p2. You can also use other shorthand such as /dev/block/vold/179:2. But for simplicity, I'll use mmcblk*p* throughout the tutorial.
Prepare the mount point for your prepared data partition, and mount it. If it's currently mounted, unmount it first.
Code:
umount /dev/block/mmcblk0p2
mkdir /system/sd
You can also format the partition now if you didn't specify the partition type during the partition creation.
Code:
busybox mke2fs -m0 -b4096 /dev/block/mmcblk0p2
Now mount the extended data partition.
Code:
mount -t ext2 /dev/block/mmcblk0p2 /system/sd
We'll still need to be able to access the original data partition now and later, so, prepare the mount point and mount it as well.
Code:
mkdir /system/internal
mount -t yaffs2 /dev/block/mtdblock4 /system/internal
At this stage, you'll need to copy over all files inside the original /data directory to your new sd directory. You'll also need to make sure that the permissions isn't changed during the process. To do this, just tar the entire original data directory to your new one.
Code:
cd /system/internal
busybox tar -cvf /system/sd/old-data.tar *
cd /system/sd
busybox tar -xvf old-data.tar
busybox rm old-data.tar
The initialization for the new data directory mounting in the boot process does not modifies the boot image's init.rc. Thus, it seems that the initialization process is called after the radio initialization. I can't get my GSM to work without this step. We'll need to symbolic-link back the /system/sd/radio directory to the original internal storage /data/radio directory. And remember that on the boot process, we'll need to mount /system/internal *before* /system/sd.
Code:
cd /system/sd
busybox rm -rf radio
ln -s /system/internal/radio /system/sd/radio
After fiddling for several hours, I realized that the date and time settings gets reset on each boot. Fixed by symlinking the /data/date.time back to the internal storage.
Code:
cd /system/sd
busybox rm -rf date.time
ln -s /system/internal/date.time /system/sd/date.time
5) Prepare the boot init script
---------
The Froyo boot process runs init.rc script, which is replaced by the boot.img when system boots. So we can't put our new /data directory mount commands there, unless we extract, unpack, modify, repack the boot.img. Ok so I decided that modifying boot.img will be the last step if I can't get it working without it. There must be an easier way!
Also, there aren't any rc.d, rc3.d, bla bla directory in which we can put our custom initialization script.
Luckily, there is a script that is called from the init.rc script during boot, which is stored on the root filesystem and can be customized. It's called /system/etc/install-recovery.sh. Thus, we'll put the initialization script there. If you already got a /system/etc/install-recovery.sh, you can just add our initialization script in the beginning of the. Alternatively, you can create a separate script to perform init, and call it from your modified /system/etc/install-recovery.sh.
There will be drawback, for example, it seems that the script is called after radio initialization, so we'll need to use the old /data/radio directory from the original /data directory, prepared on step (4).
So now you'll need to create (or copy) the install-recovery.sh script. You can use vi from the busybox, or easier is to just copy and paste the install-recovery.sh script provided in this post. In case you're a vi expert, fire up these commands. Don't forget to remount the root filesystem as rw first!
Code:
busybox vi /system/etc/install-recovery.sh
Write in the install-recovery.sh script:
Code:
#!/system/bin/sh
mount -t yaffs2 /dev/block/mtdblock4 /system/internal
mount -t ext2 /dev/block/mmcblk0p2 /system/sd
mount -o bind /system/sd /data
Don't forget to set executable and readable attribute at least for root user, or else the system can't run the script!
Code:
chmod 755 /system/etc/install-recovery.sh
So now you're ready to reboot the system. Double check the install-recovery.sh script, make sure all commands mounts the partition exactly to where you intend it.
6) Reboot your Ideos S7!
---------
Reboot and enjoy the trendemous increase on your internal tablet storage
WARNING!!! Do not attempt to perform factory data reset while running with /data mounted. It seems that S7 will format the /data partition as yaffs2, not sure as I haven't checked it. But it worth to try to change the install-recovery.sh script to mount the data partition as yaffs2, and then performing factory data reset.
Sorry I can't post either an image or attachment yet
Click to expand...
Click to collapse
can you make a video about how increase the internal memory? i trying but at final step after restart my ideos nothing happens, or screenshots, please i have 4 for weeks looking for a solution about the low memory on my ideos, i install joenilan rom but dont like me the launcher, please and sorry for my bad english.
This is one good tutorial that I missed
Sent from my Ideos S7 using XDA App
HELP
Hi, i followed the steps, and my ideos keep looping at the ideos start screen
is there anything i can do?
zonyman said:
Hi, i followed the steps, and my ideos keep looping at the ideos start screen
is there anything i can do?
Click to expand...
Click to collapse
Reflash with new program,search it ..
My way !
My device : Huawei S7-105
Another way to increse internal memory :
1 flash with stock rom 2.2.2 norvegian
2 flash trizetmod v3
3 with MiniTool Partition Wizard Home Edition i've made 3 partitions on internal memory ( s7-105 using mass storage options )
- 1.2 Gb fat32
- 6 Gb ext4
- 157 Mb swap linux partition
This was one of many attempts to increase memory , and at the end i was happy with that result ! I think that you can make your own partitions , as you wish ! I have seen many movies on youtube .
Most important thing to remember : first you create fat32 partition and make it primary , second is ext4 partition also primary and the last swap partition !
After you create the partitions , reboot in recovery and make a factory reset , and your S7 has 6Gb program memory !!!!!!
Another important thing : I am a newbie in " Android world " , so I do not know how correct is what I did but one thing is certain : I HAVE 5.28 Gb and I got rid of that annoying message LOW MEMORY !!!!!!
I hope I posted in the right place , so i ask an admin to check ! Thx
in summary of this post..
all you have to do is to backup ur current rom via cwm by goodane..
make a 2nd primary partition formatted ext2/ext4 (for ext2 supports 2GB or less.. ext4 for 2GB or higher)
flash trizet's v3 rom
-THE END :good:
Hello guys!
I have a Huawei Ideos S7 Slim too,
Specifications
- Model: Huawei Ideos S7 Slim
- Version: 202u
- Intermal memory: 160 mb
I'm trying to do the steps to increase the internal memory
I don't getting success with the process
I wonder if the process works with the model Huawei Ideos S7 Slim 202u
Thank you

External card as ext2?

Can I have external card mounted as ext2? I have files names not supported by fat and sync'ed with dropbox
Yes, you can but afaik there is no easy way to do this.
I formatted my sdcard to ext2 (because I wanted to put large file (image for wikipedia offline) on my sdcard).
I formatted the beginning (~30MB) of my sdcard to fat32 so that the Nook detect the sdcard and does not trigger an error and the remaining part to ext2.
Then I used a script that mount manually the ext2 partition to /sdcard on boot.
This generally works but I have sometimes a few bug in some applications, especially when I connect and disconnect my Nook to my computer...
The best solution would be to find a way so that Android can automount a ext2 partition by itself but I don't know how to do it.
Instead of using the whole card I partitioned the first 4gb as fat16 (msdos) and then set the rest to ext3. When the fat16 space runs out I'll look into making some sort of script to try to mount the second partition. At the moment with the card acts like a normal 4gb card.
is it possible to repartition the nook to be able to use the space that b&n reserves for its contents? I heard that the space for our files is just 250 mb.
user4242 said:
is it possible to repartition the nook to be able to use the space that b&n reserves for its contents? I heard that the space for our files is just 250 mb.
Click to expand...
Click to collapse
yes of course. If you're used to linux repartitioning and the dd command then it's a breeze. If you're a Windows user who've never done partitioning or disk imaging then you can easily mess up.
I'll assume the former.
It's just a case of:
boot with a noogie.img that you've written to a sdcard (root of card, not partition 1)
then plug it in
now you can see all the nook partitions like it's an external USB drive and fdisk, cfdisk, partitionmagic or whatever you want
Obviously you're gonna want to backup first because if you mess up the only way to restore would be asking one of us off this forum to break the distribution laws and send you a 2gb (or whatever it is) image.
All the details on this forum
Has someone tried editing /system/etc/vold.conf to get a ext-formated SD-Card mounted?
mali100 said:
Has someone tried editing /system/etc/vold.conf to get a ext-formated SD-Card mounted?
Click to expand...
Click to collapse
I checked, I had modified it adding a line "partition 2" in the section "volume_sdcard2" so that Android does not show the message "SD card blank or has unsupported filesystem".
But I couldn't make it mount a ext2 sdcard itself. (if you know how to do it without using another script, I'm interested)
Time to resurrect this thread.
FAT is ugly. File timestamps are in local time (whatever that means, summer? winter?).
The Nook vfat implementation has problems with caching in and out directory info on vfat
and intermittently changes all the modify timestamps by 1, 4 or 5 hours.
This can play havoc if you are trying to keep things synchronized by filetime.
I've decided to have my SD card be ext3
Our volume demon, /system/bin/vold (which is ancient) uses /system/etc/vold.conf to configure automounting.
It presumes that all volumes are vfat.
It seems from a brief look inside that it does handle ext2 and ext3 somehow.
There is also the question of getting it to automount USB drives.
The easiest solution to ext3 on the SD card is to make it non-removable.
First, delete the second section out of vold.conf that relates to the SD card.
Then edit init.rc:
Code:
mkdir /sdcard 0777 system system
...
mount ext3 /dev/block/mmcblk1p1 /sdcard nosuid nodev noatime nodiratime uid=1000,gid=1015,fmask=117,dmask=007
chown system sdcard_rw /sdcard
chmod 0770 /sdcard
If you feel like having 12 partitions on your SD card you can.
That leaves vold only handling the mounting of /media
This exists so that you can serve /media as USB Mass Storage.
You could have /media be a fixed mount by doing what you just did to the SD card.
The only hiccup there would be the Adobe Digital Editions wants to see /media as UMS.
Note: To edit init.rc, download bootutil from the signature, extract, edit and replace init.rc in uRamdisk.
Make sure that you have a backup and a recovery!
Note: All of the above changes to init.rc are wrong.
I can get it to mount in a shell, but not in init.rc
Whoops.
Oops, this thread has been forgotten.
Yes, auto-mounting ext3 SDcards has been solved.
See: http://forum.xda-developers.com/showthread.php?t=2184495

Help missing 13gb data - nexus 7

Okay so i was just doing a bit of file management. I removed a 1.4gb psp iso i had on my nexus 7 and then i checked how much space i had left using storage option in settings. I checked it and it said i had 25gb free when before i removed my file i had only 13gb free. Tried rebooting device and then used es file explorer to see all files. Opened es file explorer and then noticed everything was gone. Only stock items were folders were left eg Android, Download etc. All my msuic and some game data was gone. Opened up asphalt 7 to see if it would still work but it doesnt anymore. Tried opening real racing 3 And it asks me to redownload game data. My widgets are still in homescreen and work and some of the other apps i have still work as well eg plague inc, subway surfer and most of the other ones.
Any idea on how this happened and how i can recover my files? I have a bugsense file as well that was left on my device.
As to recovery of lost files your options are not good. (And if we're talking a non-rooted device, the odds are approximately equal to 0%) Recovery in ext4 filesystems is technically much more challenging than in simple filesystems such as FAT. And this pessimistic outlook presumes that the filesystem is healthy/clean. If the reason for the problem occurring in the first place was a corrupted filesystem, then the odds go from simply bad to pathetically poor.
Sorry, dude... got any Nandroid or TiBu backups stored on your PC?
If you had Putin's top-secret files on your N7 and the CIA got hold of it, the first thing a forensic analyst would do is try to take a raw (block) device dump off of the "cold" device. (If you are still running the N7 with the regular OS the /data partition is being continually written to, and this further reduces the chances of file recovery every second the device is booted).
In the case of an analyst with less resources, this might mean using a custom recovery boot to get the raw device copy; unfortunately, the /data partition is huge - nearly 30 GB - so you would have to mount a extN filesystem via OTG... and doing so thus precludes using adb, so you would need to use a recovery with a touch interface and command-line entry (e.g. TWRP)
# mkdir /mnt/myOTGdisk
# mount -t ext2 -o rw /dev/sda1 /mnt/myOTGdisk/
# dd bs=8196 if=/dev/block/platform/sdhci-tegra.3/by-name/UDA of=/mnt/myOTGdisk/userdata.img
Doing such a thing would allow you to examine that huge image file with forensic file recovery tools from a PC (probably running Linux) as in principle you captured the entire ext4 filesystem.
The thing is, efforts spent in file recovery should be proportional to the value of the files being recovered. I'm not sure if your saved gaming history rises to that occasion. For sure the dude at the CIA won't want to help you with that.
As to the source of your troubles, it's hard to say. With TWRP booted, you can run the "e2fsck" program to see if the /data ext4 filesystem is corrupted, e.g.
# mount | grep /data ( see which mmcblk0 partition is /data, on grouper it is mmcblk0p9 )
# umount /sdcard
# umount /data
# e2fsck -f -n /dev/block/platform/sdhci-tegra.3/by-name/UDA
(For the last command above, you might need to use the block device name /dev/block/mmcblk0p?? instead of the UDA symlink )
If the above command shows that you have a corrupted /data filesystem, I would re-initialize that filesystem ( "fastboot format userdata" ) - note this wipes all userdata including the psuedo-SD card.
Finally, I should point out that some type of hardware failure might have occurred somewhere in that huge 30 GB partition - if that is the case then there will be problems down the road again. If that is the case, the only way to detect this will be a write test which nearly fills that partition, followed by a filesystem sanity check as shown above.
Probably that would need to be done in the recovery rather than in the normal OS, as a nearly full /data filesystem will probably wedge the device.
Phew, I've said enough.
Good luck
I never tire of reading your posts, bftb0, ("...the odds are approximately equal to 0%")...genius.
But don't the CIA have access to Cray, 'Kasparov' DeepBlue beating SuperComputers that could make mincemeat out of the kind of thing your alluding to... in less time than it takes to flash a ROM... or have I been watching too many James Bond movies?
Vaguely rhetorical question - think I already know the answer...
Still... what a great post.
Rgrds,
Ged.
---------- Post added at 01:22 AM ---------- Previous post was at 12:50 AM ----------
Hi, leont1280...
You could try running this ...
Disk Usage - http://play.google.com/store/apps/details?id=com.google.android.diskusage&hl=en
It gives a graphical 'map' or overview of your storage, and you can visually see where everything is (or should be), great for tracking down missing stuff... but as bftb0 has mentioned, it doesn't look promising.
Rgrds,
Ged.
Use astro file manager u can check it out
Sent from my Nexus 7 using Tapatalk 2
Right bftb0 i did what you said in twrp and i recieved the following summary information.
/dev/block/mmcblk0p10: 28133/1835008 files (3.2% non-contiguous) , 1571673/733977
Any idea on what that means?
Also under the mount option in Twrp i can Unmount and mount the System, Data and its Cache. However i cant Mount the SD Card. Should that be a concern?
bftb0 said:
As to recovery of lost files your options are not good. (And if we're talking a non-rooted device, the odds are approximately equal to 0%) Recovery in ext4 filesystems is technically much more challenging than in simple filesystems such as FAT. And this pessimistic outlook presumes that the filesystem is healthy/clean. If the reason for the problem occurring in the first place was a corrupted filesystem, then the odds go from simply bad to pathetically poor.
Sorry, dude... got any Nandroid or TiBu backups stored on your PC?
If you had Putin's top-secret files on your N7 and the CIA got hold of it, the first thing a forensic analyst would do is try to take a raw (block) device dump off of the "cold" device. (If you are still running the N7 with the regular OS the /data partition is being continually written to, and this further reduces the chances of file recovery every second the device is booted).
In the case of an analyst with less resources, this might mean using a custom recovery boot to get the raw device copy; unfortunately, the /data partition is huge - nearly 30 GB - so you would have to mount a extN filesystem via OTG... and doing so thus precludes using adb, so you would need to use a recovery with a touch interface and command-line entry (e.g. TWRP)
# mkdir /mnt/myOTGdisk
# mount -t ext2 -o rw /dev/sda1 /mnt/myOTGdisk/
# dd bs=8196 if=/dev/block/platform/sdhci-tegra.3/by-name/UDA of=/mnt/myOTGdisk/userdata.img
Doing such a thing would allow you to examine that huge image file with forensic file recovery tools from a PC (probably running Linux) as in principle you captured the entire ext4 filesystem.
The thing is, efforts spent in file recovery should be proportional to the value of the files being recovered. I'm not sure if your saved gaming history rises to that occasion. For sure the dude at the CIA won't want to help you with that.
As to the source of your troubles, it's hard to say. With TWRP booted, you can run the "e2fsck" program to see if the /data ext4 filesystem is corrupted, e.g.
# mount | grep /data ( see which mmcblk0 partition is /data, on grouper it is mmcblk0p9 )
# umount /sdcard
# umount /data
# e2fsck -f -n /dev/block/platform/sdhci-tegra.3/by-name/UDA
(For the last command above, you might need to use the block device name /dev/block/mmcblk0p?? instead of the UDA symlink )
If the above command shows that you have a corrupted /data filesystem, I would re-initialize that filesystem ( "fastboot format userdata" ) - note this wipes all userdata including the psuedo-SD card.
Finally, I should point out that some type of hardware failure might have occurred somewhere in that huge 30 GB partition - if that is the case then there will be problems down the road again. If that is the case, the only way to detect this will be a write test which nearly fills that partition, followed by a filesystem sanity check as shown above.
Probably that would need to be done in the recovery rather than in the normal OS, as a nearly full /data filesystem will probably wedge the device.
Phew, I've said enough.
Good luck
Click to expand...
Click to collapse
Right bftb0 i did what you said in twrp and i recieved the following summary information.
/dev/block/mmcblk0p10: 28133/1835008 files (3.2% non-contiguous) , 1571673/733977
Any idea on what that means?
Also under the mount option in Twrp i can Unmount and mount the System, Data and its Cache. However i cant Mount the SD Card. Should that be a concern?
leont1280 said:
Right bftb0 i did what you said in twrp and i recieved the following summary information.
/dev/block/mmcblk0p10: 28133/1835008 files (3.2% non-contiguous) , 1571673/733977
Click to expand...
Click to collapse
Hmmm, mmcblk0p10 - you must have a tilapia (3G N7) device, yes?
If you had any filesystem errors, that e2fsck run would have produced copious reams of output. If a filesystem is clean, it produces only 5 or 6 lines of summary output.
leont1280 said:
Any idea on what that means?
Also under the mount option in Twrp i can Unmount and mount the System, Data and its Cache. However i cant Mount the SD Card. Should that be a concern?
Click to expand...
Click to collapse
I've seen the same business with TWRP and the /sdcard mount - I wouldn't worry about it. (It is not a "normal" mount in the sense of extN or FAT device partition mount - it behaves sort of like a strange symlink where the target directory and descendants all appear to have different file ownership and permissions than what exist in the true (underlying) filesystem. No doubt this is all performed in the kernel... I don't know whether a command-line invocation of "mount" can create this mount point, or whether a specific syscall/ ioctl is needed)
But back to your N7 - the lack of any errors in the filesystem check is good news, but also suggests that your files didn't disappear through a hardware failure. Are you sure you didn't fat-finger things when using the file manager? (I suppose it is possible that the file manager has a bug...)
I didn't look into what tools are available for extN forensic/recovery work. I can guess that the effort would be non-trivial, though.
bftb0 said:
Hmmm, mmcblk0p10 - you must have a tilapia (3G N7) device, yes?
If you had any filesystem errors, that e2fsck run would have produced copious reams of output. If a filesystem is clean, it produces only 5 or 6 lines of summary output.
I've seen the same business with TWRP and the /sdcard mount - I wouldn't worry about it. (It is not a "normal" mount in the sense of extN or FAT device partition mount - it behaves sort of like a strange symlink where the target directory and descendants all appear to have different file ownership and permissions than what exist in the true (underlying) filesystem. No doubt this is all performed in the kernel... I don't know whether a command-line invocation of "mount" can create this mount point, or whether a specific syscall/ ioctl is needed)
But back to your N7 - the lack of any errors in the filesystem check is good news, but also suggests that your files didn't disappear through a hardware failure. Are you sure you didn't fat-finger things when using the file manager? (I suppose it is possible that the file manager has a bug...)
I didn't look into what tools are available for extN forensic/recovery work. I can guess that the effort would be non-trivial, though.
Click to expand...
Click to collapse
Im pretty sure i didnt accidently delete it myself. When i was doing file management i was using my laptop with the N7 3g connected to it via MTP. Once i deleted the iso file the N7 started acting strange. I did notice a bit of lag that was usually out lf the ordinary and when i checked available space left it increased to 25gb rather than saying 13gb
aaah, having the same problem here, i was cleaning my n7 using my laptop, found a strange folder on my sd card, looked inside and it has a back up of some of my deleted files! interesting! i deleted the folder, then i started cheking other folders, like my ebooks, audio books and etc, but all my folders were empty!
so i disconnected my tablet, and after reconnecting, bam, all files gone.

[MOD][EMMC][I9070/P][8/16GB] Internal Memory Repartition

Internal Memory Repartition
Hey guys, after a very long time I show you the way to repartition your internal memory (EMMC).
You can modify partitions as you want, increase data partition to install more apps, increase internal storage for media files...
It's based on a little Linux binary called Parted, it's a part of CWM/TWRP recovery ramdisk.
This means that you can repartition in any recovery of any 4.2/4.3/4.4 ROM.
==========WARNING==========
Operations on EMMC partitions could be EXTREMELY DANGEROUS if you don't understand well what you do.
If you touch wrong partitions (CSPSA, EFS, SBLs...) you can lose your IMEI or hardbrick your device (in this case only JTAG can save you) so...
READ CAREFULLY!!!!!
Responsibility is all yours, but if you follow well this guide you will not risk anything.
Stock partition table is designed to be used in stock ROM, since it uses preload partition to store some system apps and needs bigger system (ROM is heavier than CM-based ones) and bigger cache partitions (more system apps=more dalvik-cache).
This mod is compatible with any ROM except stock and stock-based.
This is the stock partition table:
{
"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"
}
You can touch ONLY:
Kernel2
SYSTEM
DATAFS
CACHEFS
HIDDEN
FOTA
UMS
Kernel2 is the backup of stock kernel, we don't need it.
SYSTEM is the /system partition (where the ROM is installed/stored).
DATAFS is /data partition (default 1.97 GB where are stored installed apps, Android settings, contacts, messages... User data).
CACHEFS is /cache partition (art/dalvik-cache is stored here, together with recovery logs/temporary files. In stock ROM here is stored also CSC. If you repartition to the minimum (at least 5 MB needed for recovery) you need to put dalvik.vm.dexopt.data-only=1 flag in system/build.prop
HIDDEN is /preload partition (some Samsung TouchWiz system apps are stored here and symlinked with /system/app. This is a swap partition on MIUI v5, CM10.2 and all CM11/Omni 4.4 builds (these 4.4 before 15 June), also every custom ROM based on Canjica device tree 4.3/4.4 (always before 15 June), resize it to the minimum (128 KB to format it as EXT2).
FOTA is Firmware Over The Air, so is needed to get OTA updates while on stock ROM, can be directly deleted.
UMS is the internal storage (3.96 GB one), you can repartition this to have less/more space, or repartition to the minimum (8 MB or less, you will need to swap internal/external storages).
Parted commands useful for us:
rm (to delete a partition)
mkpart primary (to make a partition)
format (to format a partition, only in ext2)
name (to rename a partition)
For an extended list/explanation of commands, type "help" without quotes
Let's go!
First make a nandroid backup of your current ROM, to be restored after repartition
If you touch UMS you will lose all the content of /sdcard (internal storage), so make a backup first!
You need a Linux distro or Windows with ADB configured.
Reboot device in recovery and connect to USB, then open ADB and write:
Code:
adb shell
parted /dev/block/mmcblk0
You can choose to display partitions as Gigabytes, Megabytes, Kilobytes (suggested), or Bytes by "unit **" command, where ** can be gb/mb/kb or b
Now type "print" to display partition table.
Parted create new partitions by following "Number", for example SYSTEM is 3, CACHEFS is 4 and DATAFS is 5 (for other partitions is the same), so when you create new partitions, you need to make them in order!! For example:
SYSTEM is 3 and its size is from 105906KB to 747635KB
CACHEFS is 4 and its size is from 2895118KB to 3215983KB
DATAFS is 5 and its size is from 747635KB to 2895118KB
The "end" of a partition is the "start" of the next partition
As you can see, DATAFS is between SYSTEM and CACHEFS. This means that after you create SYSTEM, you need to calculate new DATAFS size that you want and then first create CACHEFS (at the end of calculated DATAFS size) then create DATAFS from the end of SYSTEM to the start of CACHEFS.
To understand more:
We will resize now CACHEFS from 320864 KB to 5000 KB gaining 315864 KB for DATAFS:
Unmount /cache from recovery first!
Code:
rm 4 (to delete CACHEFS)
rm 5 (to delete DATAFS)
calculate now the new size of DATAFS, in this case add 315864 KB to DATAFS end: 2895118+315864=3210982 KB
calculate now the new end of CACHEFS, in this case add 5000 KB to 3210982 KB: 3210982+5000=3260982 KB
mkpart primary 3210982 (end of DATAFS and start of CACHEFS) 3260982 (end of CACHEFS, start of the next partition)
Now we made a new partition, its number is 4. Do: name 4 CACHEFS
It's time to make new DATAFS partition: from the end of SYSTEM to the start of CACHEFS
mkpart primary 747635 (end of SYSTEM and start of DATAFS) 3210982 (end of DATAFS and start of CACHEFS)
New partition has number 5, name it DATAFS by name 5 DATAFS
Basically the method is this, you can apply it to partitions listed above.
Remember to reboot recovery, go in Mounts and storage then (depending on what partitions you touched in Parted, excluding /preload) do the appropriate formats after repartition. Now you're ready to restore your nandroid backup (needs to have less size than new partitions) or install a ROM.
I suggest an useful program to check partition size on Android, Partition Table
If you touch HIDDEN partition and you are on 4.2 ROM or 4.4 builds after 15 June:
Code:
format
y
9
ext2
If you repartition UMS to the minimum, you will need to swap internal and external storages (MicroSD card will be the new internal storage):
On 4.2 open system/etc/vold.fstab and replace the content with this:
Code:
# MicroSD as internal storage
dev_mount sdcard0 /storage/sdcard0 auto /devices/sdi0/mmc_host/mmc1/mmc1
# UMS as external storage
dev_mount sdcard1 /storage/sdcard1 8 /devices/sdi2/mmc_host/mmc0/mmc0 nonremovable,encryptable
# usbdisk
dev_mount usbdisk0 /storage/usbdisk0 auto /devices/platform/msm_hsusb_host.0
On 4.3 ROMs open system/build.prop and add these lines at the end of the file:
Code:
persist.sys.vold.switchexternal=1
ro.vold.switchablepair=/storage/sdcard0,/storage/sdcard1
On 4.4 ROMs just open NovaThor Settings and enable "Swap Storages"
To restore original partition table flash stock ROM through Odin with "Repartition" enabled and correct PIT file for your model, in attachment (extract zip), soon CHN pits too
I know that it's difficult to understand well the first times, but think at me that I developed this method, a lot of testing and bricks on bricks
If you found this useful, you can support me at least by pressing "Thanks" or considering to offer me a beer, a coffee... Any kind of support will be very appreciated ​
Reserved for "The PIT Zone" (soon available!)
Reserved
Another reserved just in case!!
So, I want to shrink UMS (let's say by 1GB) and use it in DATAFS.
What would be the command sequence?
Thank you,
Tasos
tasosf said:
So, I want to shrink UMS (let's say by 1GB) and use it in DATAFS.
What would be the command sequence?
Thank you,
Tasos
Click to expand...
Click to collapse
All what you should know it's wrote in the OP.
You can make our way... rm anything after Kernel2, calculate datafs+1024MB more and make again all partitions, name and format them. Read again and well the OP for clarifications, it's all wrote there
Inviato dal mio GT-I9505
I didnt found any info about it in OP so i ask:
Every partition made using this guide will be formatted as ext2? Ext2 is worse than ext4 so probably it will affect performance, am i right about it?
Command "format" didnt work for me
Instead i used "mkfs <number> ext2" (however it asks about number and filesystem later) and i think "mkpartfs primary ext2 <start> <end>" could be the easiest as it create partition and format it in the same moment so its not needed to remember later
ch3mn3y said:
Command "format" didnt work for me
Instead i used "mkfs <number> ext2" (however it asks about number and filesystem later) and i think "mkpartfs primary ext2 <start> <end>" could be the easiest as it create partition and format it in the same moment so its not needed to remember later
Click to expand...
Click to collapse
Format didn't work for me either. I formatted everything through TWRP to ext4.
So, this method works! I now have 3GB for data so to have all the apps installed in the internal storage and not the internal sd card (ums). This way all apps are faster because ums is formatted as fat 32 in order to be recognised on Windows.
One tricky thing was that you have to mkpart from low numbers to high, regardless if you leave for a moment organ intermediate megabytes. The system always gives the next available number to the partition you make. It may not make sense how I try to explain it, but keep it in mind when you try it.
Sent from my GT-I9070 using XDA Free mobile app
I do exactly opposite thing as made smaller DATAFS, SYSTEM and CACHEFS to have bigger UMS. Its googd that Kernel2, HIDDEN and Fota are after "more" important partitions, so we can get rid of them and get lot of space
tasosf said:
The system always gives the next available number to the partition you make. It may not make sense how I try to explain it, but keep it in mind when you try it.
Click to expand...
Click to collapse
Yep, its important to not make mistakes, coz who wants to do something few times?
ch3mn3y said:
I do exactly opposite thing as made smaller DATAFS, SYSTEM and CACHEFS to have bigger UMS. Its googd that Kernel2, HIDDEN and Fota are after "more" important partitions, so we can get rid of them and get lot of space
Click to expand...
Click to collapse
How come you want to have bigger UMS? Not all apps can be installed there and DATAFS gets full very easily. Also, it's fat32 which creates some problems by itself.
Sent from my GT-I9070 using XDA Free mobile app
I just dont use this phone as my primary and as i have xplay for games i dont need to have lots of apps on it. Additionaly i have only 4gb sdcard for it, so my internal memory is now bigger than external
Sent using TF300T - CyanogenMod 11.0/GRIMLOCK (F2FS)
i'd really like to repartition my phone's memory but i fear i'm gonna screw everything up
i see a coming soon "pit zone" in the second post, does that mean that there is an automatic way to repartition the internal memory without directly using commands?
If u knows how to make pit file after repartitioning its probably possible to use odin to repartition
Sent using GT-i9070 - VanirAOSP
You need to use "format" command in ext2 only for HIDDEN partition that it's unneeded on custom ROMs.
For other partitions (SYSTEM, CACHEFS, DATAFS) format through recovery mode (automatically formatted in ext4), and for UMS through Android.
Yes, the PIT zone will have PIT files ready to be flashed to autorepartition along with a kernel that brings you CWM recovery to install/restore your ROM after repartition.
Inviato dal mio GT-I9505
AntaresOne said:
You need to use "format" command in ext2 only for HIDDEN partition that it's unneeded on custom ROMs.
For other partitions (SYSTEM, CACHEFS, DATAFS) format through recovery mode (automatically formatted in ext4), and for UMS through Android.
Yes, the PIT zone will have PIT files ready to be flashed to autorepartition along with a kernel that brings you CWM recovery to install/restore your ROM after repartition.
Inviato dal mio GT-I9505
Click to expand...
Click to collapse
i will definitely wait for the pit files then all i'm looking for is to get rid of those useless partitions like FOTA, Kernel2 etc. just to have more space on the internal memory for apps
TheSteve87 said:
i will definitely wait for the pit files then all i'm looking for is to get rid of those useless partitions like FOTA, Kernel2 etc. just to have more space on the internal memory for apps
Click to expand...
Click to collapse
Completely agree mate. Also HIDDEN, you don't need it on CM/CM-based custom ROMs
Inviato dal mio GT-I9505
I really have to say this guide is just A-W-E-S-O-M-E
The process is not that easy but very well explained
A complicated by well explained method for partition........But i am a bit afraid to use .... Can u help out with the step for my issue...?
My Phone: S Advance
(Rooted with the help of http://forum.xda-developers.com/showthread.php?t=2087424)
RAM= 768 MB RAM,
ROM= 2 GB //*Note phone shows this as device storage, Pl correct if I am wrong*//
Internal=16 GB (user available=11.31 GB), //*Note phone shows this as USB storage, Pl correct if I am wrong*//
external micro SD card = Nil
I want to increase the RAM Or ROM so that my mobile should not lags/hangs
I feel that mobile is slow mainly due to less RAM......pl correct if I am wrong
I want to use the the 1GB/2GB/3GB/4GB out of Internal 16 GB to increase the size of ROM from 2GB to 3GB/4GB or RAM from 768 MB to 1GB/2GB/3GB/4GB more.....
Pl help me out with the specific steps.....
Thanks a lot @AntaresOne
@anil.xda
Yes, just 768 MB of RAM is one of the biggest performance limiting factors of this phone but sadly you can't just "increase it". You'll have to use something like a zRAM or a SWAP script. But this is just a workaround - and it too has some drawbacks I think.
Sent from my GT-I9070

Categories

Resources