0

I tried to create a symlink for the external SD on a Galaxy S3 as I have done it on my HTC M8 previously. I tried with terminal emulator in command line, with Root Explorer and with Solid Explorer. It always worked and they were fully operational – but when I rebooted the device they are always lost, no track of the symlink previously created. Could someone explain, what is happening and how to correct that ? Thank you.

I forgot, my device is GT-9300 French running Android 4.3

  • 1
    Very much depends on where you wanted to create the symlink. A good guess: in the root FS? That would explain, as that FS is built up from a RAM disk on boot. You'd need to either manipulate the boot-image then – or use some init.d script to create the symlink on each boot. Doing it with an app like Tasker would be another approach. – Izzy Sep 13 '15 at 19:18
  • @Izzy, that is a valid answer. Please make it one. – Tamoghna Chowdhury Sep 18 '15 at 10:19
  • @TamoghnaChowdhury Yes, sir – done so, with a few more details making it a valid and detailed answer :) Thanks for the heads-up! – Izzy Sep 18 '15 at 17:06
  • 1
    Thanks for idea. I have it done with init.d after implementing on my stock ROM. I also did with Tasker. Both worked very well. I prefer init;d as it is a system solution. – Daniel P. Sep 19 '15 at 12:01
1

That very much depends on where you wanted to create the symlink. A good guess: in the root file-system? That would explain the behaviour:

Android uses an initial RAM-disk (aka "boot-image") on startup, from which it creates the rootFS (and several other things) anew each time – so changes to the root file-system don't survive a boot. That leaves you with at least two or three options:

  • manipulate the boot-image: only if you have the experience. Getting that wrong, and you might have to flash a fresh ROM (worst case; keeping the original, you could replace it via – but the try-and-err process might take a while)
  • use some init.d script to create the symlink on each boot: Requires your device/ROM to support the init.d system (not all do). Again, a "borked script" might screw your boot process; but you could verify your script (running it manually) before placing it into init.d, and doing so keeps the risk level very low.
  • Using an app-based solution: apps like offer to run stuff as soon as boot is completed.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.