Develop Bugs

Apps2SD on HTC Hero with default 2.1 ROM

Hi all, i've bought an HTC Hero with HTC's 2.1 ROM, and since it's still in warranty i don't want to flash it with a custom ROM now
I can't find a way to install apps on the SD, because all i find are cusom roms which already have apps2sd enabled...
What can i do if i want to keep my warranty?

Cero92 said:
Hi all, i've bought an HTC Hero with HTC's 2.1 ROM, and since it's still in warranty i don't want to flash it with a custom ROM now
I can't find a way to install apps on the SD, because all i find are cusom roms which already have apps2sd enabled...
What can i do if i want to keep my warranty?
Click to expand...
Click to collapse
no. you need root. If you like your warranty, and your phone gets broken in some way while rooting, you can just run the official RUU and return it back to stock state, and your provider will never know.

Cero92 said:
Hi all, i've bought an HTC Hero with HTC's 2.1 ROM, and since it's still in warranty i don't want to flash it with a custom ROM now
I can't find a way to install apps on the SD, because all i find are cusom roms which already have apps2sd enabled...
What can i do if i want to keep my warranty?
Click to expand...
Click to collapse
You can't enable app2sd without root, and if I am not mistaken, it's the rooting the will void your warranty....
I don't think you can mess with anything at the system level without voiding your warranty, which makes sense.
But, Andyt95 is right, if you mess something up, the RRU should restore it to the unrooted state.

I rooted it using this guide: http://forum.xda-developers.com/showthread.php?t=645253
I followed the first part up to the fourth point (i think recovery img is needed to flash, not to root, am i wrong?)
But, now?

ya recovery image needs when you want to flash something in your mobile . But to root your phone it don't need recovery
there are many apps out there which can give you root & most of them are compatible for Hero

Yes i rooted it
But what to do next to install apps on sd?
I can't find a tutorial, my mistake?

Cero92 said:
Yes i rooted it
But what to do next to install apps on sd?
I can't find a tutorial, my mistake?
Click to expand...
Click to collapse
You need to partition your card with a EXT 2 partition. Then install any custom ROM. Most support app2SD

nirmalv said:
You need to partition your card with a EXT 2 partition. Then install any custom ROM. Most support app2SD
Click to expand...
Click to collapse
Yes, but i'd like to jeep the default ROM for a while
Sent from my HTC Hero using XDA App

Cero92 said:
Yes, but i'd like to jeep the default ROM for a while
Sent from my HTC Hero using XDA App
Click to expand...
Click to collapse
The problem is, its not a simple update, it needs support in the kernel ramdisk, busybox installed and some scripts.
Usually I don't like to recommend the Darktremor app2sd, because its a bit too bloated in my eyes, and I don't like things which are so complicated I can't understand them (and I have tried, but he has so much script for a relatively simple task...).
Anyway in this case, I think its your only bet.
DO A NANDROID BACKUP BEFORE YOU TRY ANYTHING - ESPECIALLY THIS!
EDIT: Taking another look, even it (the Darktremor app2sd) does not seem to fix the kernel's ramdisk. You might want to test it after a nandroid backup on the odd chance I am wrong (i.e. if your original ROM does run the init.d scripts - mine did not). I am afraid if I am right, the only way you can keep the original ROM and enable app2sd, is if you unpack the kernel ramdisk and edit the init.rc to run the init.d scripts - which is a bit more complicated than it sounds, but not that hard if you have the proper background....

erasmux said:
The problem is, its not a simple update, it needs support in the kernel ramdisk, busybox installed and some scripts.
Usually I don't like to recommend the Darktremor app2sd, because its a bit too bloated in my eyes, and I don't like things which are so complicated I can't understand them (and I have tried, but he has so much script for a relatively simple task...).
Anyway in this case, I think its your only bet.
DO A NANDROID BACKUP BEFORE YOU TRY ANYTHING - ESPECIALLY THIS!
EDIT: Taking another look, even it (the Darktremor app2sd) does not seem to fix the kernel's ramdisk. You might want to test it after a nandroid backup on the odd chance I am wrong (i.e. if your original ROM does run the init.d scripts - mine did not). I am afraid if I am right, the only way you can keep the original ROM and enable app2sd, is if you unpack the kernel ramdisk and edit the init.rc to run the init.d scripts - which is a bit more complicated than it sounds, but not that hard if you have the proper background....
Click to expand...
Click to collapse
I'm down to give this a try, my girl wants the stock rom and a2sd. Dam cake eaters! but is there a process to follow with this? I'm good enough to follow a process but not create it for a2sd. Any links to reference??

da-pharoah said:
I'm down to give this a try, my girl wants the stock rom and a2sd. Dam cake eaters! but is there a process to follow with this? I'm good enough to follow a process but not create it for a2sd. Any links to reference??
Click to expand...
Click to collapse
why stock though? have you considered that villainrom 13 is just like stock but better and has apps2sd? it's a full HTC sense 2.1 rom but rooted with apps2sd and a few small additions to ensure it runs as fast as possible and gives as much room as possible and runs a custom kernel ***
and you can revert by flashing an RUU which is super easy to do (I've done it before for warranty reasons) and the RUU (stock rom) works exactly the same, in fact IS exactly the same except for the features you're asking for.
***(which is pretty much required for apps2sd unless you want to hack it for a while and know how to do it yourself (it's a lot to ask the devs here to tell you everything you need to do if you're not a kernel developer already imho and even then there isn't a guarantee you wont' mess up your phone's stock rom).

dkelley said:
why stock though? have you considered that villainrom 13 is just like stock but better and has apps2sd? it's a full HTC sense 2.1 rom but rooted with apps2sd and a few small additions to ensure it runs as fast as possible and gives as much room as possible and runs a custom kernel ***
and you can revert by flashing an RUU which is super easy to do (I've done it before for warranty reasons) and the RUU (stock rom) works exactly the same, in fact IS exactly the same except for the features you're asking for.
***(which is pretty much required for apps2sd unless you want to hack it for a while and know how to do it yourself (it's a lot to ask the devs here to tell you everything you need to do if you're not a kernel developer already imho and even then there isn't a guarantee you wont' mess up your phone's stock rom).
Click to expand...
Click to collapse
Hi I am trying to find the step by step guide about how to setup Apps2SD working. But having tough time. I have done this with my HD2 but cant find much help for Hero.
I have Recovery image flashed with 8GB (class 6) SD Card.
Next I am looking to partition the card from recovery, but what should be the swap size?
Once partitioned I will try flashing Villainrom 13 ROM.
Thanks

nbhor said:
Hi I am trying to find the step by step guide about how to setup Apps2SD working. But having tough time. I have done this with my HD2 but cant find much help for Hero.
I have Recovery image flashed with 8GB (class 6) SD Card.
Next I am looking to partition the card from recovery, but what should be the swap size?
Once partitioned I will try flashing Villainrom 13 ROM.
Thanks
Click to expand...
Click to collapse
Swap does not seem to work well for the hero, therefore most ROMs will not enable it and I use 0 for the swap size when partitioning. If you still prefer to reserve room for it use something like 32 or 64.

dkelley said:
why stock though? have you considered that villainrom 13 is just like stock but better and has apps2sd? it's a full HTC sense 2.1 rom but rooted with apps2sd and a few small additions to ensure it runs as fast as possible and gives as much room as possible and runs a custom kernel ***
and you can revert by flashing an RUU which is super easy to do (I've done it before for warranty reasons) and the RUU (stock rom) works exactly the same, in fact IS exactly the same except for the features you're asking for.
***(which is pretty much required for apps2sd unless you want to hack it for a while and know how to do it yourself (it's a lot to ask the devs here to tell you everything you need to do if you're not a kernel developer already imho and even then there isn't a guarantee you wont' mess up your phone's stock rom).
Click to expand...
Click to collapse
thanks for the reply! but to answer your in short, My girl doesnt speak geek and gets pissed right away when the ROM she uses acts up. So in short stock roms is whats she likes. I have been trying to convince her to do another ROM but she is hard headed. I think i'll just flash the villainrom 13 and tell her its stock lol. Thanks again i'll check it out!

Tried multiple attempts from scratch every time.
Attempt 1 - Failed
Partitioned my SD Card for EXT 2 (512MB).
Tried flashing of Villainrom 13 ROM along with Dalvik2SD patch.
Installed bunch of apps. Checked size of EXT2 partition. Nothing changed. Its still same size as it was before installing apps. System memory reduced from its original value.
Attempt 2 - Failed
Partitioned my SD Card for EXT 3 (512MB).
Tried flashing of Villainrom 13 ROM along with Dalvik2SD patch.
Installed bunch of apps. Checked size of EXT3 partition. Nothing changed. Its still same size as it was before installing apps. System memory reduced from its original value.
Any suggestions?

nbhor said:
Tried multiple attempts from scratch every time.
Attempt 1 - Failed
Partitioned my SD Card for EXT 2 (512MB).
Tried flashing of Villainrom 13 ROM along with Dalvik2SD patch.
Installed bunch of apps. Checked size of EXT2 partition. Nothing changed. Its still same size as it was before installing apps. System memory reduced from its original value.
Attempt 2 - Failed
Partitioned my SD Card for EXT 3 (512MB).
Tried flashing of Villainrom 13 ROM along with Dalvik2SD patch.
Installed bunch of apps. Checked size of EXT3 partition. Nothing changed. Its still same size as it was before installing apps. System memory reduced from its original value.
Any suggestions?
Click to expand...
Click to collapse
System memory is still reduced with app2sd, since the /data/data folder is not moved to the SD.
Assuming you have adb working, check these two commands:
Code:
adb shell df -h
adb shell ls -ld /data/app
If you think you still have a problem please post the result of these two commands.

erasmux said:
System memory is still reduced with app2sd, since the /data/data folder is not moved to the SD.
Assuming you have adb working, check these two commands:
Code:
adb shell df -h
adb shell ls -ld /data/app
If you think you still have a problem please post the result of these two commands.
Click to expand...
Click to collapse
Do I run this command in terminal emulator on droid or use droid explorer > Terminal Command?
Can Root Explorer help? I am getting adb permission denied from terminal emulator.

nbhor said:
Do I run this command in terminal emulator on droid or use droid explorer > Terminal Command?
Can Root Explorer help? I am getting adb permission denied from terminal emulator.
Click to expand...
Click to collapse
well, I actually meant connecting the device w/ a USB cable to your computer and then from a command prompt (i.e. start -> run -> "cmd") using the "adb.exe" utility that comes with the android SDK (under the tools folder)....
You can run the same commands in a terminal windows just without the "adb shell":
Code:
df -h
ls -ld /data/app
Only problem is that then it you can't copy paste your result here.
for the "df -h" command take note of the mount of your sdcard which should start like this line:
Code:
/dev/block/mmcblk0p2 720.9M 506.3M 178.0M 74% /sd-ext
I would assume that for you the mount point (last value) would be /system/sd.
next check the "ls -ld /data/app" and make sure it is linked to the same location, in my case it is:
Code:
lrwxrwxrwx 1 root root 11 Apr 20 09:59 /data/app -> /sd-ext/app

erasmux said:
well, I actually meant connecting the device w/ a USB cable to your computer and then from a command prompt (i.e. start -> run -> "cmd") using the "adb.exe" utility that comes with the android SDK (under the tools folder)....
You can run the same commands in a terminal windows just without the "adb shell":
Code:
df -h
ls -ld /data/app
Only problem is that then it you can't copy paste your result here.
for the "df -h" command take note of the mount of your sdcard which should start like this line:
Code:
/dev/block/mmcblk0p2 720.9M 506.3M 178.0M 74% /sd-ext
I would assume that for you the mount point (last value) would be /system/sd.
next check the "ls -ld /data/app" and make sure it is linked to the same location, in my case it is:
Code:
lrwxrwxrwx 1 root root 11 Apr 20 09:59 /data/app -> /sd-ext/app
Click to expand...
Click to collapse
My results from above 2 commands
C:\Program Files (x86)\Android\android-sdk\platform-tools>adb shell df -h
Filesystem Size Used Available Use% Mounted on
tmpfs 95.6M 0 95.6M 0% /dev
tmpfs 4.0M 0 4.0M 0% /sqlite_stmt_journals
/dev/block/mtdblock3 170.0M 162.8M 7.2M 96% /system
/dev/block/mtdblock5 165.8M 11.2M 154.5M 7% /data
/dev/block/mtdblock4 130.0M 58.8M 71.2M 45% /cache
/dev/block/mtdblock4 130.0M 58.8M 71.2M 45% /data/dalvik-cache
/dev/block//vold/179:1
6.8G 4.0G 2.8G 59% /sdcard
C:\Program Files (x86)\Android\android-sdk\platform-tools>adb shell ls -ld /data/app
drwxrwx--x 1 1000 1000 2048 Apr 22 01:34 ?[1;34m/data/app?[0m

nbhor said:
My results from above 2 commands
C:\Program Files (x86)\Android\android-sdk\platform-tools>adb shell df -h
Filesystem Size Used Available Use% Mounted on
tmpfs 95.6M 0 95.6M 0% /dev
tmpfs 4.0M 0 4.0M 0% /sqlite_stmt_journals
/dev/block/mtdblock3 170.0M 162.8M 7.2M 96% /system
/dev/block/mtdblock5 165.8M 11.2M 154.5M 7% /data
/dev/block/mtdblock4 130.0M 58.8M 71.2M 45% /cache
/dev/block/mtdblock4 130.0M 58.8M 71.2M 45% /data/dalvik-cache
/dev/block//vold/179:1
6.8G 4.0G 2.8G 59% /sdcard
C:\Program Files (x86)\Android\android-sdk\platform-tools>adb shell ls -ld /data/app
drwxrwx--x 1 1000 1000 2048 Apr 22 01:34 ?[1;34m/data/app?[0m
Click to expand...
Click to collapse
Well, you really do *not* have app2sd enabled (I am sorry for my previous disbelief but I have seen many users in the past which only thought they did not have app2sd enabled).
From your previous posts I understand you are using VR13, so either ask on the VR13 thread how to enable app2sd (you can post the above as proof it is not working for you), or change to a ROM with more "stable" app2sd....

[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

/storage/sdcard0 vs /data/media

I took the plunge today and flashed my first JB ROM today. (I was previously running BAMF Paradigm v1.3).
This morning, I flashed CWM 6.0.0.5 (not the touch version), and then flashed BAMF You Jelly Huh v2.1
Everything went very smoothly, it boots up quickly, JB is awesome, etc, etc...
So, with Root Explorer, I see that there is now this folder:
/storage/sdcard0
From reading a lot in the past week or so (both here and at rootzwiki), I know that this is the new actual location of our internal SD card. And the /sdcard folder really just points to this new location.
However, I also still have the old /data/media folder. From what I can tell in Root Explorer, the /data/media folder is identical to the new /storage/sdcard0 folder. However, I'm assuming that the data hasn't really been duplicated, and all three folders all contain a single copy of the same files.
Is that correct?
If so, what exactly is the differences between /storage/sdcard0 and /data/media? Should I just leave them both? Should I delete the older /data/media folder? Or would that delete everything on my internal SD card?
Thanks in advance for any clarification you can provide.
Sent from my Galaxy Nexus using Tapatalk 2

/sdcard is indeed a symbolic link to /storage/sdcard0, which is the new sdcard data location and mounted on /dev/fuse. It's likely there for backward compatibility. If I had to guess, /data/media looks like a bind mount of /storage/sdcard0, though I have no idea why they would use a bind mount instead of a symbolic link if it were only for backward compatibility. It's not listed as being a mount point when issuing the mount or df commands, though. I guess I'll dig around for an fstab entry.
Edit: It looks like there's an explanation in the init.tuna.rc file. /data/media is created. Later in the file, a "virtual SD card" is created via a service:
Code:
service sdcard /system/bin/sdcard /data/media 1023 1023
class late_start
Per the code comments:
Code:
# create virtual SD card at /storage/sdcard0, based on the /data/media directory
# daemon will drop to user/group system/media_rw after initializing
# underlying files in /data/media will be created with user and group media_rw (1023)
So the actual physical storage place is still /data/media. /storage/sdcard0 is a "virtual" SD card. /sdcard and /mnt/sdcard are symbolic links of /storage/sdcard0.
At this point, my big question is... why?

Cilraaz - thanks for your detailed reply. We still don't know why the new /storage/sdcard0 folder was created, but at least we're a little closer.
Anyone else have anything to add?
Sent from my Galaxy Nexus using Tapatalk 2

Does anyone else have any other thoughts?
Sent from my Galaxy Nexus using Tapatalk 2

I wonder if this has something to do with the problem some people are having where the available space in internal storage isn't adding up properly. For example, I have 13.33GB total space, 4GB of used space, and 3.21GB of available space.

Cilraaz said:
So the actual physical storage place is still /data/media. /storage/sdcard0 is a "virtual" SD card. /sdcard and /mnt/sdcard are symbolic links of /storage/sdcard0.
At this point, my big question is... why?
Click to expand...
Click to collapse
I'd guess that the virtual sdcard exists because /data/media is part of an ext# partition, so they use fuse filesystem and virtual sdcard to make it look like fat to apps, many of which don't understand ext# filesystems.

External_sd
strumcat said:
I'd guess that the virtual sdcard exists because /data/media is part of an ext# partition, so they use fuse filesystem and virtual sdcard to make it look like fat to apps, many of which don't understand ext# filesystems.
Click to expand...
Click to collapse
In my vold.fstab, now I have the following to my External SD:
dev mount sdcard1 /storage/sdcard1 auto /devices/plataform/s3c-sdhci.2/mmc_host/mmc1
How can I remap the external SD card back to /sdcard/external_sd ?
Is it in the vold.fstab file?

fabriciouerj said:
In my vold.fstab, now I have the following to my External SD:
dev mount sdcard1 /storage/sdcard1 auto /devices/plataform/s3c-sdhci.2/mmc_host/mmc1
How can I remap the external SD card back to /sdcard/external_sd ?
Is it in the vold.fstab file?
Click to expand...
Click to collapse
1. Why would you want to?
2. Safest bet would probably be a symbolic link from /storage/sdcard1 to /sdcard/external_sd. If you're doing it as a hard mount and it tries to mount /sdcard/external_sd before everything happens with /data/media, /storage/sdcard0, /mnt/sdcard, and /sdcard, you'll end up with some nastiness.

write to /mnt/sdcard or fail on /storage/sdcard0 ?
This is making me nugging futz !
just trying to save a picture in an app - same code works fine in os < Jellybean (JB)
m_sFilePath = Environment.getExternalStorageDirectory().getAbsolutePath() ;
= /mnt/sdcard in os < JellyBean (JB)
but /storage/sdcard0 in JB
as others here have noted.
However - and this is where it gets me - append a file name with a leading slash and the slash is there in os < JB, but gets trimmed out (somehow?) in JB ! e.g.
/mnt/sdcard/MyFile.bmp
VS
/storage/sdcard0MyFile.bmp
Tests use EXACTLY the same code ! Tests run on 2.3.3, and several versions of 4.x
So is /storage/sdcard0 actually a C, null terminated string and the null has been turned into a char 0 ? The '0' is counted in length() call, but fails on write --- or should I not use the sym link and go straight to /mnt/sdcard ? Can the app write to that path without special permissions, etc ?
thanks!

HowardPau said:
This is making me nugging futz !
just trying to save a picture in an app - same code works fine in os < Jellybean (JB)
m_sFilePath = Environment.getExternalStorageDirectory().getAbsolutePath() ;
= /mnt/sdcard in os < JellyBean (JB)
but /storage/sdcard0 in JB
as others here have noted.
However - and this is where it gets me - append a file name with a leading slash and the slash is there in os < JB, but gets trimmed out (somehow?) in JB ! e.g.
/mnt/sdcard/MyFile.bmp
VS
/storage/sdcard0MyFile.bmp
Tests use EXACTLY the same code ! Tests run on 2.3.3, and several versions of 4.x
So is /storage/sdcard0 actually a C, null terminated string and the null has been turned into a char 0 ? The '0' is counted in length() call, but fails on write --- or should I not use the sym link and go straight to /mnt/sdcard ? Can the app write to that path without special permissions, etc ?
thanks!
Click to expand...
Click to collapse
*sigh* *frakkin necrobumping*
the issue you're describing...relates to an app, not really to the mount list/android fstab :|
https://groups.google.com/forum/?fromgroups#!forum/android-developers would be a better place, IMO.

bk201doesntexist said:
*sigh* *frakkin necrobumping*
the issue you're describing...relates to an app, not really to the mount list/android fstab :|
_/android-developers_ would be a better place, IMO.
Click to expand...
Click to collapse
Not necrobumping, more like "living dead bumping" - I searched extensively first on Stack Overflow, and the google forum you mention above, then came here to XDA, based on a suggestion two days ago in S.O. *THIS* thread, despite it being old, is the closest match and my question / comment clearly relates: it is a File Access problem, is it not ?
So how about a useful suggestion - do you know the difference between ~/sdcard and ~/sdcard0 ?
Why does writing to storage/sdcard work, but to storage/sdcard0 fail, if they are sym-links to the same place. Clearly, the are not - or at least not at the time my app attempts to write to it, which should be long after mounting has happened.
and for you SDcard DeadHeads - the obvious search is "sdcard0 path", which as I mentioned does not yield the info needed:
https://groups.google.com/forum/?fromgroups#!searchin/android-developers/sdcard0$20path

bk201doesntexist said:
*sigh* *frakkin necrobumping*
the issue you're describing...relates to an app, not really to the mount list/android fstab :|
https://groups.google.com/forum/?fromgroups#!forum/android-developers would be a better place, IMO.
Click to expand...
Click to collapse
Enough complaining about 'necrobumping'. Bringing these threads back is much better than overflowing with new threads. I feel that this is a good reason to bump an old thread.
Sent from my Galaxy Nexus using xda premium

Vfan23 said:
... Bringing these threads back is much better than overflowing with new threads. I feel that this is a good reason to bump an old thread.
Click to expand...
Click to collapse
Thank you Vfan23 - this is exactly what I was thinking - seemed more appropriate to tie into old info (that, I claim, is not really old, just odd).
Here's more of what I've determined, but have not solved yet:
* JellyBean requires
<uses-permission android:name="android.permission.WRITE_EXTERNAL_STORAGE"/>
( or READ_EXTERNAL_STORAGE if that's all you need ).
* Trim off the " 0 " in /storage/sdcard0 and append your file name to the result and some folks claim it works:
/storage/sdcard/MyFile.foo
Still have not tested if writing directly to /mnt/sdcard (in JB) fails or not ... will let you know.
thanks
- H

I wonder why xda mods don't close necro'd threads...tell me.

gnustomp said:
I wonder why xda mods don't close necro'd threads...tell me.
Click to expand...
Click to collapse
Because sometimes questions aren't answered.
Sent from my Galaxy Nexus using xda premium

Samsung non-standard use of Environment.getExternalStorageDirectory()
Vfan23 said:
Because sometimes questions aren't answered.
Sent from my Galaxy Nexus using xda premium
Click to expand...
Click to collapse
This relates not only to this thread, but all others referring to Samsung devices using sdcards - of which there are many threads.
Samsung has implemented a non-standard API (I claim they broke the interface )
Samsung says you have to append more to the path - AND that you "must test for Samsung specific devices" before doing this:
String external = Environment.getExternalStorageDirectory();
external = external + "/external_sd/";
(Sorry, I'm still a <10 post NOOB, so here's the raw link)
developer.samsung.com/forum/board/thread/view.do?boardName=GeneralB&messageId=162934&messageNumber=1381&startId=zzzzz~&searchType=TITLE&searchText=sdcard
But if you get "sdcardX" where X is 0 - 9, then it fails (at least for me on several sam. devices using JB). I ask them in that link about how to fix this ... too soon for a reply.
- H

If you delete files from /data/media they dont disappear from /storage/sdcard0 nor from the MTP file explorer.
So I guess /storage/sdcard0 is used for different virtual services like MTP.
After rebooting my smartphone, the data was not there anymore (refresh MTP explorer to be sure).
And after going on adb shell, the data had disappeared from /storage/sdcard0
So the real data is probably on /data/media and no /storage/sdcard0

How to correctly mount and set permissions for ext4 MicroSd card on stock system ?

On ASUS stock rooted system, we can make use of fdisk to create a primary partition then use make_exr4fs to format that partition to ext4.
Once done and the /dev/block/mmcblk1p1 partition mounted as /storage/MicroSD it is possible as root to interact with it, but as non root you can only read data from there, not write.
How do you set selinux permissions correctly to allow writing without root ? The folder is set to 777, it cannot be a file permissions problem, it leaves us selinux policies to fix.
I tried to apply the selinux policy used for exfat external volumes but it still failed for writing.

Thanks to @Chainfire and Red Hat selinux documentation, I was able to resolve this without modifying the system, patching rules, disabling selinux or anything like that.
A two lines script can take care of this, requiring supersu and tools that are already on the device.
su --mount-master -c "mount -t ext4 -o discard /dev/block/mmcblk1p1 /storage/MicroSD"
chcon -R ubject_r:media_rw_data_file:s0 /storage/MicroSD
I'm still unsure to what each things are related to at 100%, but the context source of 3rd party application can write to media_rw_data_file , and this is what is applied on user's media folder inside data partition.
Some applications may still fail at understanding this is the external storage, but as my favorite file manager Fx does, that's what I want needed.
For some reasons the lost+found folder remains inaccessible, but the recursive part of chcon should take care of it on next boot.
Hope this will be useful to someone else.

Will your script work with another stock-ROM too? I've a Sony phone. Never had a phone I could get an ext4-formated sdcard working. Only with cyanogenmod installed ext4-formated cards work out of the box.
I'm a noob so I don't about scripting or understand details of file systems.

It will depend on where the Sony custom built system is mounting the micro sd card, if it mounts it at the same place, it will work.
But your message should have been a comment to my answer and not an answer proposal as you don't bring an alternative solution