Related
I have managed to natively boot Urokdroid's OS in my Archos-70 device. This means that I don't need to go to the boot loader menu and select Developer to boot into my SD card which contains my Android OS. Upon power-up or reboot without pressing the volume -, I can have rooted Android OS.
First and foremost I'd like to give credits to where credits are due. I'd like to thank $aur0n for his excellent work on allowing us to boot our Archos device to external SD card. This has paved the way for many enhancements that we have now, and soon to come. I'd also like to give thanks to apr24991 for discovering a way to always boot in Developer mode. This has given me a chance to tweak my OS and allow Urokdroid's kernel to boot natively. And for all those generous people here who have willingly share their knowledge in this forum, I appreciate all your work. Now it's time for me to share what I've learned.
I'm no expert of Linux or Android. This was just based on my experience and there may be better ways to do this. Having said that, I just want to lay out some precautions.
Be prepare to lose data. So as preparation, please back-up your data.
Don't blame me if you brick your device. I would say that instructions here are easy enough for those knowledgeable in linux. However there may be few cases that you don't get the expected results. In any case, you can still restore your original Android OS by going to recovery menu and applying the stock 2.0.71 firmware from Archos.
This works on my A70, and I cannot guarantee that it will also work on A101 and other Gen8 devices. I'm suspecting it will.
After applying this successfully, you will lose the capability to dual boot. Meaning you will only be able to boot in SDE mode with rooted Android. Again you can still restore the stock firmware in the recovery menu.
Pre-requisites
Please download the SDE firmware from here. You can also download the stock 2.0.71 firmware in case you want to recover your original OS.
You should have already installed Urokdroid's kernel & this is properly working on your Archos device. In other words, you are already running Android on external SD card. $aur0n has setup a comprehensive guide here. The guide here is based on 0.3 version of Urokdroid's kernel.
Steps
Warning. On this step, you will lose all data in your device but excluding contents of external SD card. Please backup important data before continuing. Apply SDE into your Archos following phase 1 of apr24991's post here. This method will actually erase your stock Android firmware and only the SDE (AngStrom) will be present. So whenever you power on or reboot,
it will always boot AngStrom.
Now the trick now is to modify the kernel & initramfs of SDE so it will boot into external SD which contains your Android OS.
Insert your external SD card into your device.
Go to recovery menu. Press volume - while powering on.
Chose Developer Menu from the Recovery Menu.
Select flash kernel & initramfs.
Attach the device to your PC via USB. Your device will now appear as mass storage device in your PC. Copy 0.3 zImage from Urokdroid's, and the modified initramfs.cpio.gz, attached in this post (Extact it from the zip file first). This is the same initramfs.cpio.gz as Urokdroid's except I've modified /init to disable the checking of squasfs file in mmcblk0p2.
Safely unmount your device from your PC. Afterwards, select ok in your device. This would apply the copied zImage and initramfs.cpio.gz. And then it will prompt you that it will boot the device. Press power
button to reboot.
If everything is ok, you will now always be booted into Urokdroid's Android OS, rooted, and able to do other things. If you wish to restore stock firmware from Archos, just go to recovery menu and apply the firmware version you want. You may follow phase 2 of apr24991's post
here and just use your desired firmware version (2.0.54 or 2.0.71).
So far my setup is stable.
Optional: If you look at /data.old (mmcblk0p4), there is no longer data there. You have additional 300MB of partition where you can setup swap space.
Why?
You can remove the Android (Original Archos Android - not the SD-One!) in the Developer Menu in the Recovery - so no need to flash a special modified initramfs?!
Or am I missing something?
As I've mentioned, I'm no expert on Linux or Android. I've just laid out what I did. I did a lot of trial and error. If I did not flash a modified initramfs it will always boot AngStrom. What I want is to always boot on rooted Android in SD. The only thing I modified from Uruk's initramfs is to bypass the checking of squash file in /dev/mmcblk0p1. Since we reformat the device, the squash file in /dev/mmcblk0p1 has been erased. The only way to bring it back is either copy from backup or reapply the stock firmware.
I have also managed to boot a rooted Android using the built-in mmcblk0p2, mmcblk0p4 block devices. When I got to AngStrom, I just copied a backup of squash file to mmcblk0p2, and backup of data to mmcblk0p4, and then flash the kernel & initramfs from this thread. My only problem here is I'm limited to 300MB for apps.
There may be more efficient ways to do this, and if you have suggestions that will achieve the same results I'll be happy to include them in this guide.
I think I did it in a different order but it still worked.
1- SDE
2- New kernel
3- Remove "Andriod" from recovery
I liked this way since I knew the new kernel booted before I erased Archos's.
xnatex21 said:
I think I did it in a different order but it still worked.
1- SDE
2- New kernel
3- Remove "Andriod" from recovery
I liked this way since I knew the new kernel booted before I erased Archos's.
Click to expand...
Click to collapse
That works for sure and is the simplest way I know of.
A possible dangerous, scary way?
Thinking out loud here... but
the archos/sde bootloader is mounted by Uruk in /mnt/rawfs (currently the permissions seem to prevent write access)
rawfs contains, among other things, a file called 'custom' (which is a copy of the zImage and initramfs.cpio.gz flashed under developer edition menu and packaged together) and 'avboot', which looks to be the archos kernel/loader.
Does anyone else think it might be possible to rename custom->avboot and avboot->custom to swap both the behavior of the bootmenu and default boot around? Rooted android booting by default, stock android boots when developer edition is selected?
Ok so is there a way now that we can move the sdcard android files over to the system as a re-write-able system?
sent from epic 4g
There isn't enough space where the stock android is atm (mmcblk0)
I have put Uruk onto the internal storage (mmcblk1) because my sdcard is slow and rubbish.
so how big is the file? cant we just edited and delete some junk apps to make it enough?
I think it's possible to use mmcblk0p4 as storage for root fs. It has 300MB of space. The other partitions are too small. I'm not sure if it's possible to consolidate mmblk0 to 1 partition, but i've managed to convert mmcblk0p4 to ext4.
Update:
I consolidated mmcblk0p2, mmcblk0p3 and mmcblk0p4 into 1 ext4 partition. It's about 450MB. I put the rootfs here and use 2GB of internal storage as /data partition.
Code:
# mount
mount
rootfs on / type rootfs (rw)
/dev/mmcblk0p2 on / type ext4 (rw,noatime,barrier=1,nodelalloc,data=ordered)
/dev/mmcblk1p2 on /data type ext4 (rw,noatime,barrier=1,nodelalloc,data=ordered)
tmpfs on /dev type tmpfs (rw,mode=755)
devpts on /dev/pts type devpts (rw,mode=600)
proc on /proc type proc (rw)
sysfs on /sys type sysfs (rw)
usbfs on /proc/bus/usb type usbfs (rw,devuid=1000,busuid=1000,listuid=1000)
debugfs on /sys/kernel/debug type debugfs (rw)
tmpfs on /mnt/asec type tmpfs (rw,mode=755,gid=1000)
/dev/block/mmcblk0p1 on /mnt/rawfs type rawfs (rw)
tmpfs on /dev/shm type tmpfs (rw)
/dev/block/vold/179:9 on /mnt/storage type vfat (rw,dirsync,nosuid,nodev,noexec,noatime,nodiratime,uid=1000,gid=1015,fma
sk=0000,dmask=0000,allow_utime=0022,codepage=cp437,iocharset=iso8859-1,utf8,errors=remount-ro)
/dev/block/vold/179:9 on /mnt/secure/asec type vfat (rw,dirsync,nosuid,nodev,noexec,noatime,nodiratime,uid=1000,gid=1015
,fmask=0000,dmask=0000,allow_utime=0022,codepage=cp437,iocharset=iso8859-1,utf8,errors=remount-ro)
tmpfs on /mnt/storage/.android_secure type tmpfs (ro,size=0k,mode=000)
/dev/block/mmcblk2p1 on /mnt/storage/sdcard type vfat (rw,nosuid,nodev,noexec,noatime,nodiratime,uid=1000,gid=1015,fmask
=0000,dmask=0000,allow_utime=0022,codepage=cp437,iocharset=iso8859-1,utf8,errors=remount-ro)
fusesmb on /mnt/storage/network/smb type fuse (rw,nosuid,nodev,user_id=0,group_id=0,allow_other,max_read=32768)
djmount on /mnt/storage/network/upnp type fuse (ro,nosuid,nodev,user_id=0,group_id=0,allow_other)
# df -h
df -h
Filesystem Size Used Avail Use% Mounted on
rootfs 448M 313M 112M 74% /
/dev/mmcblk0p2 448M 313M 112M 74% /
/dev/mmcblk1p2 2.0G 268M 1.6G 15% /data
tmpfs 120M 12K 120M 1% /dev
tmpfs 120M 0 120M 0% /mnt/asec
/dev/block/mmcblk0p1 32M 13M 20M 40% /mnt/rawfs
tmpfs 120M 4.0K 120M 1% /dev/shm
/dev/block/vold/179:9
4.6G 464M 4.1G 11% /mnt/storage
/dev/block/vold/179:9
4.6G 464M 4.1G 11% /mnt/secure/asec
/dev/block/mmcblk2p1 1.4G 4.0K 1.4G 1% /mnt/storage/sdcard
fusesmb 448M 313M 112M 74% /mnt/storage/network/smb
#
As a newer Archos buyer, I'm very happy about this info. I'd like to get some additional info tho. Firstly, you consolidated mmcblk0p2, mmcblk0p3, and mmcblk0p4 into a 400MB part for the rootfs. Were you unable to consolidate mmcblk0p1 in as well?
Secondly, you allocated 2GB of internal storage for /data, but what do you use this for? Also, this leaves you about 5GB of internal storage (as the internal storage shows approx. 7GB on my stock 101IT)? And, you're able to utilize your entire SD for storage data, as opposed to booting and keeping your OS here?
Thirdly, do you think, if necessary this could be rolled back to stock? Would a flash back to the stock ROM package restore the original partition table? The only reason I ask this, is that I've been considering selling this in a short while, when the verdict comes in on which tablets will get Gingerbread updates. Also, the pontential performance gains on a Viewsonic GTablet with it's Tegra2 based chipset intrigue me (I hadn't heard of this device when I chose my 101IT), and with it's horsepower, I think it might be a surer bet for Gingerbread love. But, if I sell it, I'd like to give my buyer an option to recieve a ROM'd/rooted or stock device depending on preference.
Lastly, as if I haven't asked enough already ;-) , could you provide detail on how one could replicate your processes? I imagine you'd start with installing SDE on your storage card to have root access to the mmcblk0 devices and install the new kernel to the consolidated mmcblk0 partition? Are there any other steps that one would need follow?
If you've read this far, thanks much for your patience and assistance!
As a newer Archos buyer, I'm very happy about this info. I'd like to get some additional info tho. Firstly, you consolidated mmcblk0p2, mmcblk0p3, and mmcblk0p4 into a 400MB part for the rootfs. Were you unable to consolidate mmcblk0p1 in as well?
Click to expand...
Click to collapse
I didn't try to include mmcblk0p1 since the boot process is still accessing this partition. One access i've seen is the flash image at boot up is taken from this partition. There may be more. So to be safe, i've excluded this partition.
Secondly, you allocated 2GB of internal storage for /data, but what do you use this for? Also, this leaves you about 5GB of internal storage (as the internal storage shows approx. 7GB on my stock 101IT)? And, you're able to utilize your entire SD for storage data, as opposed to booting and keeping your OS here?
Click to expand...
Click to collapse
/data is used to be mounted to mmcblk0p4 which has about 300MB of space. I've transferred this to internal storage with 2GB, which allows me for more apps to be installed. In the internal storage, I've allocated 4.5GB as vfat (/sdcard), 2GB as ext4 (/data), and 500MB as swap.
Thirdly, do you think, if necessary this could be rolled back to stock?
Click to expand...
Click to collapse
You can always go to recovery menu, and reformat the device. This will repartition the internal storage, and install a stock firmware. This, however, will erase all your data in the internal storage.
Lastly, as if I haven't asked enough already ;-) , could you provide detail on how one could replicate your processes?
Click to expand...
Click to collapse
I'll back trace my steps later, and post them here.
Here are the steps I did to use mmcblk0p1 as rootfs and a partition in mmcblk1 (internal storage).
I assume you are already on Urukdroid's kernel running on external SD.
Partitioning Internal Storage
1) I first partitioned the internal storage. To partition without destroying existing data, I used GParted from Ubuntu desktop. Connect Archos to PC running Ubuntu via USB. Mount the USB Mass Storage. A70S will appear as one of drive in Ubuntu.
2) Open GParted and select the device for the Archos internal storage. You will see 1 fat32 partition labeled A70S. Unmount the partition. Upon unmounting, you will be able to resize the partition. In my case, I put 2500 free space after the partition.
3) After resizing, I have 2500MB free space. I created 2 primary unformatted partitions, 2GB (/data), and the last one 500 (swap). After this, apply the changes in GParted.
4) Afterwards, from linux command line I formatted the 2 partitions using the following command:
Code:
mkfs.ext4 -O ^huge_file -L data /dev/sdb2
mkswap /dev/sdb3
5) Unmount USB from Archos.
Partitioning System Storage
6) Use adb shell. Unmount /dev/block/mmcblk0p4, /dev/block/mmcblk0p3, /dev/block/mmcblk0p2, /dev/block/mmcblk0p1. Using fdisk, delete partitions 2, 3, 4 from /dev/block/mmcblk0, then create 1 partition utilizing the rest of the disk space. This will give you about 450MB, that you can use as root.
7) format the partition.
Code:
mkfs.ext4 -O ^huge_file -L root /dev/block/mmcblk0p2
Copying files to the created partition
8) I mount /dev/block/mmcblk0p2 to /tmp/root, /dev/block/mmcblk1p2 to /tmp/data
Code:
mkdir /tmp/root
mkdir /tmp/data
mount -t ext4 /dev/block/mmcblk0p2
mount -t ext4 /dev/block/mmcblk1p2
8) I grabbed Urukdroid's 0.4 rootfs.tgz, and extract them mmcblk0p2.
Code:
cd /tmp/root
tar zxvf /sdcard/rootfs.tgz
9) Since 0.4 already contains Gapps, I've uninstalled Gapps first on my archos.
10) I copied the data files
Code:
cp -a /data/* /tmp/data/.
11) I modified /tmp/root/init.rc and comment out mounting /mnt/system, /cache & /data. I've attached my modified init.rc.
12) Unmount /tmp/data, and /tmp/root.
Apply kernerl & modified initramfs
13) I then rebooted to recovery, on Developer Edition Menu, flash new kernel & initramfs. Use zImage, and modified initramfs.cpio.gz which I have attached here. The modification I did in initramfs is use mmcblk0p2 as root and mmcblk1p2 as data, and if it finds /dev/mmcblk1p3 (assuming mkswap has already been applied) use it as swap.
Hope this helps.
Will this work on the 101 too?
Sent from my A101IT using Tapatalk
hexto said:
Will this work on the 101 too?
Click to expand...
Click to collapse
Also curious about this
Thanks for your walkthrough! I greatly appreciate it. I'm testing this on my 101IT now. However, I seem to be boot-looping (Archos Entertainment your way screen flashes on, off, and on repeatedly). However, for the first boot of the Urukdroid kernel, it took a significant amount of time as well. I'm going to give it a few, and if there's no change, I'll retry. I may have made a mistake someplace causing this issue, so I'll see what I can dig up.
nmyron said:
Thanks for your walkthrough! I greatly appreciate it. I'm testing this on my 101IT now. However, I seem to be boot-looping (Archos Entertainment your way screen flashes on, off, and on repeatedly). However, for the first boot of the Urukdroid kernel, it took a significant amount of time as well. I'm going to give it a few, and if there's no change, I'll retry. I may have made a mistake someplace causing this issue, so I'll see what I can dig up.
Click to expand...
Click to collapse
Are you following the guide from the 1st post or from the 13th post? What version of Urukdroid kernel are you using?
I was totally incorrect. When I boot with the dev edition option, I'm booting off the two internal partitions. To be honest, when I made that first post, I had been at work all night, then did this, and just didn't think to check "mount" in the terminal to see the result.
However, it's performing somewhat sluggishly. I'm unsure what's going on there. I'm going to look at some things and see what might be going on. But, the tutorial was spot on.
Is there a way to force it to boot Dev Edition (so it boots this OS) automatically upon logon?
Edit: And, I'm running the Urukdroid 0.4.1 currently, I just downloaded the latest before I began this process
On recovery menu, select Developer Edition, then select delete android's kernel. After this you'll always boot in Developer mode.
________________________________
Sent from my GT-I9000 using Tapatalk
... And you would've thought that I'd have noticed that, being all the in/out of that menu I've done in the last two days...
As far as the sluggishness goes, it seems to be mostly directly after boot. After about 2 minutes, it fades, and performance improves drastically. I'm guessing it ties mostly to swappiness, and the system making initial use/caching data.
You have no idea how much of an amazing help this walkthrough has been. Just a little messing around with the file system, and moving things around, and now it's just cooking along, running an internally booted os with root access... Great work here!
1. I've installed ICS passion on my phone and am unable to install Google plus.
I keep getting an insufficient space error (see attachment), but all my partitions seem to have a healthy chunk of free space.
Code:
/dev/block/mtdblock2 250.0M 206.6M 43.4M 83% /system
/dev/block/mtdblock3 17.5M 2.3M 15.2M 13% /cache
/dev/block/mtdblock5 16.0M 14.3M 1.7M 89% /radio
/dev/block/mmcblk0p2 1.8G 880.0M 1009.8M 47% /data
/dev/block/mtdblock6 172.0M 98.2M 73.8M 57% /datadata
/dev/block/mtdblock4 12.5M 6.6M 5.9M 53% /efs
/dev/block/vold/179:9
7.4G 1.3G 6.1G 18% /mnt/emmc
/dev/block/vold/179:1
12.8G 9.0G 3.8G 70% /mnt/sdcard
I haven't run in to issues installing other apps.
2. I have a large number of apps installed on my phone and as a result ran out of space in /datadata. I moved a few of the larger directoreis to /data/data2 and symlinked the directory to /datadata. Is this the usual way to deal with running out of space in /datadata?
Thanks!
I have noticed in the past that google+ takes A LOT of space for some reason (when I noticed that, it was well over 200MB - more than 2x what you show as available in datadata)
I usually install/restore and then immediately move it to SD when I flash a new rom, although that doesn't really help your current situation.
Not sure why the XDA app won't let me edit my previous post to add a picture, but whatever.
after thinking about this for a while, I think that perhaps the large space requirement was a result of G+ and the automatic picture uploading feature.
I could be wrong, but it does reserve a lot of space over and above what any of my other apps take.
Sent from my SGH-T959 using xda premium
Figured it out. I had a symlink in /datadata for the google+ app to /data. This was tripping up market.
Removing the symlink fixed the issue.
Thanks for helping.
K, time to give this a proper OP, if anyone wants any of the info that was here before you can look here
_________________________________________________________________________________________________
So, the whole idea here started with me reading an article on how part of the whole I/O problem with the transformer is partially caused by the hardware used as internal storage. I wanted to find out if this had any merit and I figured the best way to do it would be to "replace" the internal storage. I did this by mounting the /data partition to the exteral SD (which according to my research, my specific SD Card is better at writing speeds - allegedly the main problem with the transformer's internal storage hardware wise). Then I ran a bunch of benchmarks and have been running it that way for about 24 hours and so far it feels great. Anyone is welcome to give it a try, and hopefully with help, suggestions and feedback from the community, we can all take as much advantage of this idea as possible.
Before I go any further I want to give credit to those who helped me so far, because without them I would still be completely clueless, and not only have they helped be accomplishing what I got so far, but thanks to them I've also learned a bunch of things I didn't know before. So here it goes:
Rayman - For suggesting the method for mounting /data to the external SD.
lilstevie - For helping me get the new kernel flashed right.
Turge - For showing me how to properly repack the kernel.
Parastie - For suggesting doing the same thing to /cache (working on that now).
dagrim1 - For SQL patch and for suggesting a temporary remount (even though it didn't work it was a good thing to try).
_motley - For all his work on his awesome kernel.
_________________________________________________________________________________________________
Updates:
Update 1 (08-01-2012 File boot-data+cache+internal-AOKP6.1base.zip) :
Now both /data and /cache are moved to the external SD card. This means you need a third partition mmcblk1p3 in order to use this modification.
It will also mount the internal storage (previously inaccessible) to /mnt/sdcard_internal
It also attempts to (fail at this point) to mount the internal sd partition (what used to be /sdcard) to /sdcard/Internal_SD (which is why you will always see that folder get created but stay empty). If anybody knows how to make it work please advise.
Modified Lines:
init.cardhu.rc
Code:
# TweakerL MOD > original mount = mmcblk0p8 /data | mmcblk0p3 /cache
mount ext4 /dev/block/mmcblk1p2 /data wait noatime nodiratime nosuid nodev nodelalloc,errors=panic
mount ext4 /dev/block/mmcblk1p3 /cache wait noatime nodiratime nosuid nodev nodelalloc,errors=panic
# TweakerL MOD > added mounts for internal storage
mkdir /mnt/sdcard_internal 0000 system system
mount ext4 /dev/block/mmcblk0p8 /mnt/sdcard_internal wait noatime nodiratime nosuid nodev nodelalloc,errors=panic
# TweakerL MOD > give access to internal SD from /sdcard
mkdir /data/media/Internal_SD 0755 media_rw media_rw
mount /mnt/sdcard_internal/media /data/media/Internal_SD wait noatime nodiratime nosuid nodev nodelalloc,errors=panic
Update 2 (08-01-2012 About backing up/restoring in recovery) : - READ UPDATE 5
One thing that worried me was that by using this mod people wouldn't be able to backup their data partition properly, but now I know that it's possible to do it. It will only work on TWRP though since it has basic terminal access and keyboard. To do it, go into Advanced > Terminal and in there type:
umount /dev/block/mmcblk0p8
mount /dev/block/mmcblk1p2 /data
And until you reboot, any backup/restore should use the external SD data partition instead of the internal. The same should be doable with the cache partition in case you want to backup/restore that.
Update 3 (08-02-2012 File flashme-kernel-motley305-aokp-data+cache2SD.zip) :
Put together a flashable zip that will install motley's 3.0.5 aokp kernel using this mod. Works like a charm so far though I only tried flashing on TWRP. Also, internal storage can be accessed in /data2 and internal sd can be accessed in /sdcardi . Current changes are as follow:
Code:
# TweakerL MOD > move /data and /cache to external SD card || original mount = mmcblk0p8 /data | mmcblk0p3 /cache
mount ext4 /dev/block/mmcblk1p2 /data wait noatime nodiratime nosuid nodev nodelalloc,errors=panic
mount ext4 /dev/block/mmcblk1p3 /cache wait noatime nodiratime nosuid nodev nodelalloc,errors=panic
# TweakerL MOD > create mount for internal storage
mkdir /data2 0000 system system
mount ext4 /dev/block/mmcblk0p8 /data2 wait noatime nodiratime nosuid nodev nodelalloc,errors=panic
# TweakerL MOD > symlink internal sd to a couple of easily accessible locations
symlink /data2/media /mnt/sdcard_internal
symlink /data2/media /sdcardi
Update 4 (08-03-2012 File boot-cm10-unofficial-data+internal.zip) :
Running the unofficial CM10 (no cherrypicks one) using this mod and so far it's pretty amazing. The rom itself is pretty stable and even snappier with /data mounted to external SD. Benchmarks are at the bottom. Current modifications:
fstab.cardhu:
Code:
#TweakerL MOD > Move /data to external SD and internal /data to /data2
/dev/block/mmcblk1p2 /data ext4 rw,nosuid,nodev,noatime,user_xattr,acl,barrier=1,journal_async_commit,nodelalloc,data=writeback wait
/dev/block/mmcblk0p8 /data2 ext4 rw,nosuid,nodev,noatime,user_xattr,acl,barrier=1,journal_async_commit,nodelalloc,data=writeback wait
init.cardhu.rc:
Code:
# TweakerL MOD > create mount for internal storage
mkdir /data2 0000 system system
mount_all /fstab.cardhu
# TweakerL MOD > symlink internal sd to a couple of easily accessible locations
symlink /data2/media /mnt/sdcard_internal
symlink /data2/media /sdcardi
Update 5 (08-03-2012 About backing up/restoring in recovery) :
So after doing some tests, and paying more attention to TWRP, I noticed something rather useful:
When you have this mod enabled, or whenever you have a mmcblk1p2 partiion, TWRP will have the sd-ext menu enabled. This means that to backup your data you can simply backup the sd-ext partition and to restore your data you can simply restore your sd-ext partition. No need to worry about manually switching the mount point for /data in recovery. I guess it was a whole lot easier than I thought.
Also congratulations and thanks to everyone who has contributed with this so far.
WE MADE IT TO FRONT PAGE ON XDA (08-03-2012)
_________________________________________________________________________________________________
Requirements:
There are a few things you will need to do in order for this to work right for you, and a couple of things you'll have to research before you even try it.
#1. Obviously, you have to be rooted/unlocked because you're not gonna be able to change much around otherwise.
#2. You MUST repartition your external SD. The kernel I've put together so far WILL ONLY mount /data to mmcblk1p2, which basically says "mount /data to the second partition in the external SD." also, the ramdisk expects that partition to be ext4, so essentially:
Make sure you have an external SD with at least two partitions and that the second partition is formatted to ext4. I personally use Gparted to repartition my stuff, but feel free to use whatever rocks your boat. Even if you're on windows you can still use gparted by using virtualbox, so I'm not gonna go look for a different windows solution.
#3. This is the research part... This will be beneficial or detrimental to each user depending on the SD card used. If you have a slow SD card this probably will do you no good. However, just because you have a class 10 SD card, that doesn't mean it will benefit you either. On my own research I have found that some class 6-10 SD Cards have extremely slow random write speeds, so if you happen to have one of those, even if it's a class 10, this might not be for you. This means that you're gonna have to do some research to find out if your SD Card will benefit you or not. You can always just give it a try, as far as I know this is entirely reversible, how easy or hard being just a matter of how bad you mess up on meeting the requirements and following the instructions.
#4. At this point (07-30-2012) I'm doing all this stuff using the AOKP milestone 6.1 kernel as base for my modified kernel, so if you're not using AOKP milestone 6.1, flashing my kernel might borke your system. You've been warned, feel free to proceed otherwise at your own peril.
_____________________________________________________________________________________________________________
Installation:
#1. Download attached file (boot-data2SD-AOKP6.1base.zip) and extract it to the root of your internal storage (/sdcard).
#2. Open a terminal.
#3. Type the following:
Code:
su
dd if=/sdcard/boot.blob of=dev/block/mmcblk0p4 bs=1
#4. Wait for it to complete.
#5. Reboot.
Upon rebooting you will know that it worked because it will look just as if you just flashed a new rom, that is, you'll get the device setup screen (assuming that the tablet booted at all lol). If you're planning to use TB to restore your apps, you'll probably want to copy the TB folder to your external SD's first partition so that you can copy it back once you're done with the device setup (at this point you will have no access - unless you manually mount it - to your internal storage).
_______________________________________________________________________________________
Reverting:
Follow the same exact steps for installation but use boot-default-AOKP6.1.zip instead.
_______________________________________________________________________________________
Optional:
#1. If you want to have access to everything you had on your data partition in the new data partition, you'll have to clone everything from one to the other. To do this, make sure that your new data partition (the one in your external SD) has enough storage space to fit everything you currently have in your data partition (the one in your internal storage). Then run the following command in your terminal.
Code:
dd if=dev/block/mmcblk0p8 of=dev/block/mmcblk1p2 bs=4096 conv=notrunc,noerror
BEWARE that if you have a lot of stuff this can take quite a while and even though I've read a way of getting the progress for this in Linux I'm not sure that you can check the progress on Android.
_______________________________________________________________________________________
Next steps in development:
#1. Move /cache as well.
#2. Find out what happens with recovery backups when the partitions are changed.
#3. Attempt to apply mod to motley's kernel.
#4. Create a script that is run on boot to eliminate need for replacing the kernel.
#5. With help from the community, find the best SD Card for this.
#6. Run the modified system for a while to have a good feel for performance benefits
#7. Come up with other interesting uses for this other than getting better I/O (maybe an easy - kinda easy - way to dual boot with ubuntu, maybe other stuff, dunno).
_______________________________________________________________________________________
How can I set my kernel to do this?
I didn't do a whole lot, and it's not like I want it to be a secret, so as I modify things I'll try to keep the steps listed here so that anyone modifying their own kernel who would like to try this modification can go ahead and do it.
You'll need to know how to unpack/repack a kernel. Turge has a SUPER EASY explanation here on how to do it on windows (I'll pack together the necessary binaries for linux later, maybe).
Mount /data to the second partition in your external SD (formatted as ext4 filesystem):
After unpacking the kernel navigate to the folder that has the ramdisk and open it
(DON'T USE ANY ASCII BASED TEXT EDITOR BECAUSE IT WILL PROBABLY MESS THINGS UP I USE NOTEPAD++)
Around line 26 change:
Code:
mount ext4 /dev/block/mmcblk0p8 /data wait noatime nodiratime nosuid nodev nodelalloc,errors=panic
to
Code:
mount ext4 /dev/block/mmcblk1p2 /data wait noatime nodiratime nosuid nodev nodelalloc,errors=panic
_______________________________________________________________________________________________________
SD Cards tested:
Samsung 32GB Class 10 MicroSDHC High Speed Memory Card - Very Good Results
SanDisk® microSDHCTM 8GB Memory Card - Very Good Results
"Either way, with this mod, the tablet feels like it should have right from the start. It's speedy and responsive, and apps being installed don't stall the system." - Turge - Post #59
_______________________________________________________________________________________________________
Benchmarks:
/data mounted to mmcblk0p8 (Internal Storage):
{
"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"
}
/data mounted to mmcblk1p2 (External SD):
RL Benchmark WITHOUT dagrim1's sql patch as per request:
/data mounted to mmcblk0p8 (Internal Storage):
/data mounted to mmcblk1p2 (External SD):
*Important thing to note: When running the benchmark with data in the internal SD it was about 220 seconds in the first run, then about 180, then about 130 and finally 118; whereas running it from the external SD was consistenly between 63 and 65 seconds every time. I think this more than proves that A) Asus used a cheap I/O storage, B) No matter what software changes are made, more than likely running the rw partitions from a better I/O storage, i.e. an external SD is a good idea.
As promised here are benchmarks on a JB rom (Unofficial CM10). Also sorry it took me a while to get these, I was going to use eos3 but I started getting random reboots. Then I decided to try cm10, and I messed up a flash and had to redo a bunch of things. Anyway, the only change here is the mod itself (no custom kernel or anything). Though one thing to note is that I moved /cache back to the internal partition after some thought that this allows /data and /cache to be written at the same time to different locations thus lowering the bottleneck.
/data mounted to mmcblk0p8 (internal storage):
/data mounted to mmcblk1p2 (external storage):
Now, as you can see, JB did bring a major improvement to I/O, bringing the benchmark down from about 115sec to 68 (almost reaching the modded ICS at 60 seconds). But as I expected, better software works better on better hardware and now the modded JB is running at 50 seconds instead of 60. Next I'm going to put dagrim1's sql patch and see how low the benchmark goes. Also will be posting the modded blob in just a little bit for anyone who wants to use it on CM10.
We don't have sd-ext it's an old trick when phones had very little /data partitions, you have the possibility to create a sd-ext partition on an external sdcard and mounting it as a secondary data. (like opt partition on Linux).
To see what block device is data just run 'mount' command in terminal emulator. I don't have my device here.
sdcard cache is already set to 2048 if I'm correct.
Your script would mean creating a sd-ext partition on an external sdcard, modify fstab to have it correctly mounted then applying the script.
Not really easy for common users.
I would rather look at kernel drivers (not I/O schedulers but drivers handling with file system format) but it's quite a hard work.
Hmmm...
Was talking to Rayman and it doesn't actually seem that hard to do... Just gotta change the init.cardhu.rc in the ramdisk to mount /data to /dev/block/mmcblk1p2 instead of /dev/block/mmcblk0p8
The thing is, that while I know every step that I have to take to get it done, I haven't used linux in forever and quite honestly I couldn't even compile blobtools right now if I wanted to to extract the ramdisk from the boot blob to make the necessary change... so yea anyone who knows how to edit a kernel should be able to do it, and then just repack it as a blob... I'll probably look into it later, but if anyone wants to type the terminal commands for to to get/compile blobtools I'll appreciate it...
As in just a mount of data to mmcblk1p2?
Would a temp solution (just to check if it works) be to remount data manually? (Tried it, to mmcblk1p1 btw since 1p2 didn't seem to exist for me, but it still mounts to mmcblk0p8.
Using:
mount -o remount,rw -t ext4 /dev/block/mmcblk1p1 /data
(as su in terminal)
dagrim1 said:
As in just a mount of data to mmcblk1p2?
Would a temp solution (just to check if it works) be to remount data manually? (Tried it, to mmcblk1p1 btw since 1p2 didn't seem to exist for me, but it still mounts to mmcblk0p8.
Using:
mount -o remount,rw -t ext4 /dev/block/mmcblk1p1 /data
(as su in terminal)
Click to expand...
Click to collapse
Reason why mmcblk1p2 didn't work is because you have to repartition the sd card to have an ext4 partition... personally what I did was take my 32gb sd card and have the first partition as a fat32 partition for storage and set the rest to an ext4 partition... also, you have to do that because the /data partition is already expected to be an ext4 partition on most of the current ROMs... Trying to set it without doing that most likely won't work.
Also, another thing that's important is that for this to be beneficial you have to have an SD Card with higher random write speed than your internal storage speed... my internal storage speed is about .25 mb/s and my sdcard is about 1.5mb/s so there should be a big difference... Oh and if you happen to have a class 10 sdcard that doesn't necessary mean that it has high random write speed... you actually have to go look up the specs or run benchmarks on it.
TweakerL said:
Reason why mmcblk1p2 didn't work is because you have to repartition the sd card to have an ext4 partition... personally what I did was take my 32gb sd card and have the first partition as a fat32 partition for storage and set the rest to an ext4 partition... also, you have to do that because the /data partition is already expected to be an ext4 partition on most of the current ROMs... Trying to set it without doing that most likely won't work.
Also, another thing that's important is that for this to be beneficial you have to have an SD Card with higher random write speed than your internal storage speed... my internal storage speed is about .25 mb/s and my sdcard is about 1.5mb/s so there should be a big difference... Oh and if you happen to have a class 10 sdcard that doesn't necessary mean that it has high random write speed... you actually have to go look up the specs or run benchmarks on it.
Click to expand...
Click to collapse
Thanks, makes sense yeah... will have to check if it's worth the hassle for now. Not at this moment anyway, but interesting concept...
Stuck... again...
So I figured how to unpack the boot.blob, then unpack the boot.blob.LNX, then decompress the ramdisk... made the necessary change to init.cardhu.rc... compressed the ramdisk to the same format it was before, repacked the boot.blob.LNX, repacked the boot.blob... dd if=blob of=dev/block/mmcblk0p4 seek=28 bs=1 ... and ... nothing... reboot and where you're supposed to get the quick progress bar nothing seems to happen... I'm assuming I messed up on the recompressing ramdisk/packing the boot.blob... but I'm not sure how...
Anyway... I'll post exactly how I did it tomorrow so maybe someone with more experience can help me figure out where I messed up...
But so far, I wanna say thanks to rayman and lilstevie for all the help they've given me so far with this idea.
TweakerL said:
... compressed the ramdisk to the same format it was before, repacked the boot.blob.LNX, repacked the boot.blob... dd if=blob of=dev/block/mmcblk0p4 seek=28 bs=1 ...
Click to expand...
Click to collapse
Just wondering, why did you choose to use seek=28?
I believe the TFP will need the first 28 header signature to be there in order to flash through the staging paritition (p4).
Your other option would be to flash using fastboot:
1. If you've installed the AndroidRoot.mobi bootloader (if you have nvflash), then you can directly flash the boot.blob.LNX file, as this is a raw image.
fastboot -i 0x0b05 flash boot boot.blob.LNX
2. If you don't have AndroidRoot.mobi bootloader, then I suggest you get NVFlash working first and get a backup... if not, you can use the following to flash the blob:
fastboot -i 0x0b05 flash boot blobfileyou'vecreated
3. Use fastboot to flash to the staging partition:
fastboot -i 0x0b05 flash staging blobfileyou'vecreated
TweakerL said:
So I figured how to unpack the boot.blob, then unpack the boot.blob.LNX, then decompress the ramdisk... made the necessary change to init.cardhu.rc... compressed the ramdisk to the same format it was before, repacked the boot.blob.LNX, repacked the boot.blob... dd if=blob of=dev/block/mmcblk0p4 seek=28 bs=1 ... and ... nothing... reboot and where you're supposed to get the quick progress bar nothing seems to happen... I'm assuming I messed up on the recompressing ramdisk/packing the boot.blob... but I'm not sure how...
Anyway... I'll post exactly how I did it tomorrow so maybe someone with more experience can help me figure out where I messed up...
But so far, I wanna say thanks to rayman and lilstevie for all the help they've given me so far with this idea.
Click to expand...
Click to collapse
I've repacked the boot.img for the Prime before to add init.d support so I'll post my method and the files needed in a few minutes once I get to work. It'll involve getting cygwin installed (with Perl support I believe) if you're on Windows.
Would it be better to move cache and maybe dalvik cache (assuming the SD random read/write is faster then internal memory) ? Since you're only moving data and leaving cache on internal, that'll still hit the issues of having bad IO. Moving cache (which I believe would have more random access) I think would be better.
Thoughts?
dagrim1 said:
As in just a mount of data to mmcblk1p2?
Would a temp solution (just to check if it works) be to remount data manually? (Tried it, to mmcblk1p1 btw since 1p2 didn't seem to exist for me, but it still mounts to mmcblk0p8.
Using:
mount -o remount,rw -t ext4 /dev/block/mmcblk1p1 /data
(as su in terminal)
Click to expand...
Click to collapse
Thanks for the idea, I tried to do that but nothing seemed to happen (checking on file manager /data partition is still taking the same amount of space as it did before). It would've been a really good way of testing this whole thing though
kokopuphz said:
Just wondering, why did you choose to use seek=28?
I believe the TFP will need the first 28 header signature to be there in order to flash through the staging paritition (p4).
Your other option would be to flash using fastboot:
1. If you've installed the AndroidRoot.mobi bootloader (if you have nvflash), then you can directly flash the boot.blob.LNX file, as this is a raw image.
fastboot -i 0x0b05 flash boot boot.blob.LNX
2. If you don't have AndroidRoot.mobi bootloader, then I suggest you get NVFlash working first and get a backup... if not, you can use the following to flash the blob:
fastboot -i 0x0b05 flash boot blobfileyou'vecreated
3. Use fastboot to flash to the staging partition:
fastboot -i 0x0b05 flash staging blobfileyou'vecreated
Click to expand...
Click to collapse
I used seek=28 out of despair and by lilstevie's suggestions... dd with or without seek had the same exact result, the staging just ignoring the whole thing lol...
Sounds like a plan (flashing with fastboot)... I've got one dumb question though before I do that (and yea i've got nvflash setup and all the backups and stuff). How do I actually go about restoring the system with NVFLASH if I go and borke the system ? XD
Turge said:
I've repacked the boot.img for the Prime before to add init.d support so I'll post my method and the files needed in a few minutes once I get to work. It'll involve getting cygwin installed (with Perl support I believe) if you're on Windows.
Click to expand...
Click to collapse
That would be much appreciated, I don't mind steps for windows or linux, I'll go either way
Parastie said:
Would it be better to move cache and maybe dalvik cache (assuming the SD random read/write is faster then internal memory) ? Since you're only moving data and leaving cache on internal, that'll still hit the issues of having bad IO. Moving cache (which I believe would have more random access) I think would be better.
Thoughts?
Click to expand...
Click to collapse
I agree that moving the cache is a good idea, one of the main reasons why I'm testing with /data though is that it will be much easier to have solid evidence of whether this works or not that way since all the benchmark apps seem to benchmark on the /data partition. I know benchmarks aren't real world results, but if I can run benchmarks on the same partition and it's 5 times faster on the SD card than on the internal memory, I think it should mean something. After that, if there are positive results, I'm thinking of moving both /data and /cache partitions and run that way for a while to see how well it performs, and then to run with just the /cache moved and see how that performs.
Turge said:
I've repacked the boot.img for the Prime before to add init.d support so I'll post my method and the files needed in a few minutes once I get to work. It'll involve getting cygwin installed (with Perl support I believe) if you're on Windows.
Click to expand...
Click to collapse
Here are the steps for repacking the boot.img. Some involve running the commands via cygwin, others involve running them via the Windows Command Prompt.
The instructions for installing cygwin, extracting and repacking the boot.img were found here: http://www.freeyourandroid.com/guide/extract-edit-repack-boot-img-windows
Once you have setup cygwin, extract the attached files in a folder under your "home" folder in cygwin.
copy boot.blob to the same folder and run the following via the Windows Command Prompt to extract the boot.img from the boot.blob:
Code:
BlobUnpack.exe boot.blob
ren boot.blob.LNX boot.img
From the cygwin bash terminal window, switch to the same folder and run the following to extract the ramdisk from the boot.img:
Code:
./extractboot boot.img
You now have an out/ramdisk folder that contains the files you want to edit.
Once done, repack the ramdisk and kernel into boot_new.img with the following command (via cygwin once again):
Code:
./packboot
then from the Command Prompt repack boot_new.img into boot2.blob using the following:
Code:
blobpack -s boot2.blob LNX boot_new.img
You can now flash the boot.blob to the staging partition via a command in updater-script:
Code:
package_extract_file("/boot.blob", "/dev/block/mmcblk0p4");
or by using adb while in recovery/android:
Code:
dd if=/sdcard/boot2.blob of=/dev/block/mmcblk0p4
Did anyone think of running iotop? If we know what part of /data is contributing to the stalls, maybe an interesting idea would be to just mount that part of the tree on SD?
tyvm will get on it now, will report back any results
Sent from my Transformer Prime TF201 using Xparent SkyBlue Tapatalk 2
what's iotop?
Though regardless, the problem I'm trying to deal with is the fact that apparently, the storage hardware in the Prime has limited I/O capabilities, namely random write speeds, regardless of software. Because of this the stalls are at least partially caused by the "where" the /data is rather than the "content" in the /data.
Sent from my Transformer Prime TF201 using Xparent SkyBlue Tapatalk 2
TweakerL said:
what's iotop?
Click to expand...
Click to collapse
ffs. Why do I bother?
tshoulihane said:
ffs. Why do I bother?
Click to expand...
Click to collapse
You know, I can just google it, but the fact that you care enough to post your opinion but not enough to explain it is the kind of mentality that keeps people who could potentially contribute to the community from doing so because they have to go research all over the internet, possibly going through bad information, for something that might be very simple. Read a few posts up and you'll see the right kind of mindset. Turge could've just*given some halfassed response and sent me on a wild goose chase but instead he took the time to explain in a way that anyone with any amount of knowledge could understand...
And I hope that since you can't bother to give an useful response, that you can't bother wasting you "precious time" justifying and complaining about how people ask questions that they could just look for elsewhere...
Hi there, first time I write here and I probably have a lot to learn
However, a few days ago I accidently dropped by Galaxu SIII from my balcony. As a result both the screen and the touch is broken, the rest seems to work. So, of course I can connect the phone to my computer and gain access to those folders that are always monuted. However I wan't to get access to all files, like I did on the phone after I rooted it. It looks like USB debugging is off even though I was sure it was on, ADB refuses to see the phone anyway. I have tried many ideas, including remote connection to the phone, but all soloutions require to either enable USB debugging or open an app and that is exactly what I cannot do! So what can I do besides getting a new screen, which I don't want since I've already brought a new phone. Mostly I want to save my contacts and I cannot to that with Samsung KIES since I have CM11 on the phone. I really can't find any solution and I really hope somebody out there can help me!
//Oscar
SuperLarre said:
Hi there, first time I write here and I probably have a lot to learn
However, a few days ago I accidently dropped by Galaxu SIII from my balcony. As a result both the screen and the touch is broken, the rest seems to work. So, of course I can connect the phone to my computer and gain access to those folders that are always monuted. However I wan't to get access to all files, like I did on the phone after I rooted it. It looks like USB debugging is off even though I was sure it was on, ADB refuses to see the phone anyway. I have tried many ideas, including remote connection to the phone, but all soloutions require to either enable USB debugging or open an app and that is exactly what I cannot do! So what can I do besides getting a new screen, which I don't want since I've already brought a new phone. Mostly I want to save my contacts and I cannot to that with Samsung KIES since I have CM11 on the phone. I really can't find any solution and I really hope somebody out there can help me!
//Oscar
Click to expand...
Click to collapse
I suppose your files are not on the SD-Card? If they are just remove the card, but I'm pretty sure you wouldn't ask this question if it was that easy!!
broonage said:
I suppose your files are not on the SD-Card? If they are just remove the card, but I'm pretty sure you wouldn't ask this question if it was that easy!!
Click to expand...
Click to collapse
You're right, it isn't that easy!
SuperLarre said:
You're right, it isn't that easy!
Click to expand...
Click to collapse
You could try nandroid backup from recovery, maybe using an otg for watching what your're doing on a separate screen.
When all data is nandroided, you can try going trough the backup (the data section specially).
If the backup has several parts (ie, a b c d… ) you can "merge" them into a single file that could be opened with 7zip or winrar. Just open a DOS command prompt and:
type data.ext4.tar.a data.ext4.tar.b >> data.ext4.tar
Thats the example for 2 parts a and b.Then, after unpacking the tar, you could look into the data to get stuff. For example…
Sms & mms:
data/data/com.android.providers.telephony/databases
Contacts:
data/data/com.android.providers.contacts/databases
And a lot of other stuff. Note that you need something to read-edit ".db" files, like an sqlite editor.
Alternatively, if you're using a similar phone, with same manufacturer, a close android version (for example not gb 2.3 vs kk 4.4, but yes jb 4.1 vs jb 4.3), etc, then you could copy such addresses and paste them inside your new phone (crossing fingers and any other crossable bodypart) and you might get all that stuff back.
Good luck.
Put a blank SD (formatted as FAT32 or exFat) on the phone. It must be sized as the phone's internal memory size (16 or 32GB)
Set the phone in download mode. Flash Phil'z recovery with Odin.
Start the phone in recovery mode. Connect usb to computer and after 10-15 seconds ADB will be enabled.
/data is mounted by default (internal SD is stored inside /data).
Now mount the external SD:
enter adb shell and put:
Code:
mount /dev/block/mmcblk1p1 /external_sd
If any error appear, stop.
If nothing appeared, check that it was sucessfully mounted. Ensure that mmcblk0p12 and mmcblk1p1 are mounted as this!
Code:
mount
rootfs on / type rootfs (rw)
tmpfs on /dev type tmpfs (rw,nosuid,relatime,mode=755)
devpts on /dev/pts type devpts (rw,relatime,mode=600)
proc on /proc type proc (rw,relatime)
sysfs on /sys type sysfs (rw,relatime)
/dev/block/mmcblk0p8 on /cache type ext4 (rw,nodev,noatime,nodiratime,barrier=1,data=ordered)
/dev/block/mmcblk0p12 on /data type ext4 (rw,nodev,noatime,nodiratime,barrier=1,data=ordered)
/dev/block/mmcblk1p1 on /external_sd type exfat (rw,relatime,fmask=0000,dmask=0000,allow_utime=0022,codepage=cp437,iocharset=utf8,namecase=0,errors=remount-ro)
Now copy all the internal storage to the external SD:
Code:
mkdir /external_sd/intData; cd /data; tar cf - * | ( cd /external_sd/intData; tar xf -)
Take a breath and come 15 minutes later to see if it finished. It may take more if the device was nearly full.
After it comes back to shell (you see the # symbol again) it means it's over.
Now let's flush the filesystems and unmount the partitions :
Code:
cd /; sync; umount /external_sd; umount /data
Remove the battery and the sd card.
Put the SD on your computer...done!
- The internal SD is stored on /data/media.
- The app data is on /data/data.
- The apps are on /data/app
- Your contacts are stored on /data/data/databases/com.android.providers.contacts/contacts2.db.
Putting that DB file on the same place of other Android phone and rebooting after will restore your contacts. Or you can convert them to VCF:
http://askubuntu.com/questions/445997/how-to-convert-androids-contacts2-db-to-vcf
Good luck!
dabyd64 said:
Put a blank SD (formatted as FAT32 or exFat) on the phone. It must be sized as the phone's internal memory size (16 or 32GB)
Set the phone in download mode. Flash Phil'z recovery with Odin.
Start the phone in recovery mode. Connect usb to computer and after 10-15 seconds ADB will be enabled.
/data is mounted by default (internal SD is stored inside /data).
Now mount the external SD:
enter adb shell and put:
Code:
mount /dev/block/mmcblk1p1 /external_sd
If any error appear, stop.
If nothing appeared, check that it was sucessfully mounted. Ensure that mmcblk0p12 and mmcblk1p1 are mounted as this!
Code:
mount
rootfs on / type rootfs (rw)
tmpfs on /dev type tmpfs (rw,nosuid,relatime,mode=755)
devpts on /dev/pts type devpts (rw,relatime,mode=600)
proc on /proc type proc (rw,relatime)
sysfs on /sys type sysfs (rw,relatime)
/dev/block/mmcblk0p8 on /cache type ext4 (rw,nodev,noatime,nodiratime,barrier=1,data=ordered)
/dev/block/mmcblk0p12 on /data type ext4 (rw,nodev,noatime,nodiratime,barrier=1,data=ordered)
/dev/block/mmcblk1p1 on /external_sd type exfat (rw,relatime,fmask=0000,dmask=0000,allow_utime=0022,codepage=cp437,iocharset=utf8,namecase=0,errors=remount-ro)
Now copy all the internal storage to the external SD:
Code:
mkdir /external_sd/intData; cd /data; tar cf - * | ( cd /external_sd/intData; tar xf -)
Take a breath and come 15 minutes later to see if it finished. It may take more if the device was nearly full.
After it comes back to shell (you see the # symbol again) it means it's over.
Now let's flush the filesystems and unmount the partitions :
Code:
cd /; sync; umount /external_sd; umount /data
Remove the battery and the sd card.
Put the SD on your computer...done!
- The internal SD is stored on /data/media.
- The app data is on /data/data.
- The apps are on /data/app
- Your contacts are stored on /data/data/databases/com.android.providers.contacts/contacts2.db.
Putting that DB file on the same place of other Android phone and rebooting after will restore your contacts. Or you can convert them to VCF:
http://askubuntu.com/questions/445997/how-to-convert-androids-contacts2-db-to-vcf
Good luck!
Click to expand...
Click to collapse
Amazing answer, however during the first steps, could he be blocked? Due to not seeing the screen? Maybe I'm over complicating things.
I see various options for converting system apps <==> user apps and moving or linking some to SD. But I don't see a good general discussion of this. Also, I think my old phone needs a more hard core approach--probably one that trims down /system and reduces how much /system overlaps redundantly with updates on /data. So here goes...
First off, these solutions seem inadequate:
built-in apps2sd: it still fills up internal memory a lot.
s2e: an all-or-nothing approach for each category
free version of link2sd: cannot move-and-link app data, nor system apps
I've been fairly happy with link2sd, but it's still not radical enough for me. Can s2e be combined with it to reclaim even more space?
Assumptions about a stronger solution:
It will require root access.
It will break OTA (can this be turned off safely? can someone link to a good overview of problems/workarounds?)
It *might* require a fairly fast SD card (but still limited to an old phone's bus speeds, etc.) Note: I just bought a 32GB class 10 SDHC card (UHS-1 U3) for my s5360.
It might require one or two paid apps (hopefully not)
One of the most promising options I've seen is to convert system apps to user apps and then move-and-link them to SD. For the conversion step, do the following all do the same thing?
link2sd Plus (paid)
Titanium Backup Pro (paid)
System Tuner (paid) -- I've tried the free ones and move (and freeze) always fails.
app mover (free) http://forum.xda-developers.com/showthread.php?t=1999346
And are there rules of thumb for what can be safely converted?
EDIT: I just found this handy list--my guess is that any green or yellow Yes can be safely converted to a user app and even moved/linked to SD, but that red shouldn't, and think twice before uninstalling yellow :
http://wiki.cyanogenmod.org/w/Barebones#CM-10.1_App_list_.28WIP.29
Can apps that were moved to /data still be updated? I'd especially like to target outdated system apps that are have already been updated anyway and are thus running from /data anyway. My understanding is that 'moving' those to /data doesn't increase /data usage and doesn't reduce performance--just slightly reduces permissions--as long as I don't move/link them to SD.
lightningdude said:
In all seriousness, though, I'm not entirely sure the Link2SD has good implementation of this method. You might try Titanium Backup to convert system to user apps, then try linking it with Link2SD. It may still not work, but it'd be worth a shot, I suppose.
Furthermore, I always delete bloatware I'm not going to use with Titantium Backup. If I need to go back to stock for an OTA, I just flash the complete stock of whatever phone I'm on.
Click to expand...
Click to collapse
If this can all be done successfully, can the internal partitions then be resized? That is, if we safely shunt some of /system and /cache off to SD, can we then let /data steal some space from both? (My s5360 has this by default: /system 230MB, /cache 40MB, /data 197MB)
My old s5360 seems to get full almost immediately after flashing a cm11 rom (LolliKat) and minimal gapps onto it, although I plan to try again with a version of minimal gapps that installs to SD.
For that matter, can some ROMs be installed primarily to SD? I get the impression that that's how some dual-boot (multiROM) approaches work, but I don't really know.
I've also seen one guide for permanently mounting /system as read-write. I think I'd be ok with that (are the security concerns truly awful?), especially if it meant that system apps would update themselves in-place without impacting /data. But I'm guessing it's not that simple.
can't create /system/... Read-only file system
I found another cool feature of link2sd to "integrate update into system", removing it from data and eliminating the double use of space. The free version includes this feature, but unfortunately it always errors out for me:
`sh: [51]: can't create /system/app/Music.apk.t: Read-only file system`
I tried upgrading to link2sd Plus, since that's the version that includes a convert feature, which requires write access to /system:
C-Jon said:
One of the most promising options I've seen is to convert system apps to user apps and then move-and-link them to SD.
Click to expand...
Click to collapse
But that feature failed too, for the same reason. So I tried all of the following--granting each app superuser access for 10 minutes each time--and they also failed to successfully mount /system as RW:
X-plore - long press the / folder and choose System Shell, then enter `su` and `mount -o remount,rw /system /system`. It gives no error, but if I then immediately `cd system` and try to `mkdir xxzz` it gives an error: `can't create directory 'xxzz' : Read-only file system`. If I use the GUI, I can apparently create a folder under /system with no error, but if I browse up and come back, the folder is gone.
ES File Explorer (free version) - menu, Root Explorer, Mount R/W. I tried running it multiple times, setting both `/` and `/system` to RW. After doing this a couple times, `/` showed up as already RW, but `system` never did. I immediately retried link2sd Integrate--fails with same error.
mountsystemrorw - this app is dedicated to this one task, and when I click "MOUNT /system RW" it claims success ("Your system is now mounted RW!"); but it actually fails. (At least, link2sd Integrate and X-plore still give the same error/failures.)
AnExplorer - menu, Root. I don't see 'mount' options.
Has KitKat made it nearly impossible to mess with /system, even as root? Or am I doing something wrong?
Just in case, I tried re-running "recreate mount scripts" in link2sd, which had worked before, and this time it failed too! `can't create /system/etc/init.d/11link2sd: Read-only file system`. So maybe something has changed since I first installed link2sd. Hmm. I do see this in a thread on stack exchange, "Write access to the system partition is usually blocked by the kernel at boot." But "recreate mount scripts" worked before, *after* I'd flashed the current kernel (Kernel Bangprovn#1.zip) and ROM (LolliKat Stable 2.zip). That's how I got the ext4 partition working for link2sd in the first place.
I'm getting frustrated and don't want to have a big fight every time I want to integrate or convert an app. So I'm wondering just how feasible the following might be...
I've also seen one guide for permanently mounting /system as read-write. I think I'd be ok with that (are the security concerns truly awful?), especially if it meant that system apps would update themselves in-place without impacting /data.
Click to expand...
Click to collapse
I'm guessing they wouldn't simply self-update. But if I could easily run the Integrate step without this RW battle, that might be enough.
If it helps, here is my mount info:
Code:
cat /proc/mounts
rootfs / rootfs ro,noatime,nodiratime 0 0
tmpfs /dev tmpfs rw,seclabel,nosuid,relatime,mode=755 0 0
devpts /dev/pts devpts rw,seclabel,relatime,mode=600 0 0
proc /proc proc rw,noatime,nodiratime 0 0
sysfs /sys sysfs rw,seclabel,noatime,nodiratime 0 0
selinuxfs /sys/fs/selinux selinuxfs rw,noatime,nodiratime 0 0
/sys/kernel/debug /sys/kernel/debug debugfs rw,noatime,nodiratime 0 0
none /acct cgroup rw,relatime,cpuacct 0 0
none /sys/fs/cgroup tmpfs rw,seclabel,relatime,mode=750,gid=1000 0 0
none /sys/fs/cgroup/memory cgroup rw,relatime,memory 0 0
tmpfs /mnt/asec tmpfs rw,seclabel,relatime,mode=755,gid=1000 0 0
tmpfs /mnt/obb tmpfs rw,seclabel,relatime,mode=755,gid=1000 0 0
tmpfs /mnt/fuse tmpfs rw,seclabel,relatime,mode=775,gid=1000 0 0
none /dev/cpuctl cgroup rw,relatime,cpu 0 0
/dev/block/mtdblock8 /system yaffs2 ro,seclabel,noatime,nodiratime 0 0
/dev/block/mtdblock9 /cache yaffs2 rw,seclabel,nosuid,nodev,noatime,nodiratime 0 0
/dev/block/mtdblock10 /data yaffs2 rw,seclabel,nosuid,nodev,noatime,nodiratime 0 0
/dev/block/mmcblk0p2 /data/sdext2 ext4 rw,seclabel,relatime,barrier=1,data=writeback 0 0
/dev/block/vold/179:1 /mnt/media_rw/sdcard0 vfat rw,dirsync,nosuid,nodev,noexec,noatime,nodiratime,uid=1023,gid=1023,fmask=0007,dmask=0007,allow_utime=0020,codepage=cp437,iocharset=iso8859-1,shortname=mixed,utf8,errors=remount-ro 0 0
/dev/block/vold/179:1 /mnt/secure/asec vfat rw,dirsync,nosuid,nodev,noexec,noatime,nodiratime,uid=1023,gid=1023,fmask=0007,dmask=0007,allow_utime=0020,codepage=cp437,iocharset=iso8859-1,shortname=mixed,utf8,errors=remount-ro 0 0
/dev/fuse /storage/sdcard0 fuse rw,nosuid,nodev,noatime,nodiratime,user_id=1023,group_id=1023,default_permissions,allow_other 0 0
using bin/mount rather than xbin/mount
I finally found a solution: remount by explicitly using `/system/bin/mount -o ...` rather than just `mount -o ...`. I'm guessing that at some point the version in /system/xbin started taking priority and for some reason that version fails silently. More info here:
http://android.stackexchange.com/a/110883/109855