Related
!!!OBSOLETE!!! 2009-11-26: This script was very useful in the beginning, but is now obsolete. There are superior methods such as sdparted using better tools, and this script likely no longer works properly on modern builds.
As the title says, this script will repartition your sdcard so that you will have a FAT and an EXT2 partition. This is particularly useful for running apps off of the sdcard.
The app is called sdsplit, it has a strong focus on error prevention and recovery. Use at your own risk and please do let me know if you have any problems. As partitioning your card is inherently risky (especially if you are trying to preserve data from it), this script may help backup your data and any system config scripts which it modifies.
Instead of describing all of the features of the script, I will simply post the help message here since I spent a lot of time trying to make it comprehensive. The design of the script tries to make it easy for you to understand where a failure occurs if one does, and to pick up where you may have left off due to the failure after you work around it.
See the HowTo for Dummies for exact steps, but here is the general idea:
* Download sdsplit to your phone and give it execute permissions.
* Run script as root
* Do not run it from a subdirectory of /sdcard
* Run it with as few applications running as possible (to avoid having files open on the sdcard.)
The script logs its output to /data/sdsplit.log, please post the relevant bits from here if you encounter a problem and want help. But first, check out the FAQ for answers to most questions!!!
Code:
# sdsplit --help
Usage(v1.7): sdsplit [options]
'sdsplit' will by default perform all of its default actions in sequence. Specifying a
specific action will tell sdsplit to only perform that action and skip the others. You
may instead prefix an action with 'no' to prevent that specific action from being
performed while all the others are run. For debugging purposes, all output of sdsplit
will be logged (appended) to /data/sdsplit.log
PREREQUISITES:
* This is desgined to work with the Jesus Freke updates (tested on JF1.43ADP/JF1.5).
Here is why you need a JF update: for busybox, DNS, so the /init.rc invokes /system/init.rc,
and so the ext2.ko module is under /system/modules/2.6.27-00392-g8312baf/kernel/fs/ext2.
* If you are making a FAT partition greater than 2GB and have a pre1.5 android
environment, you will likely need a new 'mkdosfs' executable or internet access
from your phone so that sdsplit can download and install it for you. If a capable
mkdosfs is not found somewhere in your path (or where specified by --pmkdosfs),
sdsplit will attempt to download and install it for you from my repo. This executable
came from a Haykuro 1.5 build.
* Additionally, you will need a 'mke2fs' executable for arm-eabi or internet access
from your phone so that sdsplit can download and install it for you. If mke2fs is
not found somewhere in your path (or where specified by --pmke2fs), sdsplit will
attempt to download and install it for you from my repo. I got this executable from
here: http://sites.google.com/site/juanjosec/android
ACTIONS:
--backup|-b Perform a backup of the /sdcard directory to /data/sdcard
--nobackup|-nb (See --pbackup)
--config|-c Configure the system to handle a new ext2 partition on the
--noconfig|-nc sdcard. This involves adding mount options to /system/init.rc and
to /system/etc/mountd.conf along with creating the /system/sd mount
point for the ext2 partition on (see --pext2). Backups of the
original files will be made (.orig). You should use this for
a JF1.5 build.
--partition|-p Wipe the partition table of the sdcard and create two new
--nopartition|-np partitions, first a 500M FAT32 one (see --fatsize) and then
a Liunx one (for EXT2) on the remainder of the sdcard (see --ext2size).
--mkfs|-mk Make the FAT32 (see --fat[16|32]) and EXT2 filesystems. (partitioning
--nomkfs|-nm only allocates the space for them). This requires the mke2fs
exectuable on the G1/ADP (see --pmke2fs).
--restore|-r Restore the original sdcard backup from /data/sdcard back to /sdcard
--norestore|-nr
Along with the above actions there is one additional action if you do not care to
save your original sdcard data:
--nodata|-nd Equivalent to: --nobackup --norestore
OPTIONS:
-h|--help Usage (short) | Help (this)
--forces|-f Force exectution without prompting up front
--forcemkfs|-fm Force even if the mke2fs executable cannot be found and/or
if the mkdosfs executable is not suitable for large
partitions.
--forceumount|-fu Force even if partition already mounted at /system/sd.
Use with care, if you have an already existing EXT2
partition this will delete everything on it!!
--fatsize|-fs SIZE[KM] Set the size of the FAT partition in bytes, K or M.
(defaults to 500M)
--ext2size|-es SIZE[KM] Set the size of the EXT2 partition in bytes, K or M.
(default to the remainder) If you set this, it will not
set the FAT parition to the remainder, it will remain
500M unless you explicitly set it to something else.
The only reason to use this is if you want to leave space
for another partition.
--fat[16|32] Make the FAT partition of type 16 or 32. The default is
32 since 16 does not seem to work with my ADP.
--pbackup|-pb PATH Set the location of the sdcard backup dir.
--pmke2fs|-pme PATH Set the path to the mke2fs executable (if not already in
your PATH.)
--pmkdosfs|-pmd PATH Set the path to the mkdosfs executable (if not already in
your PATH.)
--pext2|-pe PATH Set the mount point for the new ext2 partition (defaults
to /system/sd)
COPYRIGHT: Martin Fick <[email protected]> GNU GPL2 or above
ChangeLog:
v1.7 2009-05-10 (usability improvements)
* Prompt on startup (confirm requested actions), use -f to override.
* Log invocation string to sdsplit.log
* Removed error when sdcard is empty
* If no ext2.ko is found output a message instead of an error.
more...
WOW i don't need the script since i have my card partitioned, but i didn't even know this was possible. i congratulate your efforts and hope that this works for everyone. would certainly help people that have bad computers or USB lower than 2.0 on their computers. i really don't know what to say, i am looking at the script right now and it's about 10 levels above my coding ability. great job on this
I was reluctant to try partitioning my SD card again after two failures, now I'll have to try this tomorrow. Thank you very much, MartinFick!
i was beginning to wonder why this hasn't been done before...
i applaud you in your efforts sir, ill be sure try this tomorrow.
thank you
Has anyone tried this yet? I already have mine set up but I'm dying to know.
This could make LucidREM's job easier too!
MartinFick said:
Well, here is my paltry contribution to the community. I spent entirely too much time on this! I hope it can help at least one person.
Click to expand...
Click to collapse
ok .. so maybe you DID spend entirely too much time but i would hardly call it paltry .. just skimming thru the code .. looks pretty nice .. i'm sure people will be happy to have the assistance
Great work MartinFick!!! I also have a partitioned card, but this is a great addition to the wonderful mods that already exsist in our community. I do hope it works and I'm sure it will help out many.
I refused an offer of $$$ to mod two phones (from root to apps on sd) because I lost the ability to use paragon (trial over), and "customers" not wanting to give their email address. Now that this may take care of that I might start doing it. I'll wait for reviews. Thanks again MartinFick!!!
Wow, I'm very impressed. Nice work.
So if I read this correctly. Using the following command would give me a 1gig EXT2 partion and the rest goes to FAT32?
sdsplit -es 1000[M]
I'm not ready to try it since I don't have my 8gig card yet, but Id be willing to give it a go.
Another question I notice it sets the default of the FAT to 500meg. Shouldn't that be the other way around? I mean if I dump tons of songs, videos and what not you would think that the majority of the card should be FAT to use it opposed to EXT2.
So if I read this correctly. Using the following command would give me a 1gig EXT2 partion and the rest goes to FAT32?
sdsplit -es 1000[M]
Click to expand...
Click to collapse
No, there is no simple way (that I know of) with fdisk to make the frist partition take a remainder of the disk, so that feature is only available to the second partition. Since the first partition (I believe) will need to be FAT for most hacks to work (and my script currently), that makes EXT2 the second one.
So you must figure out how big you want your FAT partition no matter what (default is 500M). The EXT2 partition can then either be the remainder of the disk or a smaller amount (if you later wanted a third partition.) If you have an 8G disk and you want only 1000M for the EXT2 partition, simply use:
Code:
sdsplit -fs 7000M
which will give you a 7G FAT and a remainder of 1G for the EXT2. Make sense? Since this was confusing, I will try to add a note about this.
Another question I notice it sets the default of the FAT to 500meg. Shouldn't that be the other way around? I mean if I dump tons of songs, videos and what not you would think that the majority of the card should be FAT to use it opposed to EXT2.
Click to expand...
Click to collapse
I guess that is probably a personal decision, I am not sure why we even need the FAT at all (except for interoperability with other devices)?
Due to the limitations that I explained in the first section, I could only hardcode a limit on the FAT partition, not the EXT2. And, since I figured that people with a 1G card would probably want at least 500M EXT2, I opted for the 500M FAT default.
If I figure out a clean way to specify the EXT2 size and let FAT be the remainder, I will consider your suggestion. I was basing the fact that FAT should be first on rules that I read in other threads (this is not an inherent disk partitioning limit). If someone could explain to me why (I assume other components in the android system expect this), perhaps this could be worked around? Another solution if FAT absolutely needs to be P1 and EXT2 P2, is to try and simply put P2 first on the partition (fdisk will usually let you do this.) This way, the EXT2 partition could be set to a fixed size and the FAT one could use the remainder (be second on disk,) but stay numbered P1. Anyone have any thoughts on that suggestion?
Awesome. So basically set the FAT and the EXT2 would set its self to the rest. I by no means was questioning why you did it the way you did it. I just didn't have a clue and it makes complete sense now.
Like I said I can't try this the 7th because the cards I ordered do not arrive until then.
Can somebody
Can somebody post a how to execute this coz i downloaded it and can't understand wat to do next
So if we do select 7GB for the first partition, it'll format it FAT32 correct? As FAT can't use that much space.
Bug Fix Release Update
I update the original post with v1.1 which has some bug fixes in it. The partitioning worked fine in the original script, but my repeated testing seems to have masked some bugs in the automounting of the new partition.
Can somebody post a how to execute this coz i downloaded it and can't understand wat to do next
Click to expand...
Click to collapse
While I am more confident about this version (more personal testing), I would be happier if someone who knew how to recover from potential disasters (someone knows how to use recovery mode) and with a basic linux understanding tried it first.
But, to answer your question, download the new one first (v1.1 which I uploaded after you posted your question), then save this file (perhaps remove the .txt extension) to somewhere in your path (/data/local/bin), and give it execute permissions: chmod 777 /data/local/bin/sdsplit and run it specifying the size of the FAT partition that you want (sample for a 1G FAT partition):
Code:
sdsplit -fs 1000M 2>&1 | tee /data/local/tmp/sdsplit.log
So if we do select 7GB for the first partition, it'll format it FAT32 correct? As FAT can't use that much space.
Click to expand...
Click to collapse
Regardless of size, it will format it as FAT 32 unless you specifically tell it to try FAT 16 (which did not seem to work for me)
MartinFick said:
But, to answer your question, download the new one first (v1.1 which I uploaded after you posted your question), then save this file (perhaps remove the .txt extension) to somewhere in your path (/data/local/bin), and give it execute permissions: chmod 777 /data/local/bin/sdsplit and run it specifying the size of the FAT partition that you want (sample for a 1G FAT partition):
Code:
sdsplit -fs 1000M 2>&1 | tee /data/local/tmp/sdsplit.log
Click to expand...
Click to collapse
Hmm, you need to simplify it further for simpletons like myself.
What we need is a step by step (and I mean step by step, i.e. every single thing you need to do to your phone no matter how obvious) guide on what to to from downloading the app, to ending up with a partitioned SD card.
So, e.g, I have an 8gb SD card, I have some data on that card, I wish to make a partition of 1gb for the EXT2 part, and 7gb for the FAT32. I also dont wish to lose my data.
Should I manually copy my data to my computer, then format the SD card and run the app, or is there a built in thing in the app to backup the SD card (on what though?) and allow you to transfer it back after the partition?
Some questions to clarify (which is why the step by step guide for idiots is needed):
1) do you download the app via the app store, and install it on the phone, or do you download the app onto your computer and transfer to your SD card via USB cable?
2) Do you need to change the file (you say you MAY want to remove the .txt. extension, that a yes or a no?)
3) save the file to somewhere in your path? What does that mean? and where exactly?
4) How do you give it 'execute' permissions? By typing in "chmod 777 /data/local/bin/sdsplit", where do you type this in?
5) are all of these instructions carried out in the command / dos type area of the phone, where you can type in these controls? I am assuming so.
These are just some of the things I do not understand (sorry for my ignorance), which is why we need someone to really clarify the whole process so even a monkey can follow it.
I hope someone has the time and inclination, since I am really pissed of with the android since I ran out of space on my internal memory, makes me want to throw the phone away.
Please be step-by-step specific please.
yeah i have the same questions as him ^^^^^
i have an 8 gig sd card. i want to have my EXT2 to have 800 MB and the rest FAT32. how much do i give the FAT32 portion?
First of all, THANK YOU! This is just what many people need. Great job on making it as simple as possible.
I too would second the request to give us a step by step directions on using this (ie press this button and then....(have to say this in Homer Sipmson's voice))
I could most likely figure it out myself but I don't want to take chances, especially since my card is alrealdy fomatted and works, I wouldn't mind changing the size of my partitions at some point but don't want to take risk of losing 110+ apps..
Once more, BIG THANKS for this piece, I'm sure a lot of people will use it.
Martin I just want to say thank you on behalf of the community.
I reset my phone this evening and tested this out on JF rc33. It's brilliant. You've done a great thing here.
I hope you don't mind but I've posted a how to over on the android section of nokia apps at the request of a few users! Of course i linked to this page and gave full credit!
Well, some of you may have heard my ramblings around here that I've been working with some of the devs here(JF and MartinFick deserve major praise, probably more than me) on getting a better way to do the whole apps to sd thing.
After 3 days of talking/discussing/working on it, I've finally reached the fruits of that investigation and thought I'd share. This new method uses the filesystem unionfs to essentially meld the /data directory with the /system/sd directory, so that they appear to be one. This has the potential to allow users to move specific apps to or from the sd card, is far more stable than the normal symlink method(will still boot, etc even if there's no SD card) and should be easier to set up. Now, onto the tutorial of setting this up.
BIG DISCLAIMER NOTE: This is a major hack of the phone and it is fully possible that it will break your phone(I've seen no permanently bricked phones but that doesn't make it impossible). Use this method, and my app along with it at your own risk.
REQUIREMENTS:
1: This only works on JF(possibly only on 1.5, not sure about the others) and The Dude's v.1.0 or greater. The Dude's 1.0 or greater actually does the steps in this tutorial for you so you can just run appstosd2 and set it all up from there if you're using his ROM.
2: This still requires you to have 2 partitions set up, first FAT32 and second ext2. Although you can use the appstosd2 app attached to this post and available in the market for $0.99 which will partition the card for you.
3: If you want your apps to go to the sd card, you must have a directory "/system/sd/app" If you didn't have apps to sd before on the ext2 partition do the following in terminal emulator or run my appstosd2 app after finishing the tutorial:
Code:
su
mkdir /system/sd/app
If you want the private-apps, or dalvik-cache moved you can replace "app" in that code with ""app-private", or "dalvik-cache" respectively. Do not copy "data" to the sd card. My script will delete it on the next reboot.
-----------------------------------------------------------------------------------------------------------------------------------------------------------------
Alright, first there's some files you need.
1: init.rc in .zip attached to this thread
2: a2sd.sh in .zip attached to this thread
All the above listed files should be put on your sd card(my tutorial will assume they are in the root directory of the sdcard(the topmost folder)
-----------------------------------------------------------------------------------------------------------------------------------------------------------------
If you need to undo the normal apps to SD first do the following in the recovery terminal(it's not strictly necessary but I'd recommend it):
Code:
mount data
rm /data/app
mkdir /data/app
if you moved the dalvik cache, repeat steps 2-3 with "dalvik-cache" instead of app. Ditto with "data" for the data cache.
-----------------------------------------------------------------------------------------------------------------------------------------------------------------
Then go to terminal emulator and type the following:
Code:
su
cp /sdcard/init.rc /data/
cp /sdcard/a2sd.sh /data/
Then reboot and you're set. By default all future apps are installed to the sd card. In order to move an app to the internal memory do the following in terminal emulator:
Code:
su
cp /system/sd/app/[the app you want to move] /system/intmem/app/
rm /system/sd/app/[the app you want to move]
I will be incorporating this into my appstosd app soon(probably as a JF and TheDude-only version until the rest of the devs get on board).
I have included a copy of appstosd 2, which will copy all apps from internal memory to the sd card with an option to remove them from the internal memory. This will only work if you have followed this tutorial.
If you don't have partitions set up, appstosd2 will now do that for you with user-set partition sizes.
NOTE: If you're using The Dude's ROM and find yourself with an outdated version of this since he doesn't always update his ROMs at the same time I update this, do the following in terminal emulator to update(after putting a2sd.sh from the attached a2sd.zip on your sdcard):
Code:
su
mount -o remount,rw -t yaffs2 /dev/block/mtdblock3 /system
rm /system/bin/a2sd.sh
cp /sdcard/a2sd.sh /system/bin/
reboot
For JF1.5, do the following to update:
Code:
su
rm /system/intmem/a2sd.sh
rm /system/intmem/init.rc
cp /sdcard/a2sd.sh /system/intmem/
cp /sdcard/init.rc /system/intmem/
reboot
NOTE FOR UPDATERS: If you had your data on the sdcard(/system/sd/data), it WILL GET DELETED with the new version. This is a necessity in order to get both wallpaper and protected apps working. I recommend moving it back to the phone.
EDIT: And here's another tutorial from ThatsBS(might be easier for the less tech savvy to follow?):
I am still learning a lot everyday from this forum. So for people new to this process let me noobify it, if I can, as I am one too.
Start by reading the first page!! Get all the stuff you need from page 1. (apps2sd2.zip and a2sd.zip )
I started from a fresh wipe and flash of jf1.51 adp.
A newly formatted fat32, non partitioned sd.
Put the init.rc and app2sd.sh on the sd (the files NOT the zip)
Then go to the terminal emulator and typed:
su
cp /sdcard/init.rc /data/
cp /sdcard/a2sd.sh /data/
Then reboot
Next I ran the apps2sd 2 app. It will ask you how much to you want to partition. I did 3000mb the first successful time and the dreaded low mem notice would not leave the status bar. I have read not to make it more then 1500mb. Have a good connection, dont force close it. It will reboot.
Next, after the reboot, I ran the apps2sd 2 app again and pressed "copy apps to sd" (let it do its thing)
Reboot.
Next I went back to the emulator and typed:
su
mkdir /system/sd/app-private
mkdir /system/sd/dalvik-cache
Reboot.
Go back to the apps2sd 2 app and hit move dalvik-cache.
Reboot for good measure and your done.
I did this in about 10 mins. Worked flawlessly.
I have a ?, if i have been using your app what dod i do diferent or what should i change?
Thanks
Good job, thanks!
[email protected] said:
will still boot, etc even if there's no sim card
Click to expand...
Click to collapse
You mean SD card?
[email protected] said:
Alright, first there's some files you need.
1: unionfs.ko from here:
Click to expand...
Click to collapse
JF1.5 build has already unionfs.ko in it, doesn't it? Is there any difference between this unionfs.ko and the one included?
1. I hear unionfs is not really stable at this point, is it true?
2. Why do you want to move the whole /data folder to sd, instead of just /data/app, /data/app-private?
3. You might want to add a command to remove previous app2sd changes (i.e. delete symlinks, create folders.)
4. How do you put selected apps to internal memory after this? Copying to /data will copy to sd card again.
The whole idea is really interesting! Thank you for your work!
ArmandHammer said:
I have a ?, if i have been using your app what dod i do diferent or what should i change?
Thanks
Click to expand...
Click to collapse
You don't have to do anything different. It will find all the apps you put on the sd card. If you want to set the phone back to normal(so the phone memory apps can still be there), you can do the following in the recovery terminal:
Code:
mount data
rm /data/app
rm /data/dalvik-cache (only if you moved the dalvik-cache)
mkdir /data/app
mkdir /data/dalvik-cache
@Dimath: yes, I did mean SD card, good catch
1:JF didn't mention it and from a little bit of using it, it seems stable to me. Plus, no matter how much I've screwed up, I haven't managed to boot loop my phone yet.
2: You could just mount those independently. I might end up doing that eventually but for now the way it is works for reasons I'll get to.
3: True, although it's not strictly necessary. If apps2sd already works, this won't break it. I'll put in a guide on undoing the symlink method
4: Actually, no. My script sets the internal memory as the main file system in the union, so apps automatically go there. Moving apps to the sd card just involves copying them to /system/sd.
Ok, just a little confusing.
I didn't use the apps2sd to move apps over to my SD card. What I did was set it with the busybox ls command. I guess that's the symlink.
My question is, if I didn't use apps2sd, can I still use your method? I also moved the dalvik cache also, everything works fine for me now, my apps go directly to the SD card when installing since my memory stays at around 65 MB no matter what I do.
Just need some laymen terms to help me understand that if I'm NOT using apps2sd, and I just linked them with the recovery method, what's my pitfalls / advantages?
Thanks.
larrygates said:
Ok, just a little confusing.
I didn't use the apps2sd to move apps over to my SD card. What I did was set it with the busybox ls command. I guess that's the symlink.
My question is, if I didn't use apps2sd, can I still use your method? I also moved the dalvik cache also, everything works fine for me now, my apps go directly to the SD card when installing since my memory stays at around 65 MB no matter what I do.
Just need some laymen terms to help me understand that if I'm NOT using apps2sd, and I just linked them with the recovery method, what's my pitfalls / advantages?
Thanks.
Click to expand...
Click to collapse
Yes, any other method of apps to sd currently uses the same symlink method, so following the directions as if you installed my app will work. A note though is that all future apps will install to the internal memory by default. I did that because it's MUCH easier to move apps from the memory to the sd card than vice versa. You can use the code I posted if you want it the other way around.
would this also work for /data/data and app-private?
or is this particular setup only for dalvik-cache and app?
oh and before I do this, just wondering, so in theory, since I have a 1.5GB ext2 partition, my free memory will be 1.573GB (1.5GB + 73Mb internal)? The internal memory will just run down and switch over to the sdcard when needed (but be seen as one filesystem)?
andonnguyen said:
would this also work for /data/data and app-private?
or is this particular setup only for dalvik-cache and app?
Click to expand...
Click to collapse
This works for the whole /data folder and everything under it. Everything is automatically installed to the phone memory right now so you can just move over anything you don't want on it(will be making an app to do this automatically)
EDIT: oh and anything you already moved over to the sd card will still show up.
Code:
su
mount -o remount,rw /dev/block/mtdblock3 /system
cp /sdcard/unionfs.ko /system/
cp /sdcard/init.rc /data/
cp /runme.sh /data/
cp /sdcard/a2sd.sh /data/
I see, when I run these lines of code (I can do this from adb also right using adb remount) this IS the new symlink method. It's just all at one time without me having to manually link anything.
Right?
larrygates said:
Code:
su
mount -o remount,rw /dev/block/mtdblock3 /system
cp /sdcard/unionfs.ko /system/
cp /sdcard/init.rc /data/
cp /runme.sh /data/
cp /sdcard/a2sd.sh /data/
I see, when I run these lines of code (I can do this from adb also right using adb remount) this IS the new symlink method. It's just all at one time without me having to manually link anything.
Right?
Click to expand...
Click to collapse
Wrong, no symlinks here. Pure unionfs goodness. Basically it convinces the operating system that /data and /system/sd are the same thing. So anything that's on /system/sd shows up under /data but everything that's normally under /data is still there. Think of it like what happens in windows when you merge folders with the same name, but in this case in actuality everything stays exactly where it was.
New news: If you haven't seen it, I updated this tutorial(and the scripts with it) quite a bit and would now consider it to be completely fully functional.
Also The Dude will be sending me an advance copy of his next ROM tomorrow to verify it works. In his build the apps to sd will be automatic, with no user setup(although if you want apps on the sd card you'll have to make an app directory under /system/sd(mkdir /system/sd/app), ditto for dalvik-cache and data).
Finally, I will attempt to add this into my apps to sd app tonight, thus rounding out everything I can do.
After all this, the only thing left is for Haykuro to build it into his ROM and me to make an app to move specific apps to/from the sd card automatically.
This will no doubt be the method of choice in no time. Great work. Sticky?
If anyone dl'd the latest version(that fixed the race condition, etc), please download the one I just put up. I made that one in windows and I believe the funky carraige return(that indicates a new line) that windows uses screwed it up
So I got some kind of error, and I don't know what is going on.
I put in all the lines in the terminal emulator app..
but after line cp /runme.sh /data/ it gives me an error
it says "cp: cannot stat '/runme.sh': No such file or directory
Any help? I rooted my phone just so I could run my apps off of my SD card.. and now I can't figure out how to get it to work. Somebody help me please.
GTASouthPark said:
So I got some kind of error, and I don't know what is going on.
I put in all the lines in the terminal emulator app..
but after line cp /runme.sh /data/ it gives me an error
it says "cp: cannot stat '/runme.sh': No such file or directory
Any help? I rooted my phone just so I could run my apps off of my SD card.. and now I can't figure out how to get it to work. Somebody help me please.
Click to expand...
Click to collapse
Which ROM is this? JF1.5 should have runme.sh there...
[email protected] said:
Which ROM is this? JF1.5 should have runme.sh there...
Click to expand...
Click to collapse
Ok, I am going to re-partition my memory card.. and then re flash to JF1.5 and try it again.
Just tried it, one issue I'm seeing is android seems to install [email protected]@[email protected] into /system/intmem/dalvik-cache at boot. Is there anyway to have that only in my dalvik-cache on the sdcard?
Its a fairly large file at 3megs so I want it to reside solely on the sdcard and even if I delete it from intmem, whenever I reboot it gets added again.
Now when I display the internal phone storage from the settings menu, it shows up at 835 megs.
I wonder if this is possible to use unionfs and make an ext2 fs object as a file on the FAT fs. That way no 2nd partition is necessary. Plus, if you remove the sdcard, everything will still work.
Maybe we could combine unionfs and this method that uses an ext2 image on the fat32 for apps to sd.
http://forum.xda-developers.com/showpost.php?p=3402947&postcount=687
mkefs can be downloaded here:
http://sites.google.com/site/juanjosec/android
dwang said:
I wonder if this is possible to use unionfs and make an ext2 fs object as a file on the FAT fs. That way no 2nd partition is necessary. Plus, if you remove the sdcard, everything will still work.
Maybe we could combine unionfs and this method that uses an ext2 image on the fat32 for apps to sd.
http://forum.xda-developers.com/showpost.php?p=3402947&postcount=687
mkefs can be downloaded here:
http://sites.google.com/site/juanjosec/android
Click to expand...
Click to collapse
I've been looking at that possibility with JF and MartinFick as well, seems like it could be a good plan but I wanted to get this bit done first. It's a good point about the dalvik-cache, but in order to fix it JF(in this case) would have to change /init.rc to make sure to do this bit before building the dalvik-cache.
Can't download apps from market
hmm so I didn't hit any errors when doing this, but afterwards I am unable to download any apps from the market. It just continually says "Starting Download..." Everything else seems to work well.
I had this same issue when I tried to manually setup apps to sd using the symbolic links. I narrowed the issue down and figured out this only occurred after I moved the dalvik-cache over to the sd card. I'm assuming I'm doing something wrong, but can't seem to figure it out. Any pointers in a general direction would be most helpful
I'm using JFv1.50 ADP1.5, not the modded version by LucidREM. For some reason the bootloader couldn't pickup his version on my phone and --edit-- I'm pretty sure I have the SD card partitioned correctly... everything else seemed to work ok. The ext2 partition shows up as the correct size
*EDIT* So apparently my issue was the SD card as well. Just did a format of the sd card and it fixed it. I also formatted data and cache (alt+w in recovery mode). Thanks MarcusMaximus!
[email protected] said:
New news: If you haven't seen it, I updated this tutorial(and the scripts with it) quite a bit and would now consider it to be completely fully functional.
Also The Dude will be sending me an advance copy of his next ROM tomorrow to verify it works. In his build the apps to sd will be automatic, with no user setup(although if you want apps on the sd card you'll have to make an app directory under /system/sd(mkdir /system/sd/app), ditto for dalvik-cache and data).
Finally, I will attempt to add this into my apps to sd app tonight, thus rounding out everything I can do.
After all this, the only thing left is for Haykuro to build it into his ROM and me to make an app to move specific apps to/from the sd card automatically.
Click to expand...
Click to collapse
If I have apps2SD and the dalvik-cache both moved on the dudes builds already, do I still have to create those directories or will my existing setup still work fine? I would like to know what kind of issues I may run into when the dude releases .95 with this (hopefully, not getting my hopes up just in case).
Hi All,
Here is my first contribution to the community, hope it is useful!
I've rezzed up a construct to produce a new /data on sd. It makes use of a second partition formatted ext2 or ext3 mounted to /system/sd with /system/sd/data then mounted over /data.
I've included a lengthy readme file which should explain things in greater detail.
Read the readme first to get a list of dirs & files this construct adds to the /data, then copy the files as explained and off you go!
currently my /data "volume" is 2GB and all is lovely!
Things to note:
I'm rom JF1.51 ADP1 CRB43, the sdcard is 8gb class6
The sd /data contains several scripts of my own design which if not needed can be deleted. I include my modified bootdeb.sh script as it mounts to /data/local/mnt/debian vs /data/local/mnt (that is a script I modified for my own needs which you may find useful)
Feel free to adjust any of the scripts according to your needs. Just note that if I update the construct, that your changes may be undone if you use it, so back them up in that scenario.
Also, I include my mount.ak.sh script which make use of a loopfs to accomplish the roughly the same thing, but in a single partition environment (intended as proof of concept).
**There is NO booting into recovery and wiping of the phone for this mod!**
Thanks to JesusFreak for the roms and saurik for the Debian info!
Cheers!
Wow! Nice, Going to try it out. Thanks
is that mean after running data2sd the phone's completely running on sd? and so much faster?
Hi,
To followup on xnycen's question, why would we do this? Is the benefit only in providing more space, or is there also a performance increase (or decrease)?
hate to see the sdcard fail with this change
well...
Yes, after the install you are running complete on sd,
but because of the method used, if you reboot, and take out the sdcard before the boot starts, you will be running as you were before the data2sd aka normal; put the sdcard back in, reboot and you are in data2sd mode again.
This effectively gives you two android run modes: "normal" and data2sd. If the SDCore can not be located the Android will boot in normal mode. You can of course try to keep them sync'd, but if you do the data2sd from a clean slate you can effectively have a "safemode" and if you have an issue with some app, go into this "safemode" and do some investigations or adjustments as the SDCore will mount if you put the sdcard in after the system is in "safemode" but the apps and such will not be loaded until you reboot.
The size expansion is the primary benefit of the construct. As far as speed goes, I haven't checked to see if there are any speed gains in moving /data to the sd... Can someone who's interested check that out and let us know?
Darkstrumn said:
Yes, after the install you are running complete on sd,
but because of the method used, if you reboot, and take out the sdcard before the boot starts, you will be running as you were before the data2sd aka normal; put the sdcard back in, reboot and you are in data2sd mode again.
This effectively gives you two android run modes: "normal" and data2sd. If the SDCore can not be located the Android will boot in normal mode. You can of course try to keep them sync'd, but if you do the data2sd from a clean slate you can effectively have a "safemode" and if you have an issue with some app, go into this "safemode" and do some investigations or adjustments as the SDCore will mount if you put the sdcard in after the system is in "safemode" but the apps and such will not be loaded until you reboot.
The size expansion is the primary benefit of the construct. As far as speed goes, I haven't checked to see if there are any speed gains in moving /data to the sd... Can someone who's interested check that out and let us know?
Click to expand...
Click to collapse
Speed is all I'm interested in If it speeds the device up, why not?
Anyone have anything to report about the speed? I am very interested in this
wow having this "dual boot" seems like an incredible idea... can anyone report on this?
can someone please give a more noob friendly instructions? from what I understand as of now is:
1) boot into recovery and wipe the phone (I'm assuming we can keep whatever ROM we had before)
2) place data2sd.img in root of SDcard (fat32)
3) and this is where I get lost... how exactly do I move the sh file to that location? how do I chmod it? how do I run it? what are the adb commands? thanks!
Hmmnm I thought we weren't doing this because of inheriant security risks?
Not to mention what happens when you mount your fat32 partition....are the apps no longer (as well as your data) available?
NO booting into recovery and wiping of the phone!
Hold up people!
**There is NO booting into recovery and wiping of the phone!**
My bad for not being clear on the wipe instructions!
1) (optional) If you are to wipe it (your choice it is not required), then press menu->settings->SD card & phone storage->scroll to bottom of screen and select "Factory data reset". This will wipe the /data partition only removing all apps and settings. BACKUP YOUR /data dir to sd, First or you will need to down load all your apps again to include paid apps!!
2) place data2sd.img in root of SDcard (fat32)
3) terminal in or adb shell in.
4) cp /sdcard/data2sd.sh to /data/local/bin - to copy the script to your user-space
5) chmod 0750 /data/local/bin/data2sd.sh - to make it executable
6) /data/local/bin/data2sd.sh or data2sd.sh may work to run the script
7) once the install is done it should tell you to reboot. If you had the ddms debugger running, you can observer the log as it is working.
8) done. It may boot a little longer if you clean-slate installed and then restored your apps by copying them back into /data/app and /data/app-private which has the affect of reinstalling everything, and thus the boot will take a while if you have alot of apps like I do. Again you can observe this as the Android boots if you have the debugger running.
thanks a lot man, will give this a shot in a few hours! not at my comp right now
security risks and (u)mounting /sdcard
TheDudeOfLife said:
Hmmnm I thought we weren't doing this because of inheriant security risks?
Not to mention what happens when you mount your fat32 partition....are the apps no longer (as well as your data) available?
Click to expand...
Click to collapse
Not sure why there would be any security issues, the Android is already rooted. If someone can steal the sdcard, they can steal the entire Android, and if the sdcard is left lying about, then yes it can be strolen then too.
The construction of the SDCore assumes all the original permissions, so nothing has access to things it shouldn't save the scripts that use the cache as a backup mount point, but it is given the same permissions as /data, so no worries.
With this construct in place, you can't physically remove the sdcard without first powering off the Android, or rebooting it and removing the sdcard first thing. But while the system is operational, you can mount the sdcard to usb and umount it from usb without issue as long as any mounts to the sdcard are released (loopfs, etc) prior to trying. vold will give 10 tries to umount /sdcard to include attempting to kill the processes with file locks on /sdcard when it tries to umount the volume to attach it to usb.
A a matter of fact, if you observe via teh ddms debugger during boot, the vold service is busy checking the sdcard and mounting it well after the system has already mounted the sdcp2 and begun initializing apps from the sd /data.
So, as long as "sdcard partition2" (sdcp2) remains mounted and all, you can mount the sdcard to the connected Host and back and still have access to your apps and data all you want. I reckon this is how the app2sd and dalvik2sd constructs also perform.
The only thing to really note is that the first partition must be vfat (fat32) and the second either ext2 or ext3 (currently as they support file permissions). vold only cares about the first partition which it expects to be a vfat volume. So as long as p1 is vfat and p2 is posix compliant, we're golden!
The only real question I don't have a good answer for is the speed gains question. My card is a 8GB class6 and things seem fairly responsive. I don't know how much different it would be with a class 4 or 2, or the real speed difference with the built in storage. Honestly it feels a little more responsive, but I haven't really done things that make it feel sluggish.
Oh, I saw the .img and assumed you just mounted the .img from fat32. My bad for not reading all the instructions.
Any problems with apps crashing? I have had a lot of quirky issues in the past with merging the entire partition.
Thanks for the response. I like what you've done here. I'll have to try it out for sure.
TheDudeOfLife said:
Oh, I saw the .img and assumed you just mounted the .img from fat32. My bad for not reading all the instructions.
Any problems with apps crashing? I have had a lot of quirky issues in the past with merging the entire partition.
Thanks for the response. I like what you've done here. I'll have to try it out for sure.
Click to expand...
Click to collapse
No worries; the .img file can be thought of as an install cdrom it is only used the one time during install.
As far as apps crashing, no problems!
During my experimentation building the construct, permission mangling happens if apps are moved out of /data/app, /data/app-private but /data/data and maybe /data/dalvik-cache are not cleaned up prior to copying apps back into their respective app dirs.
What happens is the app dirs are monitored. if you move an apk into the dirs android will install the app. Likewise if you delete an app from those dirs PackageManager will uninstall the app. If /data/data already has the dir for the app, it will use it. if the /data/system/packages.xml and /data/data don't have the same id assigned to that app, you get a permissions\\id conflict; the PackageManager will not manipulate the dir if the id's don't match.
The app /data/local/bin/archiveApps.sh, /data/local/bin/softWIPE.sh and /data/local/bin/restoreApps.sh scripts allow one to backup thier apps to the new /data/app-archive and /data/app-private-archive dirs, clean out /data/data/ /data/dalvik-cache, and restore the apps to their app dirs. As the apps are copied into their dirs, the PackageManager will update /data/system/packages.xml proper and rebuild /data/data and the dalvikVM will build the /dalvik-cahce proper.
Someone made a seemingly nice script (I've not used it yet) called fix_permissions.sh that will parse the /data/system/packages.xml and update the ownership id of the apps /data/data sub dir proper and thus is more scalpel like in operation, but that process doesn't make a backup of the apps; so using both may be the most effective replacing the softWIPE.sh part of the process with the fix_permissions.sh instead.
The only time you should run into issues is if say you have 10 apps installed in teh SDCore /data and 6 in Android /data and then attempt to sync them (because the 6 are different than the 10) by copying\\merging Android /data with SDCore /data the SDCore /data/data /data/dalvik-cache and /data/system/packages.xml will now be mangled.
/data/system/packages.xml will now no longer know about the 10 apps that were installed prior, and on boot PackageManager will "install" them, but /data/data will have dirs inside with now different id's from what was newly assigned them in /data/system/packages.xml, and the 10 apps will now not work correctly but the 6 will as dirs with matching id's were created when they were "installed" new.
To fix, either the softWIPE.sh process outlined above, or the fix_permissions.sh process also mentioned above.
So did anyone try this at all?
Can this be done after doing the apps2sd by marcusmaximus? I tried it but when trying to chmod 0750 /data/local/bin/data2sd.sh it said "No such file or directory" so i tried mkdir /data/local/bin and got "File Exists" so i proceeded with copying data2sd.sh to /data/local/bin again which went without showing any errors and when trying to chmod 0750 /data/local/bin/data2sd.sh again i got the same error so i tried to ls /data/local/bin and just got # what am i doing wrong?
looks interesting! might try this during the weekends ill give an update if i encounter any issues or not
interesting. I'll be looking into this!
So I was using Slax. Great LiveCD/USB linux, extremely customizable, modular, fast, and small, and has the capability of either:
- saving changes to its rootfs onto an AUFS mounted on a non-linux FS (FAT32, NTFS) using posixovl (POSIX Overlay FS) with metadata (permissions, etc.) being held in files
- saving changes to a fixed-size loop mount image.
This got me thinking.
If we could insert all the necessary modules, code, etc. for posixovl into the Android linux, and make a modified a2sd script that takes advantage of posixovl, we could effectively do away with the requirement for crazy partitioning.
It should be simple enough for ROM devs to implement, assuming it's ready and installed:
1. Create folder on main partition if it doesn't exist, something like /sdcard/system/[app, app-private, dalvik-cache, app_s]
2. In the init scripts, before the a2sd stuff, mount /sdcard/system with posixovl on /system/sd
3. Run a2sd as normal, it should automatically just work.
I'll hopefully test this once I get my phone to a stable development/testing stage, and I don't need to make phone calls for a while. Anyone else is welcome to try to implement this idea.
My current test environment:
- HTC Dream (T-mo G1) with the deadly SPL of doom
- Cyanogen Experimental, latest build
- Amon_RA's modded recovery
- Wipe /data, move all existing apps to backup, remove a2sd partition, Backup for Root Users to restore some settings and data
Anyone with ideas or improvements, please let me know.
To be tested:
- Feasibility (can it work?)
- Functionality (does it work?)
- Portability (Can it work on other ROMs and devices like Hero, Pulse, Blur etc.? If so, will likely be moved to XDA's new Android board)
- Stability (Will everything Force Close on boot? Does it run fast enough? Does anything get corrupted over time?)
Links:
- http://sourceforge.net/projects/posixovl - Sourceforge page for posixovl
In desktop linux you can create a file with the touch command, and mount the file to a mountpoint after formatting it to ext4 for example.
Maybe this is the easier way?
I have done this about 5 years ago, but I will try it today and report if it worked.
edit: ok done already:
1. create a file of the desired size, eg: dd if=/dev/zero of=filename bs=filesize count=1
2. use mke2fs to format the file
3. create a mountpoint and mount the file
thats all. Now I have a 128MB file on my PC, mountable and usable like a partition.
Archont said:
In desktop linux you can create a file with the touch command, and mount the file to a mountpoint after formatting it to ext4 for example.
Maybe this is the easier way?
I have done this about 5 years ago, but I will try it today and report if it worked.
Click to expand...
Click to collapse
As far as I know, you can do that on the mobile Android, too, and that does work in theory. This technique involves mounting a loop filesystem, and it too will allow one-partition apps2sd, but it's less flexible, and I would think slower, than the overlay method.
For a 512MB apps image:
Create empty 512MB file
# dd if=/dev/zero of=/sdcard/apps.img bs=1024k count=512
Format it to Ext2
# mke2fs -L Apps2SD /sdcard/apps.img
Unmount existing a2sd
# umount /system/sd
mount new a2sd image
# mount -t ext2 -o loop /sdcard/apps.img /system/sd
Make the usual directories, and a mountpoint for the old a2sd partition
# mkdir /system/sd/app; mkdir /system/sd/app-private; mkdir /system/sd/dalvik-cache; mkdir /system/sd/apps-tmp
Mount the old a2sd partition
# mount -t ext2 /dev/mmcblk0p2 /system/sd/apps-tmp/
Move all files from the old partition to the image file
# mv /system/sd/apps-tmp/* /system/sd/
Unmount and remove the mountpoint, we don't need it anymore
# umount /system/sd/apps-tmp
# rmdir /system/sd/apps-tmp
Finally, you add the following line to the init script where the a2sd auto mount happens, and comment out the old line.
Code:
[...]
mount -t ext2 -o loop /sdcard/apps.img /system/sd
#mount -t ext2 /dev/mmcblk0p2 /system/sd/
[...]
This should do what you described, in theory. I can't say whether it will work or not. I can't tell whether it will or won't screw up your phone, I can't be held responsible if you screw something up or overlook the details. Either of us might have made a typo somewhere; apply common sense before doing anything.
This sounds great! I think this would also be usefull for someone like me, who has a sd card that doesn't want to be partitioned anymore (cross-linked files??). Only thing possible is fat32 or ntfs.
Am I correct with my assumption?
This sounds a lot harder and more complicated then partioning. Your also talking about a lot of work needing to be done just so people can avoid doing a simple thing like partioning a sd card. I would say it would be very difficult alone to get the os to run a virtual mounting service especially since that will take up resources and slow down the phone. There is a reason they only use this technique on live cds is it works but its slow. most of the computers they are running on have 1gig of ram and 2ghz cpu's. i really dont think the g1 can push this.
I do not think that this is great, it definitely is slower than a ext4 partition on a good class 6 microSD card. And it is more vulnerable to data loss since 2 different filesystems including a 20 year old non-journaling fs at the base of this construct are involved.
Another problem that came to my mind: when you mount your SD card as external USB device to a PC, the file containing your apps will no longer be accessible, or Android will make using the phone as external data storage impossible.
Interesting.
There is, however, a major problem: What happens when you unmount the fat partition on the phone in order to connect with a computer using UMS? Answer: everything on the phone will crash and burn since the apps filesystem will suddenly disappear = BAD.
posixovl is a nice find though...
Note that aufs, loopmount linux filesystems, etc., wouldn't be needed with this since posixovl appears to be vfat with posix extensions, so you should be able to just use posixovl directly on the sdcard.
There are several problems with that though... i.e. how reliable is posixovl regarding users tampering with it?
In any case, a prerequisite for use of it would be certain other changes being planned...
You might want to contribute to this thread:
http://forum.xda-developers.com/showthread.php?t=577941
(note: the thread links to a thread at android-platform, the one here has, as expected, gone off on a tangent... just ignore the junk.)
TylTru said:
So I was using Slax. Great LiveCD/USB linux, extremely customizable, modular, fast, and small, and has the capability of either:
- saving changes to its rootfs onto an AUFS mounted on a non-linux FS (FAT32, NTFS) using posixovl (POSIX Overlay FS) with metadata (permissions, etc.) being held in files
- saving changes to a fixed-size loop mount image.
This got me thinking.
If we could insert all the necessary modules, code, etc. for posixovl into the Android linux, and make a modified a2sd script that takes advantage of posixovl, we could effectively do away with the requirement for crazy partitioning.
It should be simple enough for ROM devs to implement, assuming it's ready and installed:
1. Create folder on main partition if it doesn't exist, something like /sdcard/system/[app, app-private, dalvik-cache, app_s]
2. In the init scripts, before the a2sd stuff, mount /sdcard/system with posixovl on /system/sd
3. Run a2sd as normal, it should automatically just work.
I'll hopefully test this once I get my phone to a stable development/testing stage, and I don't need to make phone calls for a while. Anyone else is welcome to try to implement this idea.
My current test environment:
- HTC Dream (T-mo G1) with the deadly SPL of doom
- Cyanogen Experimental, latest build
- Amon_RA's modded recovery
- Wipe /data, move all existing apps to backup, remove a2sd partition, Backup for Root Users to restore some settings and data
Anyone with ideas or improvements, please let me know.
To be tested:
- Feasibility (can it work?)
- Functionality (does it work?)
- Portability (Can it work on other ROMs and devices like Hero, Pulse, Blur etc.? If so, will likely be moved to XDA's new Android board)
- Stability (Will everything Force Close on boot? Does it run fast enough? Does anything get corrupted over time?)
Links:
- http://sourceforge.net/projects/posixovl - Sourceforge page for posixovl
Click to expand...
Click to collapse
lbcoder said:
Interesting.
There is, however, a major problem: What happens when you unmount the fat partition on the phone in order to connect with a computer using UMS? Answer: everything on the phone will crash and burn since the apps filesystem will suddenly disappear = BAD.
Click to expand...
Click to collapse
I kinda overlooked that point. Oops.
Though this same problem does exist on regular apps2sd when you remove the card without dismounting it, killing all apps and their processes, and freezing Dalvik's method of autostarting some apps.
I do tend to swap cards every now and then, but only after a reboot. Dalvik re-enumerates and caches dex, which makes for a slow boot, but it seems to just work in most cases that the apk install doesn't drop the app's functional payload (helper Linux/shell utils, libraries, NDK .so's) in /data/data (like some emulators, the Android Scripting Environment)
lbcoder said:
There are several problems with that though... i.e. how reliable is posixovl regarding users tampering with it?
Click to expand...
Click to collapse
As far as I know, the metadata files are marked as hidden and system files, and begin with a '.'. And I haven't tried this, but I think modifying the actual files under Windows has no negative effects, but moving, deleting, or copying files would likely be a no-no.
Also, I don't think there's a 'fsck' for posixovl, meaning that if any metadata files were screwed with the wrong way, the entire overlay FS would be trashed.
lbcoder said:
In any case, a prerequisite for use of it would be certain other changes being planned...
You might want to contribute to this thread:
http://forum.xda-developers.com/showthread.php?t=577941
(note: the thread links to a thread at android-platform, the one here has, as expected, gone off on a tangent... just ignore the junk.)
Click to expand...
Click to collapse
I checked that out. It was actually a small inspiration for what I was thinking of.
In any case, Android's package management system needs an overhaul. The package storage needs to be de-Linuxified, as all it is is a bunch of .apk files and .dex/.odex files, the UIDs of apps are in the AndroidManifest.xml, right?
In a somewhat unrelated note, app data needs to be moved to a specified folder structure on the sdcard. My card is full of folders in the root directory with random names.
If I'm understanding you correctly, you're talking about storing an image file on the normal SD card partition(which has to be FAT32 as far as I've seen) and then mounting it, correct? This idea has been talked about at length before on at least 3 separate occasions(2 of which were on this very forum) and found to be a bad idea due primarily to massive security risks since FAT32 has no permissions.
Also, I believe cyanogen ended up dumping unionfs/aufs due to rampant memory issues.
If you are talking about mounting an image from the FAT32 partition, please don't endorse this. We don't want to be throwing in security bugs into android, especially ones such as this which can't be plugged up.
As a modification to what I said: If you're suggesting doing this(or something similar) on a separate filesystem, after that project to change the AOSP to support one with permissions is finished, then I'm in full support.
If you want to go for a single partition on the sd card, why don't you just make the entire card use ext4? Your linux desktop reads it anyway, it uses journaling and so on, I guess it would be faster compared to fat32 and it is definitely safer to use.
And i guess it is not too complicated to mount this partition and use it for pictures, music and so on.
I have not tried this (yet) and I go to bed in 20 minutes, but maybe I will start testing something in that direction tomorrow.
[email protected] said:
If I'm understanding you correctly, you're talking about storing an image file on the normal SD card partition(which has to be FAT32 as far as I've seen) and then mounting it, correct? This idea has been talked about at length before on at least 3 separate occasions(2 of which were on this very forum) and found to be a bad idea due primarily to massive security risks since FAT32 has no permissions.
Also, I believe cyanogen ended up dumping unionfs/aufs due to rampant memory issues.
If you are talking about mounting an image from the FAT32 partition, please don't endorse this. We don't want to be throwing in security bugs into android, especially ones such as this which can't be plugged up.
As a modification to what I said: If you're suggesting doing this(or something similar) on a separate filesystem, after that project to change the AOSP to support one with permissions is finished, then I'm in full support.
Click to expand...
Click to collapse
UNIX permissions don't do anything in the way of "security" unless you have no access to the actual storage device from another computer (as is the case with the unrooted Dream's internal memory), or unless encryption is used. The posixovl driver OVERLAYS Unix permissions over Fat32 filesystems. But even still, with Unix permissions, nothing's stopping someone else from mounting the Ext2 partition and using chown and chmod.
And the image file on the SD card's Fat32 partition is a complete Ext2 partition complete with Permissions. Nothing is lost.
Archont said:
If you want to go for a single partition on the sd card, why don't you just make the entire card use ext4? Your linux desktop reads it anyway, it uses journaling and so on, I guess it would be faster compared to fat32 and it is definitely safer to use.
And i guess it is not too complicated to mount this partition and use it for pictures, music and so on.
I have not tried this (yet) and I go to bed in 20 minutes, but maybe I will start testing something in that direction tomorrow.
Click to expand...
Click to collapse
We'd just have to find the part in the Android that mounts /sdcard/, and change 'vfat' to 'ext2'. The only reason I wouldn't do this, is because it would immediately make it incompatible with Windows and Mac's default FS drivers. As far as I know, the only FS's that are supported universally within Linux, Mac, and Windows, are FAT and NTFS. And NTFS can be made to have crude support for permissions through security descriptors. Although, the Dream SPL, the Recovery images, and most of Android only uses FAT32.
This is discussed in android-platform Group :
http://groups.google.com/group/andr...read/thread/bf0709c157451cd9/f6aee1830c84620f
The goal is to be able to integrate this in android.
And not having to partition the SDCard is one of the requirements so far...
Unix permissions are not stored using fat or vfat, and ntfs is not really supported in desktop linux and i guess it cannot be used in android linux.
I would not use windows anyway so this is no problem to me, and there are drivers around to mount ext systems in windows. As Mac OS is based on unix there will be a solution for this too.
Access usind adb push and pull, via ftp and so on is not touched by using ext4 on the entire sd card I guess.
And if you don't go the easy way using gparted on a live cd or usb device to create 2 partitions, you will have to live with some disadvantages anyway.
Finally I want to say that my ideas are far from being perfect or usable at all, I see this thread as a kind of brainstorming.
im not as linux or android savvy as probably any of you but before the current method of creating a swap partition became the "standard", people used a swap file on the sdcard and linked that. seems similar to what you are suggesting here.
ofcourse when mounting the fat partition elsewhere (ums in windows for example) that swap file could no longer be used within android. i dont see a way to get passed the same issue, but worse here, due to android not having crucial apps when the fat partition is mounted.
then again, i am pretty much over my head in this conversation and could be over looking something...
I'm kind of fascinated by the FUSE + posixovl method of doing this. In the long run I have a feeling that it's going to perform like ****, but I think it's worth testing.
I managed to get both libfuse and mount.posixovl built and running on Android.
posix-overlay(/sdcard/fuse) on /sdcard/fuse type fuse.posixovl (rw,nosuid,user_id=0,group_id=0,default_permissions)
Giving this a little testing now, it definitely works.
Code:
/sdcard/fuse # ls -l
drwxr-xr-x 2 1000 1000 4096 Nov 5 17:17 test
TylTru said:
UNIX permissions don't do anything in the way of "security" unless you have no access to the actual storage device from another computer (as is the case with the unrooted Dream's internal memory), or unless encryption is used. The posixovl driver OVERLAYS Unix permissions over Fat32 filesystems. But even still, with Unix permissions, nothing's stopping someone else from mounting the Ext2 partition and using chown and chmod.
And the image file on the SD card's Fat32 partition is a complete Ext2 partition complete with Permissions. Nothing is lost.
We'd just have to find the part in the Android that mounts /sdcard/, and change 'vfat' to 'ext2'. The only reason I wouldn't do this, is because it would immediately make it incompatible with Windows and Mac's default FS drivers. As far as I know, the only FS's that are supported universally within Linux, Mac, and Windows, are FAT and NTFS. And NTFS can be made to have crude support for permissions through security descriptors. Although, the Dream SPL, the Recovery images, and most of Android only uses FAT32.
Click to expand...
Click to collapse
Ya, I meant more from the standpoint of a rogue app. Since FAT32 has no permissions, what would prevent such an app from modifying the stored image file to, say, change a trusted app with superuser permissions to some new code of its own making to, for example, watch for credit card numbers and send them back to the person who made the original rogue app? I'm always hesitant with any ideas that suggest storing an image file on the sdcard for appstosd for this reason.
Forget it, it's useless.
An overlay filesystem prevents you from enabling USB storage.
If you want to play around with FUSE on Android, here's a repository for my port of libfuse..
http://github.com/cyanogen/android_external_fuse
Hi,
I have an idea. I used symbian S60 of Nokia, Symbian can install app to sdcard. I see that when I mount sdcard to PC, my phone immediately hold all activations of all applications on my phone. And they have a PC sync software that help us access sdcard but not mount sdcard (like that we copy file from computer to sdcard via debug mode on android).
I think we should find out how symbian can do it and we will use their way .
I'm not a developer, I'm just an user.
I talked to a few people about this, and some deep kernel voodoo is going to be needed for this to really happen without partitioning.
Another idea is to forge ahead with this, and ditch the "unmount fs for usb storage" and use RNDIS + Samba or something like that instead to access files on SD. I kind of like this idea.
I keep refining this script for my android and do not understand why any script I have tried to write will not run. Yet, any script I download and put in there will run. I have changed owner and group to root. Changed permissions to 755. Yet it still will not run, no matter how much I try and model other init scripts that I see that do run. It is vital I get this to work for something I am trying to do with my phone but no dice yet. I have successfully written many shell scripts that other programs can start, but I must be missing something on this init thing. I have refined this simple script about 25 times already with no luck. Here is what I currently have.
filename is 40cache
#!/system/bin/sh
busybox mkdir /sdcard2;
busybox mount -t tmpfs -o size=128m none /sdcard2
I have tried with and without done at the end. With and without semicolans blah blah blah and it still will not run. Can someone help a lady in distress? I am trying to make a ramdisk with the directory /sdcard2 before my apps start up, if that is not clear.
Well I was partly right. My last version of the init script was 100% fine...except one thing. I ran the commands in case Android was being stupid about something as it usually is. I was right....permissions. Not even root can write that directory with the mkdir command(explains the directory never appearing even if it was the mount command that failed which it did because of mkdir failing). Maybe you guys can still have me because I need to rethink this solution. I have a Wildfire S with Int2Ext4 Mod installed(thanks ChronicCorey). My cache is just too slow with this one and Int2Ext4+ does not provide me enough storage. What I was trying to do was fake another SD Card so that I could use CacheApps2SD to cache apps to RAM or internal storage. If you have a solution for either(preferably internal storage now that I think more about it) you will be my hero. Just to be clear, I want Int2Ext4 doing just what it's doing but move just the app caches to internal storage or RAM, but not the rest of /data/data. That much should fit and get rid of my lags when I run cache I/O intensive apps where latency is a big concern.
Surprised I got no input from all the experts on XDA that have made me a fan of this forum. Marking this as solved. For a recap, I have OWL project JB tweaked to the hilt with PurePerformance cross breeder mod and many of my own tweaks. Only issue was with Int2Ext scripts not efficiently using what fast memory is available on this phone or Underutilizing storage for the + variants. Here is my solution that mounts my app caches and my hola web cache to the unused internal memory. Do not try this at home unless you understand how to mod this to your phone's mountpoints.
With Int2Ext, Cron4phone, and SManager already installed:
Set this to run on boot in Cron4phone before /sdcard mounts
rm -rf /storage/sdcard0/Android/data/org.hola/cache
rm -rf /storage/sdcard0/CacheApps2SDCard
Now, set the following 2 scripts to launch as root after SD is shared:
#!/system/bin/sh
mkdir /storage/sdcard0/CacheApps2SDCard
mount -t yaffs2 /dev/block/mtdblock5 /storage/sdcard0/CacheApps2SDCard
#!/system/bin/sh
mkdir /storage/sdcard0/Android/data/org.hola/cache
mount -t yaffs2 /dev/block/mtdblock5 /storage/sdcard0/Android/data/org.hola/cache
Now run each of the scripts in order manually to avoid needing to reboot for last step.
Lastly, install and run Hola and Cache Apps to SD Card. Now the old data partition is exclusively an app and web cache. App data and Libs are still on SD-ext and not clogging this partition like Int2Ext4+. You can install gigs of apps without space issues or lag!!
As a bonus, I used Swapgen to use my mostly unused /cache partition as RAM. No fast storage is wasted now and this phone is lag free as it gets. I typed this long post while multitasking using the AOSP keyboard Big games run like a dream!!
Sent from my Wildfire S A510e using xda app-developers app
OK for the benefit of those with the guts to try this: remove the mount script for Hola. A few permissions issues not worth debugging due to the fact it fills the cache fast. Keep the rm -rf line in Cron to help it start faster on boot. The app cache continues to work beautifully over multiple reboots. So try that if you know how to spot the correct partition. Then use that instead of mine
Sent from my Wildfire S A510e using xda app-developers app
Can you elaborate what is Hola,Swapgen,CacheApps? If you cannot write to a partition you can use remount and rw option? You can also link the dalvik-cache to the sd-card to free some space?
Hola is a web accelerator with cache. Compresses data then caches like squid. This hack is for Int2Ext and Int2Ext4 users who find the + versions of such scripts use too much NAND space but find regular versions making cache slow by mounting it on ext-sd, an ext4 partition used in cronmod Int2Ext to replace NAND data. This hack with cache Apps to SD puts the app cache folders back on the NAND for speed, but does not put everything in /data/data on there like the + versions of the mod which effectively limits usable app space and leaves little room on NAND for app caches(band data space is 150MB on this phone, enough for caches but not all app data). SD cards read fast, write slower. Thus all cache I/O is moved to the NAND for exclusive use by cache. Cache Apps to SD binds these caches to a directory on /sdcard. These scripts mount that directory on the previously unused NAND space instead, giving back the speed Int2Ext4 took by putting the cache on the SD, but keeps the other space savings afforded by the script.
Sent from my Wildfire S A510e using xda app-developers app
Do you mean this post:http://forum.xda-developers.com/showthread.php?p=27538212#post27538212. I'm still learning and I have cacheapps2sd but where is the script? I couldn't find a main app. Can you elaborate? I have tried to move my apps to sd-card but it doesn't seems to work.