Develop Bugs

UBIFS: Any devs interested in migrating to this File System?

If dev is interested in migrating to this FS, Here is a kernel with UBIFS support, I have disabled ext3 since it don't fit the kernel but you can use ext2 with it. If we get full UBIFS support then I can disable yaffs.

i tried it several month ago but i did not manage to format the nand with that fs...
i tried in this way:
flash on nand
install data and system on sd (so i have free access to nand partitions)
try to format but i get errors...
(i'm sorry but i don't have the file and the logs anymore)

I also tried a few months ago, compiling the kernel with UBIFS support was the easy bit, it was altering the initrd as L1q1d has said which caused problems. I couldn't get the NAND partitions formatted so that android would boot for some reason. I gave up on it in the end because i didn't have the time to spend on it and still don't unfortunately. It does look like a promising file system though so if you can get it working Clemsyn, fair play to you The other thing was for it to work properly it needed the UBIFS tools package compiled into the kernel or included in the initrd which made the file size too large.

[DEV][Proof-of-Concept] Boot from SD on Optimus V

I've tested this and it works. I only have a class 2 SDcard, so my testing shows it's really slow, a faster card would probably help.
With just this class 2 SD card, the boot-from-sd process is really only useful to see if the ROM being tested will straight-up brick your device or not.
Edit!
A class 6 card works fabulous! I'm posting from a tweaked version of mmarz's port of ath3nos' port of cm7 running from my brand-new class 6 card right now.
This process is hacked together from multiple other devices' howtos here on xda, sorry I don't know who to credit for the bits and parts. All of it is pretty generic, actually, and might well be applicable to other devices when tried as a whole.
For the moment, I'm only posting a brief skeleton how-to without specific walkthroughs for the steps, and I don't really want to upload many files until more of the bugs are swatted.
The following info should be enough for you, the savvy dev, to put the ROM of your choice on your SD card and boot it (or watch it fail to boot) without risk of bricking your device!
noobs, don't you dare, bricking is always a risk if you don't know your way around fastboot and adb!
Of course, savvy dev or not, a fresh nandroid backup is MANDATORY before hacking at your phone like this.
Standard disclaimer:
There is always a possibility of bricking your phone when messing with adb and fastboot.
If you're not willing to take that risk, don't try this at home (or at work, or school....)
Here goes:
The basic plan I followed was:
1) make and format 3 extra ext2 partitions after the default fat32 on the SD card, in this order: data (at least 180Mb) , system (170Mb to match stock), and cache (102Mb stock).
2) split up the boot.img from your chosen ROM so you can mod the ramdisk.
edit: turns out this next step in the quote is not required, there is an easier way.
A nifty command called devwait for init.rc
3) compile a modified init, adding a "pause (5);" after the ANDROID text. It goes on line 569 in the gingerbread init.c from a recent repo of google source.
use the newly compiled init in place of the init from the ramdisk.
since getting the android source uses so much time and bandwidth, I'm being nice and attaching a modified gingerbread init. If you test it with a froyo ROM and it doesn't work, don't blame me. If it does work with froyo ROMS, let me know!
Click to expand...
Click to collapse
3) change your init.rc from the ramdisk as follows:
replace the "mount yaffs2 [email protected] /system" , cache, and data lines with
Code:
devwait /dev/block/mmcblk0p3
mount ext2 /dev/block/mmcblk0p3 /system nodev noatime nodiratime
mount ext2 /dev/block/mmcblk0p3 /system nodev noatime nodiratime ro
devwait /dev/block/mmcblk0p2
mount ext2 /dev/block/mmcblk0p2 /data nodev nosuid noatime nodiratime
devwait /dev/block/mmcblk0p4
mount ext2 /dev/block/mmcblk0p4 /cache nodev nosuid noatime nodiratime
be sure to comment out any other mounts which go to /system anywhere, like the "mount squashfs [email protected]/system/blahblah/blah.sqf /blah/blah" lines in the aospCmod init.rc
4) repack your boot.img, with the correct cmdline ("mem=477M console=ttyMSM2,115200n8 androidboot.hardware=thunderc" works,) etc.
5) prepare the ext2 /system partition with your target ROM /system files.
How to load the ROM:
steps a) to f) done on your PC. step g) is done on the phone.
a) Unzip the ROM on your PC, to get at the files to copy to the new /system directory in adb, and allow you to modify the updater-script.
b) Mod that ./META-INF/com/google/android/updater-script as follows:
As an example, I removed the following from the aospCmodOV-5-16-11 updater-script:
everything except the "ui_print" "symlink" and "set_perm" lines, including the "unmount" line at the end of the script.
I thinned it down because the update-binary wants to write to MTD partition for /system, and I didn't want or need that to happen.
I did need it to install the symlinks and permissions, though.
Without those, the keyboards kept FCing, and the phone couldn't connect to the network.
c) rezip the ROM with the modified updater-script.
d) boot phone into recovery and connect to PC with cable.
e) adb push or otherwise copy the modified ROM.zip to your sdcard.
f) next, copy /system from the unzipped ROM to the new partition with adb
Code:
adb shell
mount -t ext2 /dev/block/mmcblk0p3 /system
exit
adb push /path/to/unzipped/ROM/system /system
g) on phone, in recovery: install .zip from sdcard
select the new ROM.zip you reassembled and pushed to the SD card
select yes, you really want to install the .zip
this should write the /system symlinks and permissions to the new /system partition.
Click to expand...
Click to collapse
6) back on your PC, still connected to phone with cable in recovery;
Code:
adb reboot bootloader
fastboot boot /path/to/boot.img
Step 6 is important!
this will boot from your modified boot.img without actually flashing it into the phone's NAND, so a reboot (or restart after battery pull in case of issues) just goes to your regular installed ROM in the phone.
That's about it for now. It's pretty much a hack as yet, but it's cool in a geeky way to be able to do this.

<reserved for future use>

Thanks! This should be very helpful to devs and those of us who are adventurous with our phones!

Very interesting concept, I'd love to see how many uses this could have!

bump...
with a class 6 card, ath3nos/blarf cm7 runs great off sd.
even feels a little snappier than running from the phone mtd partitions.
I must benchmark soon to verify.
I'm really surprised no-one seems interested, I guess this is too old-hat, like a debian chroot

bigsupersquid said:
bump...
with a class 6 card, ath3nos/blarf cm7 runs great off sd.
even feels a little snappier than running from the phone mtd partitions.
I must benchmark soon to verify.
I'm really surprised no-one seems interested, I guess this is too old-hat, like a debian chroot
Click to expand...
Click to collapse
This is good work, but I think people require a bit more hand holding. How about publishing some of the modded files?
I personally still have problems recompiling a ramdisk.

mmarz said:
This is good work, but I think people require a bit more hand holding. How about publishing some of the modded files?
Click to expand...
Click to collapse
I can post files one rom at a time, because the ramdisk and kernel will be a bit different for each rom, and so will the permission/symlink updater-script.
first, I'll have to get rom-dev permission, because they get modded, and also cause it's nice to have permission.
I personally still have problems recompiling a ramdisk.
Click to expand...
Click to collapse
fastboot provides a fantastic shortcut for that, if you cpio-gzip the ramdisk together after editing it to your specs
from http://android-dls.com/wiki/index.php
in a command line linux shell, from the directory containing your unpacked ramdisk,
Code:
find . | cpio -o -H newc | gzip > ../newramdisk.cpio.gz
will put newramdisk.cpio.gz in the directory above the one containing your ramdisk
Click to expand...
Click to collapse
fastboot can make the boot.img for you and either dump it into the phone (assuming your shell current directory contains your kernel (zImage) and ramdisk (newramdisk.cpio.gz))
Code:
fastboot -c "mem=477M console=ttyMSM2,115200n8 androidboot.hardware=thunderc" flash:raw boot zImage newramdisk.cpio.gz
or boot your phone from the assembled image without actually flashing it in.
Code:
fastboot -c "mem=477M console=ttyMSM2,115200n8 androidboot.hardware=thunderc" boot zImage newramdisk.cpio.gz
those fastboot lines assume an optimus v (or s.)
looking at all the great work you've posted on the forums, I'm surprised you have trouble handling anything to do with these phones!
I'm slowly working up to a modded recovery to install-to-sd directly and avoid all this hacking.

Nice, thanks for that. I had no idea fastboot could do that.

mmarz said:
Nice, thanks for that. I had no idea fastboot could do that.
Click to expand...
Click to collapse
happy to share.
I only learned fastboot could do that when I seriously started in kernel testing after finally getting one to compile without errors. I didn't feel like bricking my phone to test the fresh kernel, and researching fastboot showed me its capabilities... I could've just typed fastboot with no arguments and that makes it list its parameters.
it's really helpful for this mod, because you can just reboot into your stock rom without having to reflash anything.
plus it's nice to just tweak the ramdisk and let fastboot do the work making a new boot.img for you when testing weird stuff like this.

bigsupersquid said:
happy to share.
I only learned fastboot could do that when I seriously started in kernel testing after finally getting one to compile without errors. I didn't feel like bricking my phone to test the fresh kernel, and researching fastboot showed me its capabilities... I could've just typed fastboot with no arguments and that makes it list its parameters.
it's really helpful for this mod, because you can just reboot into your stock rom without having to reflash anything.
plus it's nice to just tweak the ramdisk and let fastboot do the work making a new boot.img for you when testing weird stuff like this.
Click to expand...
Click to collapse
Very cool i loved this idea when it was executed in a way over at Ubuntdroid for the intercept when i was doing alpha testing. Very convenient for many of the scarier tests when i wanted to keep my existing system intact. The big difference was that on the intercept the bootable partitions were written into the kernel. Downside you couldn't use it to test kernels but could switch kernels from the phone and flip-flop between completely isolated systems on the go without a computer. Which was great when i wanted to test a new ROM on the way to work but i needed my phone when i got there and had to have a painless method of switching to my usual running system. So i'd flash a "non SD" kernel and i was back up and running in just a minute or so.
I'm excited to play with this when i have some free time.
Thanks dude!

you could easily use an update.zip for each of the sd-boot and regular phone boot.img files and swap between working systems with those in recovery.
before getting the fast sd card, I was looking at this more as for testing foreign roms than two-system operation, but now I see that would work too.
for a second-system option I was looking at a market-enabled rom on sd since I don't use g-apps on my daily driver.
note: the GB rom I'm running on won't 'see' a card with more than four partitions properly, and won't mount the vfat partition with vold, although you can manually mount and access the first four partitions including the vfat. android just won't admit it's there. and I couldn't get at a fifth partition through the phone os, even though my pc could see it fine (to get 5 partitions I had to use an extended partition to contain most of the virtual partitions)
android could read virtual partitions in an extended partition just fine as long as the total number on the card didn't exceed four.

I learned a neat trick today.
going through the init.rc from the stock rom, I noticed a section at the beginning which was labeled 'on emmc' which would imply running from a card if the device hardware lacked nand flash memory.
I'd read on xda while researching this concept of boot-from-sd about an unspecified wait-for-device command in init.rc, but most of the info I've gotten on init scripting language has come from picking apart init scripts, as google has not documented the available commands very well.
long story short, I tried using devwait with the regular init and it worked just fine to mount the ext partitions. yay!
first post edited to reflect the improved method.
I've also been testing a recovery mod. if recovery.fstab is modified in the recovery ramdisk (or a fakeflash recovery) then the recovery will copy a tweaked rom.zip to the ext /system partition with some minimal modifications to the updater-script and a few commands in the adb shell.
the recovery with the modded recovery.fstab can also back up from and restore to the sdcard ext /data and /system partitions.
I will update the first post with more specific instructions as I hammer them into something consistent.
soon I'll be ready to release a modded fakeflash recovery to make experimentation easier, as well.

[Q][S-ON] screwing around with Wildfire S

I posted this here - http://forum.xda-developers.com/showpost.php?p=18647176&postcount=14 - but never got an answer so I'm posting it to its own thread. I would post to the development section but apparently until I clutter up the place with 10 posts I'm considered a drooling idiot.
I was playing around and I noticed that the problem is with s-on I cannot write to /system meaning no superuser etc. So I remembered from way back when I started linux you could mount over a mounted folder. So I made a small file, put ext3 on on it, transferred it to the sdcard and mounted over /system with
mount -t ext3 -o rw,loop /mnt/sdcard/test.dump /system
it worked and then of course I lost all commands (ls, reboot...) in the shell.
Would it be possible to dump /system with "cat /dev/mtd/mtd3 > /mnt/sdcard/system.img", extract it, put it in an ext3 file, mount it as readable over system and just go to town?
Somebody MUST have tried this in the past. Before I go any further can anyone tell me why this wouldn't work and save me a few hours noodling around lol

baconbacon said:
I posted this here - http://forum.xda-developers.com/showpost.php?p=18647176&postcount=14 - but never got an answer so I'm posting it to its own thread. I would post to the development section but apparently until I clutter up the place with 10 posts I'm considered a drooling idiot.
I was playing around and I noticed that the problem is with s-on I cannot write to /system meaning no superuser etc. So I remembered from way back when I started linux you could mount over a mounted folder. So I made a small file, put ext3 on on it, transferred it to the sdcard and mounted over /system with
mount -t ext3 -o rw,loop /mnt/sdcard/test.dump /system
it worked and then of course I lost all commands (ls, reboot...) in the shell.
Would it be possible to dump /system with "cat /dev/mtd/mtd3 > /mnt/sdcard/system.img", extract it, put it in an ext3 file, mount it as readable over system and just go to town?
Somebody MUST have tried this in the past. Before I go any further can anyone tell me why this wouldn't work and save me a few hours noodling around lol
Click to expand...
Click to collapse
S-on itself got nothing to do with rooting. It just means you can't flash unsigned images as much as I know.
That system is mounted as ro is also at rooted phones the standard behaviour, you have to remount it as rw, but without root it won't accomplish I think.
Cat is for text files not for binaries or whole partitions, to extract the image use the dd command.
Do you have an /dev/mtd folder? My partitions are at /dev/block and there is no /dev/mtd present.
Swyped from my HTC Desire S

Tectas said:
S-on itself got nothing to do with rooting. It just means you can't flash unsigned images as much as I know.
That system is mounted as ro is also at rooted phones the standard behaviour, you have to remount it as rw, but without root it won't accomplish I think.
Cat is for text files not for binaries or whole partitions, to extract the image use the dd command.
Do you have an /dev/mtd folder? My partitions are at /dev/block and there is no /dev/mtd present.
Swyped from my HTC Desire S
Click to expand...
Click to collapse
This issue is that when you remount it as rw you cannot write to it. I want to know if I make my own partitions and mount them after boot if that will work, probably slower but work. This is so lojack I doubt it will work, I just want to know if anyone tried it.
Also "Cat is for text files not for binaries or whole partitions" is wrong, it works fine.

baconbacon said:
This issue is that when you remount it as rw you cannot write to it. I want to know if I make my own partitions and mount them after boot if that will work, probably slower but work. This is so lojack I doubt it will work, I just want to know if anyone tried it.
Also "Cat is for text files not for binaries or whole partitions" is wrong, it works fine.
Click to expand...
Click to collapse
Then it's not rw, because rw stands for read write, but like I said without root...
And no I think no one tried it before, because using an xtc-clip is compared to your solution much less work
But if you want to try it, do it and share your experiences, maybe it helps others
That cat works doesn't mean that it's made for it, you can also hunt for birds with a bazooka
Take a look at cat and dd and choose yourself.

Tectas said:
Then it's not rw, because rw stands for read write, but like I said without root...
And no I think no one tried it before, because using an xtc-clip is compared to your solution much less work
But if you want to try it, do it and share your experiences, maybe it helps others
That cat works doesn't mean that it's made for it, you can also hunt for birds with a bazooka
Take a look at cat and dd and choose yourself.
Click to expand...
Click to collapse
is xtc-clip better? yes, not arguing that. is cat is better then dd? no, I said cat works in this instance the same as dd, the results will be the identical.
I didn't ask this question to argue unrelated linux 101. I'm just going to look into this myself. iow screw you guys, im going home...

Dude, I use Linux too though I'm probably not a guru. I think I understand what you're saying... but if I do, aren't you just talking about editing a copy of /system? How would you mount your edited partition at boot?
Time permitting, I could try a few tricks but I'm not willing to risk bricking my phone though. I'd be stranded without it.
Sent from my HTC Wildfire S A510e using XDA App

First don't blame others, because of things I wrote.
I never said it couldn't work, I just wanted to show you that there are better ways to do it, cause cat also tries to interpret the file and not only copies it, what could mess up your image in some cases.
Also be aware that if your using the same data and cache partition with both of your systems, it could be easy bricked, if you change to much at your 2. system and remember that there aren't many ways left to get it working again cause your still s-on.
I think he wants to mount it himself every time after boot.
If he can root his 2. system (but all by hand, I think) he maybe can mount his 1. system as rw and also root it, but the chance that something goes wrong is pretty high, even mounting itself could freeze the device, cause the first system is still in memory.
I'm also not even close to be a Linux guru.
Swyped from my HTC Desire S

[Guide]Functional ext4 for external microSD with just a few bumps left

Y.G. said:
I formated my sd card to Ext4 and when insert it in to my phone, it says that's it's blank and has unsupported files. Any reasons for that?
Sent from my SPH-L710 using xda premium
Click to expand...
Click to collapse
The SPH-L710 Samsung Stock LJ7 TW 4.1.1 Android doesn't understand/support the change to ext4 external SD card (microSD) without a few things being done.
I'm working this out right now. So far I have manually been able to mount the newly created ext4 partition on the microSD card through adb, and after some chown/chmod I was able to go back to "Settings and Storage" and the "Mount SD Card" picked it up, and I was up and running ext4. But this didn't persist after a restart. So I'm looking into: /etc/vold.fstab MODS to keep it after restart right Now !!
If Some one else already has this perfected please chime in. I'm wanting to do most of the devices in the house this way when I get time because better performance, having a file system with a journal, and getting rid of thins like 4 Gig per file limitations is pretty Sweet in my humble opinion *Grin*
0) Assuming you already have your microSD card formatted ext4. I also happened to label mine extSdCard for the volume label within gparted
1) Can mount with:
mount -w -t ext4 /dev/block/mmcblk1p1 /storage/extSdCard/
2) To get the correct owner and permissions run:
chown root:sdcard_rw /storage/extSdCard
chmod 775 /storage/extSdCard
3) Should make the extSdCard owner/permissons match the regular internal sdcard you can verify this like so:
cd /storage/ && ls -l
drwxrwxr-x root sdcard_rw 2013-01-12 18:16 extSdCard
drwxrwxr-x root sdcard_rw 2013-01-12 17:05 sdcard0
4) After that you can go to the "Settings and Storage" to run "Mount SD" and you will have ext4 extSdCard Show up and it bring up the File System Status !! --> Until you reboot and it goes to crap because I don't have the vold.fstab edit/MOD complete _yet_ ... So, for now a boot script has been put in place to bring our external SD card back online during restart, so the system will acknowledges it, making the world a better place.
Example of how things look file system wise: mount | grep extSdCard
/dev/block/mmcblk1p1 /storage/extSdCard ext4 rw,relatime,user_xattr,barrier=1,data=ordered 0 0
5) Have not been able to resolve the vold.fstab to make this ext4 extSdCard matter fully Legit (in my opinion), but I did manage to make it remount the card on boot, so its online when the system comes up instead of having to manually mount it. Did this by -->
Added the following lines to the very bottom of: /etc/init.qcom.post_fs.sh
## sponix MOD to match with ktoonz kernel for better power management
stop mpdecision
## sponix MOD to mount extSdCard prior to GUI work around to make ext4 function
## read and write extSdCard mount
chown root:sdcard_rw /storage/extSdCard
chmod 775 /storage/extSdCard
mount -w -t ext4 /dev/block/mmcblk1p1 /storage/extSdCard
chown root:sdcard_rw /storage/extSdCard
chmod 775 /storage/extSdCard
## if you want read only extSdCard mount
## mount -r -t ext4 /dev/block/mmcblk1p1 /storage/extSdCard
Still attempting to automate the process so the Stock+root LJ7 can pick up the extSdCard _normally_ without having to do the mount command manually, but so far its kicking my butt. Also this is more a "General, or Question and Answer type Topic" the Kernel(s) obviously support ext4 the system fs uses/requires it *Grin*.. So we might get Our Friendly Neighborhood Moderator to Migrate it to the proper place to help others. Just hoping to get the last few bumps smoothed out, or find someone that already documented the process that I've overlooked *Grin*..
Current Known Issues: If you unmount the card through the "Settings | Storage | Umount SD" or by hand with umount, you will either need to reboot for it to reattach through the /etc/init.qcom.post_fs.sh boot script script addition, or will have to mount it manually if you want to keep the system up and running. Guess you could also probably just run the /etc/init.qcom.post_fs.sh as root from a terminal emulator (or adb).
Still searching for vold.fstab bits of wisdom but that will have to continue next weekend -->
Sexy and You Know it,
Keep on Flashing,
sponix2ipfw (sponix
:fingers-crossed:

Ha! Sorry. Deleted: Didn't understand that you had it running on boot (can't read properly )

Great idea
Am I really the only one who also thinks this idea is the nuts?
Am I the only one who longs to transform the mess that passes for a filing system on the internal sd using symbolic links into a beautifully organized, encrypted and cloud synced system on my external sd?
Is it just me and a few others that want to be able to achieve the above so that we can move from one ROM to another or recover from a lost phone with the minimum of fuss?
Are we freaks? :cyclops:
Say it isn't so XDA!! :crying:
I'm gonna try this on my international S3 running Null_ Rom 25 JB 4.1.2
PS do you have any idea how the entire ExtSD or just a folder can be enrypted using Cryptonite and automatically mounted at boot time?

emp111 said:
PS do you have any idea how the entire ExtSD or just a folder can be enrypted using Cryptonite and automatically mounted at boot time?
Click to expand...
Click to collapse
Is this along the lines of what you're looking for?
http://forum.xda-developers.com/showthread.php?t=1141467
Also your idea is pretty insane, but also genius
If you get that to work please do come back and share

Insane ideas are the best lol
CNexus said:
Is this along the lines of what you're looking for?
http://forum.xda-developers.com/showthread.php?t=1141467
Also your idea is pretty insane, but also genius
If you get that to work please do come back and share
Click to expand...
Click to collapse
Thank you for your prompt reply, yes it is asking a lot I know but I think that it can be done.
Now if you really thought that idea was insane......check this out:
Imagine that we asked every Android app developer to submit the various paths used for their config (and config backup) files to a central database and had the ability to add or own custom paths (which could be added to the central database once approved).
We could build an script/app that would retrieve a list of currently installed apps on your phone then automatically build a symbolically linked file system (and/or backup file system) in the location of your choice that you could either encrypt and/or sync using your current tools or even incorporate this functionality into the app itself along with the ability to choose what was encrypted/backed up and how i.e. either synced to the Cloud or (S)FTP or SMB as either a dd copy or even a cwm flashable zip.
Could I dare hope for a Tasker module or the ability to add custom scripts?
I wish I could do this myself but my coding skills are non existent
Anyway the LUKS manager app won't automatically mount a file system, but I really like it anyways, thank you for pointing me to it!
And on the Ext4 front, the mount command (yes the 1st one ) failed, maybe the op could offer a suggestion. :angel:
BTW is there a place for people to suggest ideas for apps here?

Wait really it wont? I couldve sworn I remembering that it did
But dude....
You need to learn yourself some java and start whipping stuff up
Idk about the whole central database thing, but the rest could definitely be done with root access
I think the main problem with that is the proprietary aspects...i mean even here on XDA where binaries released are supposed to be GPL compliant, many of them arent and its sad because it deteriorates the overall quality of work thats released afterward

This whole thing is just hard work!
CNexus said:
Wait really it wont? I couldve sworn I remembering that it did
Click to expand...
Click to collapse
Doesn't seem to unfortunately
But dude....
You need to learn yourself some java and start whipping stuff up :D :D[/QUOTE said:
You make it sound soooo easy lol, and at another point in my life maybe it would have been but right now I'm operating at a reduced level due to some unforeseen circumstances that have left me lacking focus, motivation etc
You know all the things you need to be creative, learn etc lol
Anyway back to the matter at hand, I have got my ext4 SD card to the stage where I have to manually mount it from within the Settings/Storage as I'm using the international S3 and don't have the init.qcom.post_fs.sh, I think the qcom refers to Qualcomm chipset in US S3's.
As for modifying vold.fstab so we can avoid the above workaround it would seem that maybe thats a dead end as according to a German guy on android-hilfe. de, Vold may have been modified by Samsung to only deadl with exFAT on External SD's.
Looks like I'm not gonna be in Android nirvana for a while :crying:
Unless anyone else on XDA fancies getting in on this !!!!
Click to expand...
Click to collapse

Got it working ..... kinda
Got an app called ezymount (by ezynow) that automounts my ext4 64GB microSD at boot time.
I have to wait a few seconds for the boot process to complete but it's automatic, am pretty happy!!
Now gotta get symlinks, encryption and cloud synchronization sorted :/

[Q] run script on sd card mount

Does anyone know if any scripts are executed (or can be executed) when the SD card is mounted? Of course this would include on boot.
What I am trying to accomplish is that I would like to mount in a second path the fat32 external partition as the system user (with an appropriate umask) so that I can symlink data from the /data/app directory. I don't mind copying the .apk files and just symlinking them individually; I currently have over 5GB of files there, so I know it should really help with saving space. And, this way I can still take advantage of the space as is, rather than losing it all to a directory symlink.
I don't mind resymlinking once in a while after I add/remove some software. I am a long time Linux user (personally and professionally) so a little command line doesn't scare me one bit.
I thought I should mention that I am currently using LRS G Pad, so a solution that works on stock (or stock-like) ROMs is preferred, though I am curious what a custom ROM can buy me in this area also.
Thank you for your help!

IBJamon said:
Does anyone know if any scripts are executed (or can be executed) when the SD card is mounted? Of course this would include on boot.
What I am trying to accomplish is that I would like to mount in a second path the fat32 external partition as the system user (with an appropriate umask) so that I can symlink data from the /data/app directory. I don't mind copying the .apk files and just symlinking them individually; I currently have over 5GB of files there, so I know it should really help with saving space. And, this way I can still take advantage of the space as is, rather than losing it all to a directory symlink.
I don't mind resymlinking once in a while after I add/remove some software. I am a long time Linux user (personally and professionally) so a little command line doesn't scare me one bit.
I thought I should mention that I am currently using LRS G Pad, so a solution that works on stock (or stock-like) ROMs is preferred, though I am curious what a custom ROM can buy me in this area also.
Thank you for your help!
Click to expand...
Click to collapse
Maybe take a look at tasker to initiate a command. I too had hoped to use a Linux command for a different reason, only to find everything to be different enough to be a problem. Tasker will allow the command, but knowing where to put it will be the problem. Writing a script that recognizes "fuse" initiation, outing it in init.d, and then using tasker to initiate the script?
Maybe just tasker, as you can write simple one liners for different tasks(turning things off and on with a simple path).
Doing this from the kernel ramdisk would probably be better.
Please describe exactly how you do this if you figure it out please!
Best regards,