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?
Related
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,
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.
This script is built from the knowledge gathered from:
http://forum.xda-developers.com/showthread.php?t=1332629
http://nookdevs.com/NookColor:_Build_the_Original_Kernel
http://nookdevs.com/User_talk:Warewolf
This script will let you extract the ramdisk off of the working kernel and will create a directory with the ramdisk for you to edit to your heart's content. The script will then download dalingrin's kernel source and move back to a known working commit (if it hasn't done this already.) The script will then compile said kernel and merge the new ramdisk to the kernel. The script will give you the option of backing up your current kernel and then pushing the new kernel into your touchpad.
Warning: I am not responsible for any damage that come to your touchpad.
Requirements:
It assumes you have all the required programs to compile the kernel. Maybe v2 will check for this and install the required items.
You must have adb somewhere in your user's PATH.
You must have mkimage in your path. Later versions may do thi for you.
How to use:
Place the script in a folder with a known working boot.img from the Touchpad's CM7.
Open a terminal window and browse to that folder.
Give the script execute permissions:
Code:
$ chmod +x KernelModCorner
Run the script:
Code:
$ ./KernelModCorner
This command bring up the following menu:
Code:
What do you want to do?
1: Extract from boot.img (Warning: This will delete any previously extracted ramdisk.)
2: Recompile kernel and merge with new ramdisk
3: Backup current uImage and transfer new one.
4: Clean up all temporary files and ramdisk (Note: This does not include the kernel sources.)
5: Restore backup.
6: Exit
You can probably figure out which options do what...
I just used it successfully to compile the following kernel (which I also started trying to overclock the GPU in... not sure if it is overclocked at the moment as most adreno's in the past have had their GPU clock locked... test it if you'd like and let me know.)
Great job on this invaluable tool
Thanks
I would suggest posting which kernel/CM release this script is intended to work with
since it is highly version specific.
The ramdisk offset being used will only work with one version. Also, there could be a mismatch between the git commit being used and any newer ramdisk/system.
To make the script less version specific, you could use uimage-extract available in the tools dir of the moboot source (see http://code.google.com/p/moboot/source/browse/#git%2Ftools). To compile, add "-lz".
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
MyMinds_Kernel_Swap
===================
Based on AnyKernel, but pretty much rebuilt in every way so that it will actually work. So, many thanks to Koush for the idea.
The Idea and What It Does...
=======================
Some but not all of this script has been snippets here and there from ArchiKitchen and DSIXDA Kitchen.
This has allowed me to formulate a zip as such without the need to technically build from scratch saving me LOADS OF HOURS.
It currently uses my static compiled mkbootimg, unmkbootimg, and mkbootfs binaries to allow editing, and rebuilding of the boot.img.
Some serious modifications were made to get this to work successfully with MUCH DEBUGGING. If you change something and it breaks another function then that is on you!
# IT IS CURRENTLY STABLE!
1. It will pull your current boot.img using dd.
2. It will search for the Android! header in the boot.img and remove the unnecessary junk before it if needed to.
3. It will split the boot.img in to the kernel and ramdisk.
4. It will unpack the contents inside the ramdisk.
5. It will modify the default.prop file giving you insecure ADB. If you already have it then this will not affect you.
6. It will modify the init.rc file to give support for init.d. If you already have it then this will not affect you.
7. It will write to sysinit and install-recovery.sh for the completion of init.d support. If already done, then this will not affect you.
8. It will make the init.d folder under /system/etc on your device with required permissions.
9. It will place an init.d script to test to see if init.d is fully working. If it works, you will find a file called, HAS_INIT, located in the /dev directory of your device.
10. It will swap out the original kernel with a new prebuilt kernel upon rebuilding the new boot.img
11. It will repack you a new ramdisk using mkbootfs to be applied to your new boot.img upon rebuilding it.
12. It will remove your old modules and push your new modules that came with your new prebuilt kernel.
13. It will write your new boot.img to your boot partition using dd.
14. Hopefully, more to come!
MAKE SURE YOU CHANGE...
=======================
"$BOOT_PARTITION" ACCORDING TO YOUR DEVICE BEFORE USING THIS SCRIPT!!!!!!
How to use it...
==============
1. Place your prebuilt kernel in the prebuilt folder and insure it is named, zImage.
2. Place kernel modules in the modules folder.
3. Zip, and flash in TWRP recovery.
If you have any suggestions then let me know. My ears are open to them.
https://github.com/ModdingMyMind/MyMinds_Kernel_Swap
Sent from my C525c using Tapatalk