SDSPLIT repartition your SDcard on phone (w/o a PC) - G1 Android Development

!!!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!

Related

"Stale NFS file handle"

Hi all
I have all my apps and data moved to the sdcard a while back but my phone crashed and I decided to move only the apps to the sdcard.
I'm trying remove the /system/sd/data folder on the sdcard and keeps getting that error message. How to fix it?
Thanks
This should only happen if an NFS export is mounted to a linux box of some sort, and that export has changed or otherwise become inaccessible.
any idea how to fix it?
i have this problem, i'm not able to delete the data folder beacause of that error. :/
your ext2 partition is corrupted. this happens quite a lot if data is moved to the sdcard. boot up linux and run fsck on the sdcard and that should fix it.
cool. I'll give that a try.
Thanks
I'm having this problem too. Can you provide some basic instructions for how to mount and fix under linux? I have an ubuntu vmware image I can boot to on my windows pc and a usb card reader. Will that suffice?
When you plug the card into an ubuntu box it should automatically mount it as the next available drive. You'll have to figure out what device node the card shows up as, unmount it (umount /dev/<insert device name here>), and then run a filesystem check (fsck /dev/<insert device name here>) on the unmounted card. The utility will report various problems about "inodes" which you will want to say yes to fix. Once it has run through the file system should be in a consistent state and ready for use again.
You run the risk of losing stuff written to the card (which is probably corrupt anyways) when you run the fsck so you may want to take a copy of the data first.
On a side note: I am not sure what the default mount options are listed for moving the stuff onto the sd card in the faqs but I suspect it may help prevent corruption to mount the card on android with the sync option. Though, this will definitely slow writes to the card. It would definitely be a bad idea to remove the card while your G1 is running either way.
equid0x said:
On a side note: I am not sure what the default mount options are listed for moving the stuff onto the sd card in the faqs but I suspect it may help prevent corruption to mount the card on android with the sync option. Though, this will definitely slow writes to the card. It would definitely be a bad idea to remove the card while your G1 is running either way.
Click to expand...
Click to collapse
I was thinking of using the sync option, but then I read this at http://linux.die.net/man/8/mount:
sync
All I/O to the file system should be done synchronously. In case of media with limited number of write cycles (e.g. some flash drives) "sync" may cause life-cycle shortening.
Click to expand...
Click to collapse
Busybox seems to have an fsck command built in, but I don't think all the supporting stuff is there. I'd like to have a way to fsck my ext2 partition while on the go and not near my linux box.
I know that you can't fsck without unmounting the partition and of course it would be bad to unmount the partition with apps on it while the phone is running, but I was thinking it would be nice to be able to boot into the recovery console.
I tried this and attempted to do a fsck on /dev/mmcblk0p2 with the fsck in busybox as follows:
Code:
busybox fsck -t ext2 /dev/mmcblk0p2
But the error I got was that fsck.ext2, which is the actual executable that should be used, isn't there.
What would it take to get this onto the system so that I could boot into recovery and do a quick fsck and then reboot back into phone mode?
I was thinking of using the sync option, but then I read this at http://linux.die.net/man/8/mount:
Click to expand...
Click to collapse
Where flash lifetime is concerned... I agree, this will certainly have some impact. However, the amount of wear concerned really depends on the number of write cycles the particular flash you are writing to can handle, and how good any wear leveling in the memory controller is. Modern flash memory will likely last on the order of years even with tons of writing going on. If all you are moving to the card are the apps, that data will likely be written once (or maybe a few times over the life of an app) and only re-read from that point forward. The caching will eventually commit any data in the buffer to "disk" regardless of how much is actually there. The idea is to line up all the writes so they can be done efficiently. Where ext3 is concerned, the commit interval is 5 seconds by default, I am not sure what it was in ext2 but I imagine it is similar. Ext2 is not really a flash optimized filesystem, but it is readily available on basically any linux distro, and is supported on Android. A better fs for flash drives where write cycles are an issue might be something like jffs2 or yaffs.
At any rate, sd cards are cheap. Why not just throw it away when it starts to die?
But the error I got was that fsck.ext2, which is the actual executable that should be used, isn't there.
What would it take to get this onto the system so that I could boot into recovery and do a quick fsck and then reboot back into phone mode?
Click to expand...
Click to collapse
You would have to compile an ARM6 compatible version of fsck and get it onto the recovery partition so you could run it.
just turn off your phone, pull out the sdcard, boot on a linux os and
then in console type :
fsck -p /dev/your_ext2_partition
Is there any way to clear this error message on a windows xp computer?
Maybe use pargon partion manager, but where do I go to fix it in pargon?
equid0x said:
Ext2 is not really a flash optimized filesystem, but it is readily available on basically any linux distro, and is supported on Android. A better fs for flash drives where write cycles are an issue might be something like jffs2 or yaffs.
Click to expand...
Click to collapse
Hmm... Well, we know that yaffs is supported on Android because that's what the onboard storage uses. So I wonder why the tutorial for apps-on-sdcard suggests creating an ext2 partition? Couldn't we create a yaffs partition on the sdcard and use that instead?
Maybe because yaffs isn't as commonly supported in non-Android partitioning tools (which you would have to use to set up the card initially)?
In any case, if there's no real downside to having the partition be yaffs, how can I go about formatting it as such? I don't recall seeing such an option on gParted or anything, but then again I didn't look that carefully.
So can anyone clue me into how I might add yaffs/yaffs2 support to my desktop linux box? I'd like to try using a yaffs2 partition rather than ext2 to see if I get better reliability, but I need to add support for that filesystem first. Can't seem to figure out how to do that quite yet...
You will likely need to create the partition from the terminal using something like fdisk or cfdisk which will allow you to select the proper filesystem ID. The command for creating the filesystem is mkyaffs. The fstab in android will need to be modified to enable mount of this file system at boot. You will need to install all of the yaffs support tools on a linux desktop to get access to the mkyaffs command.
Yaffs is designed to be used directly on NAND or NOR flash memory (not abstracted through the controller built into an SD card) but it may work anyways. I am not very familiar with the specifics of this particular FS. Most of these flash filesystems are designed to provide a bootable root filesystem for an embedded device.
Yaffs kernel support can be built into a custom kernel with the instructions here:
http://yaffs.net/howto-incorporate-yaffs
Its not likely you will find pre-made packages for any of this in a common distro like Ubuntu. So, you will need to know how to compile it all by hand. A good starting point for a lot of linux info is The Linux Documentation Project at:
http://www.tldp.org/
FWIW I have built homebrew linux based routers for dual ISPs, IPSEC VPN and the like using a lightly modified version of CentOS and 4GB CF cards plugged into an ATA adapter. I used EXT2 on these and they were in production use at a small 13 server farm for a couple of years before being replaced with newer equipment without any failures whatsoever.
I have also used CF cards in small 200Mhz cube PCs as basic web kiosks for extended periods of time without any failures as well.
Under normal usage patterns on a mobile device probably does not require a large amount of writes in the grand scheme of things. I'd say it is fairly likely that your card will outlive the device you are using it in regardless of the filesystem in use.
If you are seeing lots of corruption I would suspect a flakey/failing SD card or some other hardware related problem. It definitely pays to buy high quality flash media. I would also suggest not allowing the phone to constantly run dead if you know things are being written to the SD card, since random power failures during a write to flash can permanently damage the media.

[CONCEPT] Single Partition No-Format Apps2SD

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.

[Q] ext2/ext3/ex4 and lynux-swap with incubus RLS14/15

Hi, I have been testing several NAND set-ups
-system to NAND and data to resized data,img
-system to resized system.img and data to resized data.img
-system to NAND and data to ext2
...
I am currently using NAND and data to ext2 partition, so all apps are installed there. After lots of reading I can not understand posts that are obsolete and posts that are not so I would appreciate if someone can explain me the basics and optimal setup for incubus superfroyo RLS14/15 roms:
I have now 4 partitions:
1) fat32,
2) 1,5G ext2 (app, app-private etc),
3) 1,5G ext2 (lost+found folder) and
4) 96M lynux-swap.
- How can I turn ext2 to ext3? do I need to do so? I have also read about ext4. Upgrading to ext3/ext4 applies to my 2) partition, to my 3) partition or to both? will I loose data stored? "there is no ext3/ext4 fs because there isn't the support on the compiled kernel. Ext3/ex4 are journal file system so are bad for limited writing device like nand or sd and thre is no good rease to use it" answered by l1qd1.
- How can I check if my lynux-swap is enabled and used by the rom?
- Do partitions 2) and 3) really need to be <1,5 G? why so?
- Can I take apk from apps folder in partition 2) in case I want to keep them for future fresh installs?
- What is lynux-swap optimal size? a 1,5G partition would be worse than 96 M? Why?
- Which tools are you using with incubus roms to manage installaion location and similar functionalities?
Another big mark I have is about deoxeding installed aps (not belonging to the ROM). Should I do it? why? how?
Pretty basic stuff I guess for experienced users & programmers, but I am new to lynux and android. Have read lots of things but it is difficult to learn by myself what would work with our Polaris and incubus ROMS and dzo/kk kernels,
Stick to ext2 man, you won't turn your old engine to 240mph on a Ford Model T.
You're not getting some major boost if the hardware dosn't use it, so I'd stick with ext2.
And you also want Super FroYo on your ext2 partition, yes? I'm here to help.
- How can I check if my lynux-swap is enabled and used by the rom?
adb shell
Code:
free
if on swap you have 0 it isn't enabled.
Code:
swapon /dev/device
to enable it or i suggest you tu use compcache.
- Do partitions 2) and 3) really need to be <1,5 G? No
- Can I take apk from apps folder in partition 2) in case I want to keep them for future fresh installs? Yes but not all apk support this
- What is lynux-swap optimal size? a 1,5G partition would be worse than 96 M? Why? Too Big = more sparse but it's a problem only for real disk so you can create a swap big as you want but it's unuseful (100 M is enaught)
i suggest you to switch to my kernels because are more updated and kk move to another device.
Yah l1q1d I love ur kernels. Eager for more !
l1q1d, I am testing your kernel as you advised me. I could apply the wifi patch without problems using your androiupdate18-09-10, as you told me some time ago they are both 2.6.25.
However I do not manage to turn linux-swap on: that's what I do: I install ubuntu, I use G-Parted to create partitions on the sd card. When I do so, the third partition is always shown as linux-swap in G-Parted but when I test adb shell -> parted -> print, it always shows as ext2. I can not dismount and can not swap on it.
The other way round, if I deleted all partitions with G-Parted and create the partitions with mkpartsfs or if I use mkfs to change the third partition from ext2 to linux-swap, then sometimes I can swap on it (directly on adb shell or with G-Parted) but when I unplug the device will tell me the card is empty and will not be able to mount it, access it from ubuntu or from the device. If I reboot then, the system will hang until I install both data and sysetm to nand. This happens no matter if I activate or not from the polaris or even if I switch on or off usb mode. The card at that point is useless. I guess the partition table or some other basic file is messed.
Could you please explain a little more how can I come with a 13.5G fat32 partition, a 2,4 ext2 partiions and a 0,1 lynux swap swapped on partition??
I really need to test this set up, since with the standard set-up (system to nand, fat32 for files and ext2 for installed apps I can not install all apps I use since performance drops significantly).
regards
well, ... dumb me, maybe with compcache you are referring to launch a script?
where do I get this compcache.sh? how do I launch it? from adb? from the terminal? from the sd card?...

[Utility] ext4 data2sd for Froyo ROMs

If you are always low on program memory, this data2sd might be for you. It works with any Froyo for the G3.
Note: This won't wipe your data, but you should have a backup, just in case. First backup the phone to the SD card, then the SD card to your computer. Be cautious. I give no guarantee whatsoever. If your phone behaves funny, even eats your cat afterwards, I take no responsibility.
Note: starting with version 3, the new storage size will NOT be reflected in the Task Manager or in Titanium Backup. I'll see what I can do about it.
You need a rooted phone and an SD card, preferably 2 GB or more and class 6 or better (higher). data2sd doesn't make your phone faster. Much to the contrary: it extends your memory at the cost of speed. That said, if your SD card is of a class smaller than 6, this will work too. The slowdown, however, will be noticeable in some situations.
Three steps are needed. First, we need a kernel with built-in ext4 if you don't have one. Second, we bring the data2sd into its place. And third, we create an ext 4 partition with the desired size. Now follows a detailed description of these steps.
Step 1: Check your kernel
You need a kernel with built-in ext4 capability. The custom ROMs mostly have one. If you are running a stock kernel, you must install one, e.g. from http://forum.xda-developers.com/showthread.php?t=978823 . Follow the installation steps detailed there. (Changing the kernel does not wipe your phone).
Step 2: Install data2sd
You now must install data2sd onto your phone. As long as you didn't modify your SD card (as long as partition #2 is not ext4), this will have no further impact on your phone.
Download data2sd.zip from below and unzip it. There's a single file in there: data2sd.sh. Use the tool that suits you best to transfer it to the SD card of your phone. With adb, you would do
Code:
adb push data2sd.sh /mnt/sdcard
Now either start a terminal emulator with a root shell or use adb again. With adb, you would execute
Code:
adb shell
Make sure you are root (the prompt reads '#'), else run "su". Now type in:
Code:
# sh /mnt/sdcard/data2sd.sh
You will see some lines about what is happening and a final confirmation.
That's it. Again, your phone will continue to behave as usual.
Step 3: Prepare your SD card
You can use any amount of program memory up to the size of your SD card, but be sure to leave some room for application data on the normal (#1, vfat) partition. As a rule of thumb, 0.5 GB of program memory will satisfy most needs, 1 GB is plenty.
If you're running Linux, prepare a second partition (must be partition #2) with the desired size. Use the usual utilities to do so. This includes gparted, but there are also other means. If you use gparted, you can follow the description for Parted Magic below.
If you have no access to a Linux computer, even not your friend's, your (probably) best choice is to run Parted Magic from a live CD. For this, go to http://partedmagic.com, and burn your CD. Instructions on how to do it with different burning tools are also there.
Step 3.1: Partition and format your SD card with Parted Magic (also applies to gparted)
The following describes the steps to partition your SD card with Parted Magic. You don't need to use this method - use the tool that suits you best.
I assume you have gparted or Parted Magic running and your SD card inserted into the card reader of your PC. Now select your card from the drop-down menu of available drives in the upper right corner. You better double check that you're on the correct drive (card). It will happily erase your system disk if told to do so.
Right click near top into the block designating your current partition #1. Select "resize". (I assume that your partition #1 is the only one. If not, delete the other partition(s)). Change the size to the total size of your SD card minus the desired size for program storage (/data). Confirm your selection.
There is now a gray block designating free space to the right of your first partition. Right click it and select "New". In the following window, leave the sizes as they are. Leave "create as" to be a primary partition, and change "file system" to ext4. Confirm your selection ("Add").
The gray block at the right has changed to a colored frame. Right click it again and select "Format as". Select "ext4".
If everything went well, you can now click on the green check mark in the icon bar near the top, confirm, and watch Parted Magic resizing your normal (#1, VFAT) partition and creating the new ext4 one.
4. Finale furioso
Now insert the SD card and reboot your phone. The Task Manager will report the new size in its rightmost tab, as do the other utilities like Titanium. All user apps and data should be in place. All will look like you have soldered in an extra chunk of internal memory. Despite not being directly visible, your program memory is resized to be the new partition. You see its size and its usage (in percent) by running
Code:
df
from adb or from a terminal emulator. Have a look at the subdirectories of /data displayed there.
As a final step, you can safely remove data2sd.sh from your SD card (/sdcard). It is not needed any more.
Q&A
* How can I remove my SD card while the phone is on?
You can't. Don't try. Always switch your phone off before you remove the SD card.​* How can I return to the state before data2sd?
Remove the SD card. All user data and apps will be there in the state you left them before you installed data2sd. The data2sd script you have installed simply does nothing as long as there is no ext4 #2 SD partition.
If you want to reuse the SD card, remove partition #2. This can be done with each partitioning tool, you don't need Linux.​• What about app2sd from Kyrillos 3.0? Is it compatible?
Yes. But "no" for the "no wipe" version which was offered for a short period of time. In the latter case, clear out the ext4 partition (important: do not forget the hidden .data2sd_initialized file) or simply reformat it before reusing it.​* It doesn't work. What can I do to help diagnose the problem?
See if the file /mnt/asec/data2sd/log.txt exists. If it does, have a look at it and try to make sense of it. If it doesn't tell you anything useful, add it to your error description in the forum here. If there is none, mention that in the description.​* What things must be considered if I flash a new ROM?
As always with such actions, make sure you have a backup. That said, just flash the new ROM and then install data2sd. When you reboot with the SD card in place, all user Apps and all data should be there. No restore from backup required.
Only in the rare case that the new ROM explicitly requires you to NOT restore your old data, e.g., from Titanium, you should reformat your ext4 partition (to clear it out) and proceed as advised by the ROM makers.​Versions:
2011-03-19 Initial release
2011-03-21 Version 2
- Updated for ROMs without /system/etc/init.d
- Simplified installation of the core parts
2011-03-23 Version 3
- Vibration bug fixed
- App2SD mode added: If the ext4 partition bears the volume label "app2sd" on a new blank SD, only /data/app is moved. This greatly reduces size benefits, but results in nearly no speed loss.
- Just run the data2sd.sh file (as described in step 2) to upgrade without data loss.
- Note: the actual size will NOT be reflected as described in the Task Manager or in Titanium.
Gosh this sounds so complex and risky! Isn't there a easier way?
☞★sent from my Galaxy3!!
♪drajax!! ♬♂ツ
drajax said:
Gosh this sounds so complex and risky! Isn't there a easier way?
☞★sent from my Galaxy3!!
♪drajax!! ♬♂ツ
Click to expand...
Click to collapse
Flash Kyrillos' v3.1 where's the script's allready built in...
It is less complex than it sounds. The description is just really very detailed. The details may sound confusing until you try it. And if you have access to Linux, it is really simple. We Linux users also have to use a different operating system when we flash our phones.
Alternative: Install Kyrillos 3.1. It contains the same data2sd and comes with a partitioning tool. But, as far as I can tell, you need to reformat the SD card's vfat part on the phone and lose the data there (not sure, however).
when i try to set permissions it says permission denied . Any help?
http://www.appbrain.com/app/move2sd-enabler-(root-only)/com.leinardi.setinstalllocation
Just one quick question....
I am having the stock JPM ROM... in that case do i need to have some new Kernel to use your data2sd???
I'll be using this!
Sent from my ACID Lestatious v1.4.5.5 Galaxy 3 FROYO
When i write down "/ # cd /system/etc/init.d/"
it says "sh: cd: can't cd /system/etc/init.d/"
What am i doing wrong???
Pinak.ahuja said:
when i try to set permissions it says permission denied . Any help?
Click to expand...
Click to collapse
You're not in a root shell. Enter "su" as your first command.
next2devil said:
When i write down "/ # cd /system/etc/init.d/"
it says "sh: cd: can't cd /system/etc/init.d/"
What am i doing wrong???
Click to expand...
Click to collapse
Don't know. Try this:
cd /system
cd etc
cd init.d
and report where it fails and if you are using adb or a terminal emulator. If it doesn't fail, continue with the line after the cd command.
Awesome work mizch!
We can refer to below link for partitioning of sd card to ext4 using adb
http://forum.xda-developers.com/showthread.php?t=534714
Hi Mizch,
Thanks for the script. have few questions; requesting for an answer:
1. Once data2sd is done, will sd card be auto mounted on reboot?
2. I am running JPM with Apollo's data2sd (ext2 partition for apps 1.1GB). What will be the benefit of ext4 over ext2?
3. I understand that i have to remove apollo's lagfix and then apply ext4 data2sd. Is there a way, i can also apply lagfix?
Thanks
jaskiratsingh said:
Hi Mizch,
Thanks for the script. have few questions; requesting for an answer:
1. Once data2sd is done, will sd card be auto mounted on reboot?
Click to expand...
Click to collapse
Yes. And for the first boot, it gets initialized too.
2. I am running JPM with Apollo's data2sd (ext2 partition for apps 1.1GB). What will be the benefit of ext4 over ext2?
Click to expand...
Click to collapse
Reliability, especially in crash cases and generally when the phone is shut down without a clean unmount. Ext 4, being a journaling file system, tries to keep the file system in a consistent state whenever possible. ext2 does nothing like that. So, when you forcible switch off your phone by long pressing the power button, most likely you are continuing with a damaged file system whose errors accumulate from now on and will eventually become visible at some time later.
There's one drawback, however: ext4 has to write more data than ext2. ext4 must always write the information needed to reconstruct a consistent file system to its journal.
3. I understand that i have to remove apollo's lagfix and then apply ext4 data2sd. Is there a way, i can also apply lagfix?
Click to expand...
Click to collapse
If I'm correct, the lagfix converts /data (your program storage) to ext2. Since /data is now handled by data2sd and converted to eyt4 anyway, you cannot use lagfix any more. You need to remove it.
mizch said:
If I'm correct, the lagfix converts /data (your program storage) to ext2. Since /data is now handled by data2sd and converted to eyt4 anyway, you cannot use lagfix any more. You need to remove it.
Click to expand...
Click to collapse
Thanks for the quick reply mizch. If i have to check apart from data, if anything else is converted into ext2, how can i do that?
jaskiratsingh said:
Thanks for the quick reply mizch. If i have to check apart from data, if anything else is converted into ext2, how can i do that?
Click to expand...
Click to collapse
have a look at the output of 'mount' or 'busybox mount'.
rm 02-app2sd for who use kyrillos ROM...i didn't do that command..but it seems works fine...what does it change if i use that command???
mizch said:
Don't know. Try this:
cd /system
cd etc
cd init.d
and report where it fails and if you are using adb or a terminal emulator. If it doesn't fail, continue with the line after the cd command.
Click to expand...
Click to collapse
I tried what you mentioned.... but again it shows the same error. It works well till "cd etc". Then, for init.d it shows out the error.
It seems the location for init.d is different in my device
next2devil said:
I tried what you mentioned.... but again it shows the same error. It works well till "cd etc". Then, for init.d it shows out the error.
It seems the location for init.d is different in my device
Click to expand...
Click to collapse
Yes. Probably there is none. What ROM are you using? Is it a Froyo ROM and from where?

[MOD] 1-Click Flashable exFAT + NTFS + EXT4 support for CM10.1/AOSP + Partitioned SD!

August 4th 2013 - This script has not been maintained in a while. A big thank you to Captain_Throwback for providing continued support.
This is now minimally supported. Now that CM is adding native NTFS/exfat support, the only thing my script handles is multiple partitions.
July 21 2014 - Thank you n01ce! Please see n01ce's post for a "6.5 Alpha" that may solve some checksum problems with exFAT. I have changed devices, so this thread is for historical purposes/legacy support.
"HELP! I accidentally made my exFat card unreadable!!" -- or-- "I can't see more than 1 partition in windows!!"
Please read the instructions at the bottom of THIS POST HERE. No data will be lost!
"My card was working up until a moment ago but now the phone is showing "card damaged!!"
Re-run the script by typing "fuse-mountsd.sh" as root. The script will attempt to repair and re-mount.
If that fails, run "chkdsk /f" in Windows. Do not reformat until it is the last resort!​
TL;DR: (Flash this), put exFat/FAT32/NTFS/EXT4 sdcard in, reboot.​To remount, type "fuse-mountsd.sh" in a console (or) run using RomToolbox Lite (in /system/xbin/)
Needs to be run every time card is ejected + reinserted -- including when UMS is used
To unmount, type "fuse-mountsd.sh umount" (or if 1 partition) use Storage Manager
Non-customized multi-partitions mounted in /storage/<their name>
​
Uses init.d to fix/mount at boot
Scans for/mounts all useable block devices (with safety checks)
User-specifiable dynamic mount points
~~Create a ".mounthere" file in the partition with the first line "/location/to/mount/at"
~~Use the first line "skip" or "SKIP" to bypass that partition
Rescans for media when you re-mount
Repairs typical exFat damage caused by CM10.1 (with safety nets)
FAT32 support
NTFS-3g support (noatime set to reduce wear)
EXT4/3/2 support (*fuse built into JB/CM10.1) <- (MTP+EXT4 permissions need to be set to media_rw:media:rw 775!!))
Cleans up after itself: disables/enables ADB/root-security to what you set
BUGS:
All -- ntfsfix does not work. Binaries need to be recompiled. Not a major issue only dead weight.
exFAT may prevent deep-sleep. (NTFS on GS3 doesn't seem to have this issue.)
If you use EXT4/3/2, you need to run the following commands to allow the card to be accessed by the mobile-user:
Code:
find /storage/sdcard1/ -print0 | xargs -0 chown media_rw:media_rw
chmod -R 775 /storage/sdcard1/
(or)
find /storage/sdcard1/ -print0 | xargs -0 chown root:media_rw
Other phones -- Post a debug.txt if it works for you.
CM10 (4.1.x) -- Support is experimental. Use at your own risk.
CM 10.1 (4.2.x) -- Implemented RSA Key Signing Fix, works with BOOTICE.exe partitioned cards.
EXPERTS:
Everything is softcoded thanks to the $SECONDARY_STORAGE, $ANDROID_DATA, $ANDROID_STORAGE, $ANDROID_CACHE env variables and get/setprop command. Some locations are hardcoded in the script's "analyzePhone" function as fallbacks.
To custom-map mountpoints, create a ".mounthere" file in the root of each partition. "skip" or "SKIP" = ignore partition at mount, "/your/path/here" will use that path (or the default if bad). Defaults to "$ANDROID_STORAGE/device_id" if directory is invalid. Removes any temporary directories (in /storage/ only) at unmount. YOU HAVE TO CREATE ANY CUSTOM DIRECTORIES OUTSIDE "/storage" YOURSELF -- I set it like that as a security precaution.
To disable "Directory Creation Security", edit the line at the top of the script to say "dirSECURITY=0". This script will remount / and /storage as RW if needed.​
Here is a quick rundown of typical use-cases:
You want one large (exFat/NTFS/ext4) partition:
No customization needed, just flash and go
You want a small FAT32 partition (p1) at the beginning (for firmware/CWM/TWRP) with another big ext4 partition (p2) for your SD card mount. [ Your ROM's vold will mount (p1:fat32) as /storage/sdcard1 automatically. To get it to swap over: ]
Create a ".mounthere" file on (p2) "big" partition with the text "/storage/sdcard1"
This will override Vold and mount the (p2) as external storage. The FAT32 partition will be mounted in /storage/mmcblk1. If you want to mount it elsewhere (even /data/media/0/extSD ! ) simply add another ".mounthere" on the FAT32 partition. (The directory must already exist -- you must make it beforehand -- or disable Directory Security feature.) Be warned - Vold will mount the first partition as /storage/sdcard1 any chance it gets -- even in the background -- unless there is something mounted there already (by this script).
You have (1) partition for a game app you play (internal storage) that you want to rebind, (2) another part you want to rebind OVER an existing directory, and (3) your main storage.
Create a ".mounthere" on (1) with text "/location/of/your/game/app/data"
".mounthere" on (2) with text "/folder/you/want/substituted"
".mounthere" on (3) with text "/storage/sdcard1"
You are a long-hair-hippie Linux developer with 4 partitions, each in a different filesystem, and want them mounted hidden from apps and listed by block device so you know what partition you are on:
No customization needed, just flash and go
SUPPORT:
I can only provide support if you supply me with logs. Do so by typing "fuse-mountsd.sh > /sdcard/debug.txt 2>&1" and opening the Debug.txt in your phone's storage.
It's all automatic now - so if it mounts your modem as writeable and kicks your dog don't blame me. (It excludes dangerous block devices automatically [mmcblk0, /system, mtdblock, etc], but there is always a 1% chance it will miss something.) If it does, report it here so I can fix it.
If you intend to use this with a other ROMs/phones, IT SHOULD STILL WORK. Post any errors or weird behavior.
Code:
Changelog
[I]7.0 - TBA (Make GUI? Fix ext4 permissions automatically? Get paid?)[/I]
6.4 - No longer uses "mount" output (wasn't acting standard-ly. Using /proc/mounts instead)
- [COLOR="Red"]Got rid of conv=notrunc[/COLOR]. Be careful!
6.3 - Bugfix to scrubMount code
6.2 - No longer Experimental / final unstable
- added rough ext2/3 support
6.1 - mount command bugfix
6.0 - Added a bypass for Directory Security, fixed some bugs.
5.9 - Rewrote NOGO code from scratch -- UUIDs ignored
5.8 - (??)
5.7 - Support for Note2 formatted exFat cards + more (0xf4 bug)
5.6 - bug fixed: no longer detects zram/assumes multimount
5.5 - [COLOR="Red"]Experimental support for weird devices[/COLOR]
5.4 - [b]Major bugfix!![/b] Fix fixmyexfat.sh coding fail
5.3 - Fixed "vffat" support. Undid HARD QUIT on bad Nogo, made it a soft one.
5.2 - Increased logging of tables, HARD QUIT if Nogo not found
5.1 - Quick patch to fix dm-* device blacklist
5.0 - [b]SUPPORTS MULTI-PARTITIONED CARDS! Autoscans for block devs! Complete rewrite![/b]
4.1 - Quick patch to check mmcblk1
4.0 - [B]WORKS 100% ON 4.2.2!![/B] My script is the first to achieve this AFAIK
3.3 - fixed a bug detecting existing mounts (related to "non-persistent mount points" issue)
3.1 - added dynamic exFAT repair code
3.0 - added NTFS/ext4 support
1.0 -> 2.0 <Removed>
Attribution credits:
Original thanks go to originator of the method, smitna in the Galaxy S2 forum. Additional thanks go to shardul_seth (Post 23) for compiling the latest version of the fuse-exfat and ntfs-3g binaries for ARM, and of course Andrew Nayenko for his efforts in creating GPL'd exFat code (fuse-exfat on google code).
[HOWTO][exFAT][WORK IN PROGRESS] Mount exFAT formatted drives and cards - smitna
Full NTFS Read Write support for Android (ARM) - shardul_seth
[HOWTO][exFAT][CM10.1] Working 64GB ext sdcard with fuse-exfat (1.0.1) + FIX broken (my original Dev thread)
I believe the term is I "kanged" their binaries. The rest is mine. This is a "mod"/"hack" until CM adds native support. (If ever: exFat)​
DONATIONS:
https://supporters.eff.org/donate , or help a noob by linking to a solution in their thread. :good:
https://plus.google.com/+CyanogenMod/posts/ib5wz8jk1JyOne of the CM Team has flesh eating bacteria! Keep CM alive! (Literally)​
I'm a noob, this looks scary to me. Either way, I needs me some exfat cuz my movies are too large for fat32.
My only question is: Even though this is written for CM10.1 on Verizon s3, might this also work on T-mobile s3 with an AOSP (Android 4.2.2) ROM?
Here's what I'm running:
SGH-T999 (d2tmo)
Android 4.2.2
Kernel: 3.0.62-cyanogenmod-g137df31
ROM: Liquid-JB-v2.1-RC1
Build:liquid-d2tmo-userdebug 4.2.2 JDQ39
I've spent the last 2 days searching and testing to no avail. My sdcard is running hot trying to get files larger than 4gb on it. I've tried formatting to exfat, ntfs, ext4, even hfs+, no success. Paragon and ntfssd apps couldn't mount it either.
Any help on this matter would be greatly appreciated!
Even though this might not work on T-mobile, thank you either way, I'm glad there are people like you developing for 64gb cards.
I wouldn't say I'm a developer, just a scripter with a lot of time on her hands.
lordazoroth said:
My only question is: Even though this is written for CM10.1 on Verizon s3, might this also work on T-mobile s3 with an AOSP (Android 4.2.2) ROM?
Click to expand...
Click to collapse
MAKE A NANDROID. This mod should do nothing permanently harmful anyway: it looks for EXFAT before writing anything.
Carrier doesn't matter. It only depends (1) if your kernel has FUSE support, (2) if it has init.d support and (3) what your Block device is.
I think Google added FUSE by default in JB, and anything based off CM10.1 will have it
Type "echo $SECONDARY_STORAGE" in a terminal emulator. If it displays ANYTHING other than blank it should work.
The Block device is trickier. Type "blkid" as root with with your FAT32 card in and out. The one that disappears is your Card's Block device, and should be /dev/block/mmcblk1p1.
If you have any doubts, don't do it.
HMkX2 said:
I wouldn't say I'm a developer, just a scripter with a lot of time on her hands.
MAKE A NANDROID. This mod should do nothing permanently harmful anyway: it looks for EXFAT before writing anything.
Carrier doesn't matter. It only depends (1) if your kernel has FUSE support, (2) if it has init.d support and (3) what your Block device is.
I think Google added FUSE by default in JB, and anything based off CM10.1 will have it
Type "echo $SECONDARY_STORAGE" in a terminal emulator. If it displays ANYTHING other than blank it should work.
The Block device is trickier. Type "blkid" as root with with your FAT32 card in and out. The one that disappears is your Card's Block device, and should be /dev/block/mmcblk1p1.
If you have any doubts, don't do it.
Click to expand...
Click to collapse
Awesome instructions, very much appreciate it. Looks like it's time to get to work. I checked the zip file thoroughly and cross-checked it with my root directories to see if it overwrites anything and it looks like it just adds stuff. From what I've seen, this is the only game in town so I'll post back once I'm done.
If this does work, this is a godlike zip file and it does something nothing else can do right now
Ok still not mounting properly.
Here's what I did:
Typed "echo $SECONDARY_STORAGE" in a terminal emulator, showed "/storage/sdcard1"
Typed "blkid", showed "/dev/block/mmcblk1p1" only when sd card was inserted under fat32 file format
Formatted sd card to exFAT on PC, inserted back into s3
Flashed CM10.1_exFAT-mountsd_2.0_HMkX2.zip
Ran terminal emulator, typed su >> exfat-mountsd.sh got this:
[email protected]:/ $ su
[email protected]:/ # exfat-mountsd.sh
[exfat-mountsd v2.0] exFat autorepair and mount script for CM10.1 (HMkX2 CORE//XDA)
Automated mounting script for exFat on GS3
/storage/sdcard1 is not mounted. (OK)
Calling [fixmyexfat] on /dev/block/mmcblk1p1 (if needed)
Broadcasting: Intent { act=android.intent.action.MEDIA_CHECKING dat=file:///storage/sdcard1 }
Broadcast completed: result=0
[fixmyexfat v2.0] exFat header repair tool (HMkX2 CORE//XDA)
More robust than before!
Usage: /system/xbin/fixmyexfat.sh <block device, eg /dev/block/mmcblk1p1>
[fixmyexfat] Manual target is /dev/block/mmcblk1p1
1+0 records in
1+0 records out
512 bytes transferred in 0.166 secs (3084 bytes/sec)
Segment 1 (0:4) (BAD)
4+0 records in
4+0 records out
4 bytes transferred in 0.012 secs (333 bytes/sec)
Segment 2 (484:4) (BAD)
4+0 records in
4+0 records out
4 bytes transferred in 0.007 secs (571 bytes/sec)
Segment 3 (508:4) (BAD)
4+0 records in
4+0 records out
4 bytes transferred in 0.005 secs (800 bytes/sec)
Check complete!
Check complete, mounting and initializing...
########################## ATTEMPTING COMMAND ##########################
mount.exfat-fuse -o rw,dirsync,umask=0 /dev/block/mmcblk1p1 /storage/sdcard1
Attempting bypass...
* daemon not running. starting it now on port 5038 *
* daemon started successfully *
connected to localhost:5556
List of devices attached
localhost:5556 device
Running ADB commands
FUSE exfat 1.0.1
ERROR: invalid VBR checksum 0xa04b8eb5 (expected 0x804d6ce4).
Broadcasting: Intent { act=android.intent.action.MEDIA_MOUNTED dat=file:///storage/sdcard1 }
Broadcast completed: result=0
Process complete!
[email protected]:/ #
Not sure how to read this...
Afterwards my notification panel says: "Damaged SD card : SD card is damaged. Try reformatting it."
Tried restarting s3, mounting in storage settings, reformatting in PC. Ran script 4 times on a fresh exFAT format with the same notification error (format was unrecognizable by s3 and PC after running terminal command "exfat-mountsd.sh" [don't worry didn't lose any data ]).
After each format to exFAT on my PC I placed a few images on the card to ensure it was functioning properly, /storage/sdcard1 directory is always empty.
Mounting in settings >> storage generates the same notification error: "Damaged SD card : SD card is damaged. Try reformatting it."
Any ideas?... it is detecting an SD there after mount attempts (despite exFAT format) interestingly enough. Though nothing is detected after a reboot unless another script or settings >> storage mount attempt is performed.
I should mention that I ran a "quick" format when formatting the SD card from Fat32 to exFAT, not sure if that might be relevant.
Hm... well, I can tell you what it means. Quick formatting is fine, I actually prefer it since flash memory has a limited life. Second, "chkdsk /f" in windows will repair your card + data -- the card isn't "damaged", it's just that 4 letters at the beginning were changed. (See: Segment1, Segment2, Segment 3 messages.) My scripts change those 4 letters back, in a safe-ish way.
Unfortunately, without having a hex-dump of your working exFat header I can't say what those four letters should be. I got mine using a program called Hex Editor Neo on what I had available, a Sandisk 64gb class-10, and are what I included in the script. When the letters don't line up like it expects, you get a checksum error.
Without that, there is one single thing you can try - but has a high likelyhood of success.
Use RootBox explorer, navigate to /system/xbin/ and DELETE the file called "fixmyfat.sh".
Turn your phone OFF. Eject the SD card
chkdsk /f the card or quick format it to fix it, put a test file on it from Windows
Put the card in your phone, turn on.The card must be in the phone before it is turned on.
If that works for you, and the card works, you can give me a hex dump pretty easily so I can edit the script. IF it works, and I highly suspect it will, get a hex dump by typing EXACTLY:
dd if=/dev/block/mmcblk1p1 bs=1 count=512 of=/sdcard/working_sd.bin​ <- corrected
That will place a text file in your internal sd card than you can post/send me. Again, thanks for bearing with me, this started out as something for myself then made better in the hopes other people could use it. If you could re-corrupt the card (by unplugging/replugging it while the phone is on) and send me a hex dump of the "Card Damaged" state, even better.
O.O... you are awesome!
I'll get on this right away, and I'd be happy to help any way i can
---------- Post added at 09:19 PM ---------- Previous post was at 08:52 PM ----------
OMG IT WORKS!!! the card mounted
I tried the line of code and it gave me an error:
[email protected]:/ $ su
[email protected]:/ # dd if=/dev/blk/mmcblk1p1 bs=1 count=512 of=/sdcard/working_sd.bin
/dev/blk/mmcblk1p1: cannot open for read: No such file or directory
1|[email protected]:/ #
My /sdcard directory seems to be a redirect to /storage/sdcard0 (i think), i have a lot of these (what appear to be redirects) on my phone now after upgrading from android 4.0.4 to 4.2.2. If I changed the end of that line of code to something like "of=/storage/sdcard0/0//working_sd.bin" (or any similar working directory), might that solve the problem or am I reading that wrong?
Thank you so much, this is... very powerful!
Great work on this!
Double post.
Please check my post for the correct DD command - I typed /blk instead of /block due to habit.
I'm glad it works. As long as you don't re-plug the card while it is on, you will have no problems. If you accidentally DO "corrupt" the card, just "chkdsk /f" in Windows, turn the phone off, put the card in, and turn it on.
And the biggest help you can give would be those headers. (I was looking at the exfat.fsck-fuse code, apparently even THAT can't fix it!) For the time being, I will re-do the scripts to display more information so I can troubleshoot more easily.
HMkX2 said:
Please check my post for the correct DD command - I typed /blk instead of /block due to habit.
I'm glad it works. As long as you don't re-plug the card while it is on, you will have no problems. If you accidentally DO "corrupt" the card, just "chkdsk /f" in Windows, turn the phone off, put the card in, and turn it on.
And the biggest help you can give would be those headers. (I was looking at the exfat.fsck-fuse code, apparently even THAT can't fix it!) For the time being, I will re-do the scripts to display more information so I can troubleshoot more easily.
Click to expand...
Click to collapse
Sounds bad, I don't know why all these companies are sticking with Fat32 after all these years. Fat32 has been obsolete since like 2000, don't we have open source formats like ext4 now? - that's my rant lol. Either way, it works and I got the file. Btw, this file acts strangely on my device, I couldn't see it in windows explorer during plugin and It wouldn't copy to my sd card even though other files seem to be copying fine. Had to email it to myself from my phone. Thank you so much for all your help, let me know if you need anything else
Rename the file and remove .rar extension before use, xda doesn't allow .bin extensions to be uploaded.
Quick question: If I shut the phone down and pull the SD, can I turn the phone back on and use it without the SD while I load the SD up with files, then power off, re-insert the SD and power on again? (like will it automount again?)
Yay!
HMkX2 said:
Please check my post for the correct DD command - I typed /blk instead of /block due to habit.
I'm glad it works. As long as you don't re-plug the card while it is on, you will have no problems. If you accidentally DO "corrupt" the card, just "chkdsk /f" in Windows, turn the phone off, put the card in, and turn it on.
And the biggest help you can give would be those headers. (I was looking at the exfat.fsck-fuse code, apparently even THAT can't fix it!) For the time being, I will re-do the scripts to display more information so I can troubleshoot more easily.
Click to expand...
Click to collapse
Very interesting. I can go on the hunt for headers if you like. I have loads of sd cards.
Oddly enough, I switched to FAT32 even though I'm on a TouchWiz ROM, cause exFAT does not use alternating file allocation tables. When exFAT gets borked, it gets super borked and you have to use chkdsk (or some other brutish method) to retrieve files. When FAT32 gets borked, you can load the last table that was working and elegantly pull your files off the card (no need to muddle through a pile of chkdsk files and find the correct extensions).
Any possibility that this method could be used to mount a more robust file system like ext[2,3,4]? Journaling would be nice. Or some transaction safe file system.
Ta very much,
ALQI
Re: [MOD] Flashable exFAT support for CM10.1 / AOSP roms (external SD)
Great.I'll try it.
Sent from my SCH-I535 using xda premium
lordazoroth said:
Sounds bad, I don't know why all these companies are sticking with Fat32 after all these years. Fat32 has been obsolete since like 2000, don't we have open source formats like ext4 now?
Click to expand...
Click to collapse
Why we have 15 competing standards... "Never attribute to malice that which is adequately explained by stupidity."
Btw, this file acts strangely on my device, I couldn't see it in windows explorer during plugin and It wouldn't copy to my sd card even though other files seem to be copying fine.​Any files you create on the device without "Rescanning for media" will not be visible in the MTP (Mass Tranfer Protocol) "MP3 player-like" abstracted FUSE filesystem. (One reason why people want UMS (USB Mass Storage) "hard drive-like" support, you see things immediately/it's faster.) Get a free program called SDrescan from Google Play, or run the command below(?), to update the MTP index and see files you create ON the device.
Code:
am broadcast -a android.intent.action.MEDIA_MOUNTED -d file://$SECONDARY_STORAGE
am broadcast -a android.intent.action.MEDIA_MOUNTED -d file:///storage/sdcard0
...let me know if you need anything else Quick question: If I shut the phone down and pull the SD, can I turn the phone back on and use it without the SD while I load the SD up with files, then power off, re-insert the SD and power on again? (like will it automount again?)​Yes, the mount script will simply fail and there will be a silent error. (I need to code some error checking if you insert a non-exfat card...)
Like I said, if you could intentionally re-corrupt the header by using Storage Manager to "Unmount SD" then "Mount SD", then the DD command, (and rescanning media to copy the file off!) I'd appreciate it. Although, I have a second idea of how to get around that problem in mind.....
alquimista said:
Very interesting. I can go on the hunt for headers if you like. I have loads of sd cards.
Click to expand...
Click to collapse
Thanks but I think the bottom line is (1) there is no working open source exfat.fsck anyway and (2) headers are unique per-device. The proper fix is re-coding vold to not run fsck.msdos on a fsck.exfat card.
Oddly enough, I switched to FAT32 even though I'm on a TouchWiz ROM, cause exFAT does not use alternating file allocation tables. When exFAT gets borked, it getse that wa super borked and you have to use chkdsk (or some other brutish method) to retrieve files. When FAT32 gets borked, you can load the last tabls working and elegantly pull your files off the card (no need to muddle through a pile of chkdsk files and find the correct extensions).
Any possibility that this method could be used to mount a more robust file system like ext[2,3,4]? Journaling would be nice. Or some transaction safe file system.​Yep, that is all 100% true. But I've lost files on fat32 drives as well - and I'd hardly call multiple file tables elegant, especially when they become desynced. NTFS would be a better fix, except for the fact it is a magnetic-media filesystem with journaling/timestamps/excessive writes, and exFAT was designed for flash media in the first place!! Even EXT4 writes too much, EXT2 or EXT4 with journaling disabled is a better solution for integrity, but much worse for flash-life. Nowadays, the value of error-recovery outweighs the limited media life. (This discussion comes up a lot in custom Linux firmwares for routers: DD-WRT NVRAM/Flashdrives)
Shardul_seth, the gentleman that compiled these binaries, has made a package for full NTFS support already using ntfs-fuse3g. (<- link) NTFS-3g is very mature/stable at this point, and installation for our devices is even simpler since we already have FUSE support in the kernel. However, his scripts are to mount USB, not the SD card. Mine does the SD card - all those ADB workarounds - so absolutely could be adapted for mounting NTFS cards. I will work on that when I have some time -- I'd need to figure out how to identify a NTFS card on header alone.
Again, all these methods are HACKS, proper support should be added in the kernel at some point. Someone actually has, and I've been cheering for him. He added EXT4 support to CM10.1, his post and code are here. However, he says it "stalled in code review". For the time being, you have to do all this manually.
Why we have 15 competing standards... "Never attribute to malice that which is adequately explained by stupidity."
Click to expand...
Click to collapse
Nice post lol, I only meant why FAT32 of all choices, these companies must know we're gonna be packing large files at some point, why knee cap us at 4gb when so many formats don't? Universal would be nice but of course it's entirely impractical
Any files you create on the device without "Rescanning for media" will not be visible in the MTP (Mass Tranfer Protocol) "MP3 player-like" abstracted FUSE filesystem. (One reason why people want UMS (USB Mass Storage) "hard drive-like" support, you see things immediately/it's faster.) Get a free program called SDrescan from Google Play, or run the command below(?), to update the MTP index and see files you create ON the device.
Click to expand...
Click to collapse
Thanks for the media scan info, that'll help a lot, I'll try out your suggestions tonight
Yes, the mount script will simply fail and there will be a silent error. (I need to code some error checking if you insert a non-exfat card...)
Like I said, if you could intentionally re-corrupt the header by using Storage Manager to "Unmount SD" then "Mount SD", then the DD command, (and rescanning media to copy the file off!) I'd appreciate it. Although, I have a second idea of how to get around that problem in mind.....
Click to expand...
Click to collapse
Will do, sounds interesting, will there be data loss or just header corruption? second idea in mind?
Also, each time I take the card out of my phone (properly after shutdown of phone) and place it in my computer (vista 64bit ultimate) It asks to check for errors, i'll click continue (confirmation to check), takes 3-5 seconds, finishes with no errors found. If I don't do this the card is write protected. I've made sure only to disconnect from PC after "safely removing hardware" so it appears that usage in the phone is generating the confusion. This doesn't seem to be an issue but I thought it might be worth mentioning
do you enter it correctly?
I get this when running the script:
Code:
BREAK! /dev/block/mmcblk1p1 is not a block-special file/device, do you enter it correctly?
How do I find what block file I need to change to script to?
Thanks for your work
boricua1213 said:
How do I find what block file I need to change to script to?
Click to expand...
Click to collapse
Safest (not easiest) way is to insert your FAT32 card, type "mount|grep vfat". The one you are looking for says "/dev/block/vold___:__" . (Shortcut: "mount|grep vold");
Then type "blkid". The one that's listed twice (UUID or Label) as "vold" is your block device's other name. (/mnt/block/mmc_somethingorother) Both names lead to the same spot.
(or)
Type "blkid" with your card in. Make a list. Remove your card. Type "blkid" again. The one that dissapears is your block device.
Ok got the file, I created 2 files, 1 before and 1 after the force unplug, just in case.
Remember to rename the files without the .rar extension before use
Re: [MOD] 1-Click Flashable exFAT + NTFS + EXT4 support for CM10.1 / AOSP (external S
I am about to embark on this journey and make another attempt at ditching TouchWiz. Does this script make it as if everything is normal as far as apps accessing the SD card go? I assume so, but I'm specifically wondering if I'll still be able to use Directory Bind and if I'll be able to create symbolic links to redirect Google Music to the external SD.
Getting ready to flash and try anyway but figured I'd ask to see if someone knows the answer all ready.
I'll be the first to admit the problem is almost certainly user error on my part but I have been wholly unsuccessful with this mod. I have tried it on Carbon Rom and Paranoid Rom. I guess they both have FUSE support, I couldn't find any confirmation of that on the Rom threads....particularly Carbon.
I flashed the zip in the OP in CWM after installing both Roms clean. I tried installing the zip as soon as I installed the Rom and I tried installing it after doing a full boot up first. Ran the chkdks /f command probably 12 times after each successive failed attempt to get my 64 exFAT card recognized. Said Damaged SD no matter what I tried. I saw the post on Page 1 about deleting the fixmyfat file....tried that too and no go. That tip may no longer be relevant since you've updated the script.
Is there something I am missing? There are lots of posts in this thread about mount commands and adb, but it seems from the OP none of those things are supposed to be necessary.
spearoid said:
Does this script make it as if everything is normal as far as apps accessing the SD card go? I assume so, but I'm specifically wondering if I'll still be able to use Directory Bind and if I'll be able to create symbolic links to redirect Google Music to the external SD.
Click to expand...
Click to collapse
In short, it should. However, exFAT/FAT32 don't support permissions/softlinks like ext4 does. So if you use ext4, just remember to set permissions appropriately! When in doubt, set permissions to 755 root:sdcard_rw or root:media_rw on the external sd.
I have tried it on Carbon Rom and Paranoid Rom. I guess they both have FUSE support, I couldn't find any confirmation of that on the Rom threads....particularly Carbon​Type "mount | grep fuse" in console. If you see "fuse" listed anywhere in the text, you have it. Google added it to JellyBean.
I flashed the zip in the OP in CWM after installing both Roms clean. I tried installing the zip as soon as I installed the Rom and I tried installing it after doing a full boot up first. Ran the chkdks /f command probably 12 times after each successive failed attempt to get my 64 exFAT card recognized. Said Damaged SD no matter what I tried. I saw the post on Page 1 about deleting the fixmyfat file....tried that too and no go. That tip may no longer be relevant since you've updated the script.
Is there something I am missing? There are lots of posts in this thread about mount commands and adb, but it seems from the OP none of those things are supposed to be necessary.​Do me a favor... open a terminal, type "su", then type "fuse-mountsd.sh > /sdcard/debug.txt 2>&1" (no spaces in 2>&1). It will make a "debug.txt" file in the root of your internal storage. Paste the output here. I am 90% certain you have the wrong block device set. 9% certain it is the 4.2.2 ADB thing.
You do not need to delete "fixmyfat.sh" -- those instructions are very old. Was the phone *physically off* when you plugged the SDcard in? Ignore the mount commands/ADB - you should not have to deal with them if you only plug in/unplug the card when the phone is off.
I am nigh certain it has to do with 4.2.2 messing with ADB. Like I said, for now, put in a *working* sd card *before* the phone is turned on and you won't run into that issue.

Categories

Resources