Hello, is it possible to do that ?
Regards
Sure, you have a few options.
The best way (hardest):
-requires root and knowledge of the boot.img and ramdisk partitions of Android
-create the symlink or mountpoint by adding the necessary lines the /init.rc file.
Next best way (not hard if you have init.d support):
-requires root
-requires init.d support
-simply write a script to create your symlink/mountpoint, name it appropriately, and place it in the /system/etc/init.d directory.
-with init.d support, this will automatically run the script at boot and set the parameters you've outlined in said script.
The "other" method (avoid this if possible since it relies on loading an app on boot):
-requires root
-download Script Manager from the play store
-write a script to create your mountpoint or symlink
-configure Script Manager to execute the script on boot.
Hello
I found /init.rc, also found init.00.rc and init.01.rc, but i guess we are talking about the first one (init.rc)
I wasn't able to edit it with a text editor on my tf101, do i need something i don't have to edit it ? Or notepadd++ will be enough ?
In case i fail completly with this, is tasker able apply the line for me too ?
Thanks you for your time.
Regards
Magissia said:
Hello
I found /init.rc, also found init.00.rc and init.01.rc, but i guess we are talking about the first one (init.rc)
I wasn't able to edit it with a text editor on my tf101, do i need something i don't have to edit it ? Or notepadd++ will be enough ?
In case i fail completly with this, is tasker able apply the line for me too ?
Thanks you for your time.
Regards
Click to expand...
Click to collapse
The /init.rc can't be directly modified that way. Everything in the root filesystem "/", as well as the kernel zImage, are loaded at boot from the boot.img image. Therefore, any changes you make will just be reverted when you reboot because it reloads the original from the boot.img image. In order to modify /init.rc, you must pull your boot.img and then extract the files from it. Now you can add the necessary lines to it. After that, you re-combine everything back into the boot.img, and push it back to your device.
If all that sounds unfamiliar to you, you will have some reading to do. Most of this will need to be done on a linux machine too.
What ROM are you running? If you have init.d support, that would be the most straightforward way to accomplish your goals.
I'm running asus' rom .24 on a tf101
I don't know if it support init.d, didn't found this file on my device.
Regards
You can also use an app from here, XDA, called directory bind. It all depends what you're looking to do with those symlinks.
Sent from my Sprint Evo View 4G (PG41200) using Xparent Purple Tapatalk 2
Hello, i plan to move game data to sdcard and symlink it to the old internal place.
Also plan to symlink some folders to the movie folder
Regards
Then directory bind app is designed for just your need. All these solutions require rooting your device.
Sent from my HTCEVOV4G using Xparent Purple Tapatalk 2
I will look at this, thanks.
Directory bind run during boot or after boot ?(little delay before things get re symlinked ?)
Regards
Related
As I'm sure you realise (considering you've clicked on this thread), hastarin's new kernels do not enable undervolting by default.
After struggling to work out how to undervolt the kernel and asking for unforthcoming help in so many places, eventually a chap called tyween helped me out.
Here is a script which you can run to enable undervolting. Bear in mind that the settings revert to normal every time android restarts, which means you need to do this every time you reset your phone
If you need a faster way of running the scripts than a terminal, there is a program called SL4A which provides a GUI:
http://code.google.com/p/android-scripting/
init.d script
Assuming the rom you use supports init.d scripts, why wouldn't you just write a init.d script and place it in the \system\etc\init.d\ folder? No need re-run scripts every time you restart.
2000impreza said:
Assuming the rom you use supports init.d scripts, why wouldn't you just write a init.d script and place it in the \system\etc\init.d\ folder? No need re-run scripts every time you restart.
Click to expand...
Click to collapse
Maybe because I don't know how to :S lol.
If you do, then I'm sure it would help a lot of people including me if you posted some instructions.
(whenever I wrote a script in notepad and transferred it to my phone it didn't work, I had to write the script from scratch in that SL4A program. This is one factor which made experimentation much more difficult)
I've always used notepad++ to write simple scripts. Never used regular notepad for scripts before.
http://notepad-plus-plus.org/
I copied and pasted your undervolt script into the file. You should be able to use notepad++ to open and edit the voltages.
Copy the script to the following folder:
1.
\sdcard\android\root\system\etc\init.d\
or, if the rom does not have root folder support
2.
\system\etc\init.d\
pkchips said:
(whenever I wrote a script in notepad and transferred it to my phone it didn't work, I had to write the script from scratch in that SL4A program. This is one factor which made experimentation much more difficult)
Click to expand...
Click to collapse
Notepad sucks (the worst part of Windows 7) - it ends each line with Carriage Return and Line Feed (ASCII 13 + 10). Linux shells are usually thrown off by this, as they expect only line feed (ASCII 10).
I recommend you use Notepad++ always (you'll find it standalone, or in both PortableApps and LiberKey). If the status bar at the bottom shows "DOS", you can convert the line endings to UNIX.
2000impreza said:
I've always used notepad++ to write simple scripts. Never used regular notepad for scripts before.
http://notepad-plus-plus.org/
I copied and pasted your undervolt script into the file. You should be able to use notepad++ to open and edit the voltages.
Copy the script to the following folder:
1.
\sdcard\android\root\system\etc\init.d\
or, if the rom does not have root folder support
2.
\system\etc\init.d\
Click to expand...
Click to collapse
no root folder on sdcard and trying to paste this file into init.d folder doesn't work, never shows up after tryng to move the file (doesn't move from sdcard where am trying to transfer it over), any ideas?
technocat said:
no root folder on sdcard and trying to paste this file into init.d folder doesn't work, never shows up after tryng to move the file (doesn't move from sdcard where am trying to transfer it over), any ideas?
Click to expand...
Click to collapse
You can use ADB (which is part of the Android Developer Kit.
You need root access and then use ADB PUSH <sourceloc/file> </system/etc/init.d/filename>
This move the file to system memory.
Hello!
First of all, thanks to all you repliers!
I'd really like to know a few things creating a ROM:
1. how can I create an update.zip starting from a system.img? (I know how to sign) In case can I simply install the img and then push /system changes, like root or busybox?
2. how can I install busybox manually? Can I create a script which does the job for me (i.e. busybox --install command at first boot then delete the script itself), avoiding me to write loads of symlinks?
3. when I've created an update.zip, is it easy to root the ROM? I mean, just push su and SuperUser.apk? Or I need a particular boot.img?
Thanks
elegos said:
Hello!
First of all, thanks to all you repliers!
I'd really like to know a few things creating a ROM:
1. how can I create an update.zip starting from a system.img? (I know how to sign) In case can I simply install the img and then push /system changes, like root or busybox?
Click to expand...
Click to collapse
Clockwork Recovery won't install system image files for some reason. You'll need to dump the yaffs2 filesystem then zip it up into the update.zip, then use an updater-script to set unix permissions (zip doesn't preserve these). Also, there's no need to sign the update.zip. It's only meaningful to the device's firmware if it is signed by the device's manufacturer.
elegos said:
Hello!
2. how can I install busybox manually? Can I create a script which does the job for me (i.e. busybox --install command at first boot then delete the script itself), avoiding me to write loads of symlinks?
Click to expand...
Click to collapse
Certainly. You can add a script and call it from updater-script during the install.
elegos said:
Hello!
3. when I've created an update.zip, is it easy to root the ROM? I mean, just push su and SuperUser.apk? Or I need a particular boot.img?
Thanks
Click to expand...
Click to collapse
Boot image is irrelevant to a properly rooted system. Just adding SuperUser should be sufficient.
That's cool!
1. as of the system.img, I see there is a system folder too - is that just enought zipping it?
2. may you please tell me how to call a script within an edify updater-script please?
3. thanks
I don't understand. You have a system.img and a system folder? In what? What are you starting from? If you use a zipped system, you WILL need to set unix permissions, symlinks and modes as these are NOT preserved in a zip file.
As far as calling scripts, something like this:
run_program PACKAGE:installbusybox.sh
I'm trying to change $PATH to have /system/xbin/ before /system/bin/.
I could do this manually but I'm lazy, so I'm looking for a way to have it like that on boot. But no matter whether I change it in init.rc, fota.rc, recovery.rc, they're all back in the old order after a reboot.
Anyone know which file I have to change to make my path changes stick?
XlAfbk said:
I'm trying to change $PATH to have /system/xbin/ before /system/bin/.
I could do this manually but I'm lazy, so I'm looking for a way to have it like that on boot. But no matter whether I change it in init.rc, fota.rc, recovery.rc, they're all back in the old order after a reboot.
Anyone know which file I have to change to make my path changes stick?
Click to expand...
Click to collapse
The init.rc file is a part of the initramfs which is included in the kernel image (zImage). You need to change the init.rc and recompile the kernel with the updated initramfs to make the changes stick.
There is also a way to unpack and repack an existing kernel image, but IMHO recompiling the kernel is much simpler.
hm, compiling kernels isn't really my thing.
is there another way to insert commands into boot process or change path on startup?
XlAfbk said:
hm, compiling kernels isn't really my thing.
is there another way to insert commands into boot process or change path on startup?
Click to expand...
Click to collapse
I think if you have a kernel with init.d support, you can just drop a script in the init.d directory and it will get automatically executed.
I think all the custom kernels (at least ones based on Voodoo) have init.d support -- never actually tried this so I am not totally sure about this.
I'm using the hacked voodoo kernel for gingerbread, created a /init.d/test.rc with "export PATH ... " but it didn't work. Is it supposed to be a .rc script? supposed to work in gingerbread kernel?
edit: after a closer looks it seems that the script is not only not run but /init.d is completly and without a trace gone after rebooting
Hi,
When you want to perform some scripts at boot-time, there is two possibilities :
- modify init.rc, but it requires to reflashing the rootfs image (modification in / does not hold after a reboot),
- using an android app like script manager, which will load your scripts at java/dalvik platform boot-time.
I've managed to find a way based on activating tf-daemon, which is a script called by the asus/ventana initrc, but disabled at boot-time. Basically, we're re-enabling this daemon by setting the property tf.enable to yes, and then creating a script called tf-daemon and put it in /system/bin. Since this script is called by init.ventana.rc as root, you can put whatever you want inside this script.
I don't know what is the original purpose of this daemon, but probably it's used by the asus team for internal and debugging purpose.
Be aware that in the next firmware update, this possibility could disappear.Let's hope the asus team does not read this post. Or at least they could allow power users to call custom scripts at boot-time.
As a case study, you will find as attachment a script for loading nfs modules at boot-time.
PS: damn, can't upload. Here is a temporary link : http://dl.free.fr/hwTZ0YBq2
Untar the archive, then su, and sh install.sh
At reboot, you should have nfs modules loaded.
Good find:
I gave this a try just to load a couple of my own modules that work with the kernel I'm using. Works fine -- Thanks, -
Another method is to make a script and just call it in the init.rc. After a firmware update you only have to add the "exec myscript.sh" line to init.rc. I personally prefer this method because it allows me to control when the script is executed, whereas the tf-daemon method is always executed at the same point(AFAIK). Good research though, always nice to know all the boot calls.
Modifying the init.rc was my first shot, but the problem is that init.rc lies in ramdisk. So when trying to modify, the modification does not hold
after reboot. So a real modification involves to reflash rootfs with nvflash, too much hassle for me. The method I'm providing is for lazy ones. ;-)
nice find, but the link is dead, could you please provide a new link for the script?
also, how do I load nfs module for there is none under /lib/modules, compile the kernel myself?
Hi,
I'm new to the business and I spent some time to learn the environment trying different applications and different approaches for almos every action I took. Today, I have not much bigger knowledge, but I finally decided to take few things in my own hands because existing software is not fulfilling my wishes.
I started with this simple script which eases the pain of reinstalling all applications after ROM upgrade. There are few such tools already, but I found those quite bloated with unnecessary thing for my own approach.
With this script I assume:
1. There is/was SSHDroid installed (or any tool with busybox and you can access shell command line) both in old and new ROMs and your ROM have bash installed in /system/bin/.
2. Backup/restore operation includes only INTERNALLY installed applications, it completely ignores SYSTEM and SDCARD installed ones.
3. This is TEMPORARY backup so it should be as fast as possible not caring about occupied space (!). Althought I added -zip parameter to enable compression if you are running out of space on your sd.
4. Installed ROM is clean with no additional apps installed (excluding those needed by the script)
5. You have basic knowledge about bash scripting, because I take NO RESPONSIBILITY of the script behavior or data loss it can do.
So, basically it is simple. It runs like this:
1. On old ROM type: sbackup -backup
2. Flash your ROM
3. On new rom type: sbackup -restore
Just like that. The applications data is tar'ed in one file per application so if you want to get rid of any, just delete it from backup directory. The directory name is same as script name on sdcard but you can change it adding a parameter without a '-' sign at runtime (first non-option parameter is treated as backup directory path). The file is zipped because this forum disallows files without an extension so... it is zipped ;D
It was tested on my fresh LeeDroid 3.3.3 GB AFTER i installed some apps. I backed them up and then restored. All seems to be perfect right now, but I will test it more thoroghly very soon because I'm planninig to have CM7 based ROM too just to choose that I need Sense or not (two nandroids for fast switch weekly ;P).
With this script and MyBackup functionality of backing up contacts, sms, history and similar it should be quite complete approach to restore all the data needed on the fresh ROM. In the future maybe I will look at the MyBackup part too. Maybe.
Feel free to comment, use, suggest or anything you like, and have fun ;P.
How do I run this script? Do i run it from sdcard or from system /bin? When i do it from system bin it says cannot create directory. When i run it from sdcard/sbackup it says permissions denied?
Sent from my ADR6400L using Tapatalk
jgrimberg1979 said:
How do I run this script? Do i run it from sdcard or from system /bin? When i do it from system bin it says cannot create directory. When i run it from sdcard/sbackup it says permissions denied?
Sent from my ADR6400L using Tapatalk
Click to expand...
Click to collapse
And thats why I mentioned in topic about not being a newbie (and I meant not forum newbie but more a linux newbie). The thing is, it's a simple script - without any user-proof capabilities, comments inside or something BUT...
But ok, I will try to help you run it. First of all, you have to set permissions to the script. It has to have executable permission to be run by the system (and I mean filesystem permission). This can be done by chmod instruction of busybox. Most of the times it's done like this:
chmod 755 filename
This is a reason of not running form sdcard if your sdcard is NOT ext filesystem (it is usually windows fat filesystem not to generate problems with reading it under windows).
Second thing to run is to have /system/bin/bash because first line of the script (a comment like this: #!/system/bin/bash) instructs busybox to execute script using bash. This can be simply changed by modifying this line, but you have to remember that changing the shell executing script have consequences. Differens shells have sometimes different syntax, althoght i wrote this script simply so it should run on most of them, especially sh.
Third thing is to have write permissions to the directory in which the backup will be created. In original version of the script it is /sdcard, because backup is made in /sdcard/sbackup. So, you have to check it (second error - problems with creating directory).
And a last tip - it can be run from ANYWHERE. Even if your partition does not alolow executing, you can do it like this:
bash-3.2# /sdcard/test
bash: /sdcard/test: /system/bin/bash: bad interpreter: Permission denied
bash-3.2# . /sdcard/test
OK
bash-3.2#
First try does not succeded, but second did. The trick is a dot which means to execute file with a shell not caring about why or permissions.
And thats most simple introduction I could write. It applies to ANY script you want to run.
Please anyone - if you want me to help, paste your results here because without a precise error message it can be very hard to deduce what caused for example permission denial or anything usual.
For now, I won't add any more error handling, but if there will be more users caring about, I will add it.