[Q] Desperately need help running CWM Shell scripts - General Questions and Answers

I need help figuring out why one script runs and another does and it doesn't help with the fact that I'm still quite new to Shell Scripting, let alone running them in CWM on Android devices.
Here's my problem:
This works:
Code:
#!/sbin/sh
busybox echo "#BlahBlahBlah" >> /system/build.prop
This will not:
Code:
#!/sbin/sh
busybox sed -e '/#BlahBlahBlah/d' /system/build.prop > /system/build.prop.bak
Yet, the above WILL run inside the OS. If I boot up fully and use something like Script Manager or Busybox Installer (the script running function) and run the above... it works.
But, in CWM, it doesn't.
I'm trying to use this to make an uninstaller for certain mods that write to the build.prop. So far, my only method for doing this is to copy over a new, unmodded build.prop, which is not very elegant and only works for one type of phone.
Any help would be greatly appreciated

Kryten2k35 said:
I need help figuring out why one script runs and another does and it doesn't help with the fact that I'm still quite new to Shell Scripting, let alone running them in CWM on Android devices.
Here's my problem:
This works:
Code:
#!/sbin/sh
busybox echo "#BlahBlahBlah" >> /system/build.prop
This will not:
Code:
#!/sbin/sh
busybox sed -e '/#BlahBlahBlah/d' /system/build.prop > /system/build.prop.bak
Yet, the above WILL run inside the OS. If I boot up fully and use something like Script Manager or Busybox Installer (the script running function) and run the above... it works.
But, in CWM, it doesn't.
I'm trying to use this to make an uninstaller for certain mods that write to the build.prop. So far, my only method for doing this is to copy over a new, unmodded build.prop, which is not very elegant and only works for one type of phone.
Any help would be greatly appreciated
Click to expand...
Click to collapse
Same problem here; have you found a solution?

Related

[MOD][HOW TO][Update: 05-Aug-2011] 2nd-init port for Milestone2

Credit for koush for Droid2 Bootstrap
Credit for edgardcastro for sharing lots of information about 2nd-boot on Milestone1
Credit for Skrilax_CZ for 2nd-init and sh hijack
If you just want to install 2nd-init on your phone you can skip the whole guide and flash update-2nd-init.zip into your phone. As usual I will not hold responsibility to any damages it may cause.
WARNING: Use this ONLY if you know exactly what you are doing. This guide will make major changes in the /system partition and may turn the phone inoperative. I won’t hold responsibility if you brick your phone or to any damages it may cause.
Pre-requisites: A computer with Android SDK and ADB drivers installed and working. It’s recommended to have RSD Lite 4.9 and the appropriate SBF image just in case anything goes wrong.
This guide was made using a Brazilian Motorola Milestone2 based on Brazil Retail SBF and a computer running Windows Vista 32-bits. I started it from the scratch by flashing my phone with RSD Lite 4.9 and performing a full data/cache wipe, just to make sure any changes were discarded.
Note: Commands that should be entered in command prompt will be listed as: “C:\> <command>”. Commands issued to ADB Shell will be listed as: “# <command>”.
1. Enable USB Debugging on your phone;
2. Get permanent root. I used the app z4root which can be found here on XDA;
3. Install Droid2 Bootstrap. It may be downloaded from Market to support the developer. More info here http://www.koushikdutta.com/2010/08/droid-x-recovery.html;
4. Open Droid2 Bootstrap and click “Bootstrap Recovery”;
5. Use bootstrap to reboot into Clockwork Recovery and backup your phone;
6. Reboot;
7. C:\> adb remount
8. # stop
9. # mkdir /system/etc/rootfs
10. # cp /*.rc /system/etc/rootfs
11. # mkdir /system/etc/init.d
12. # cp /system/bin/sh /system/bin/_sh
13. # cp /init_prep_keypad.sh /system/bin
14. C:\> adb push sh_hijack.sh /system/bin/
15. C:\> adb push 2nd-init /system/bin/
16. C:\> adb push sysinit /system/bin/
WARNING: at this point you should keep a terminal window (adb shell) opened before replacing the 'sh' binary. This is so because you wont be able to open a new abd shell window to run the chmod command.
17. C:\> adb push sh /system/bin/
18. # chmod 755 /system/bin/sh
19. # chmod 755 /system/bin/sh_hijack.sh
20. # chmod 755 /system/bin/2nd-init
21. # chmod 755 /system/bin/sysinit
22. # ln -s /system/bin/busybox /system/xbin/mount
23. # ln -s /system/bin/busybox /system/xbin/rmdir
24. # ln -s /system/bin/busybox /system/xbin/cp
25. # ln -s /system/bin/busybox /system/xbin/umount
26. # ln -s /system/bin/busybox /system/xbin/run-parts
27. # reboot
28. At this point you should be getting into Clockwork Recovery every time, no matter how many times you have rebooted or if you’ve taken the battery of or not. THIS IS NORMAL. It means that the 2nd-boot + sh hijack is working as it should. The boots into clock recovery are caused by a conflict between sh hijack and logwrapper hijack (used by Droid2 Bootstrap). Continue the guide to fix this issue.
29. In clock recovery menu go to: mounts and storage>mount /system;
30. Open ADB Shell again (it will be available in clockwork recovery as well);
31. # cp /system/bin/logwrapper.bin /system/bin/mylogwrapper
32. C:\> adb pull /system/etc/rootfs/
33. Open init.rc and init.mapphone_umts.rc into a text editor that preserves unix end-line format (e.g.: notepad++). Find all entries of “/system/bin/logwrapper” replacing for “/system/bin/mylogwrapper”.
34. In init.mapphone_umts.rc find entry for “exec /init_prep_keypad.sh” replacing for “exec /system/bin/init_prep_keypad.sh”. Add the following text to the end of this file to be able to run all scripts in /system/etc/init.d at boot time:
Code:
service bootscripts /system/bin/sysinit
class post-zygote_services
disabled
oneshot
35. Save and close.
36. C:\> adb push init.rc /system/etc/rootfs/
37. C:\> adb push init.mapphone_umts.rc /system/etc/rootfs/
38. # chmod 755 /system/etc/rootfs/init.rc
39. # chmod 755 /system/etc/rootfs/init.mapphone_umts.rc
40. Choose “Reboot system now” in clock recovery menu;
You’re all set! Now it is just a matter of changing the rc files in /system/etc/rootfs to customize your system boot.
If you want to log the system boot you may also copy the provided log-init.sh script into /system/etc/rootfs and uncomment the line “exec /log_init.sh” from my init.rc file. Doing so will create the /data/logcat.log file that may get huge in sometime.
2nd-init files and my modified *.rc files attached.
Have fun!
UPDATED to version 2.0.0 (froyo) this version exploits /system/bin/mount_ext3.sh instead of sh binary. It's a new method I developed in order of starting 2nd-init earlier but also keeping compatibility with Droid2bootstrapper (recovery takes place first). This might help me booting Leaked GB from 2nd-init, which wasn't possible on the previous version. Take note it's not ready yet to apply on GB.
I just missed the exec /system/bin/init_prep_keypad thanks!
What is this for?
Sent from my A953 using XDA App
inheme said:
What is this for?
Sent from my A953 using XDA App
Click to expand...
Click to collapse
A method to customize initialization scripts of android system. It's a major hack used be some Milestone1 custom ROM's. I've succeeded into porting this to MS2, and I think some modders here of XDA may be interested into adding this to custom ROM's. It may be added to the stock ROM (as I did) but it is not something that everyone is willing to try.
Word of advise: If you don't know what it is you don't need it
Ok thanks for the explanation
So it means that custom roms will be easier to create?
Sent from my A953 using XDA App
That's some major news for our little community.
Tell me if I'm wrong, but since init starts after the kernel is loaded, it's not useful at all for loading a custom kernel, true?
But having a custom init script is a step to CyanogenMod 6 port on Milestone 2, still true?
Anyways, great job, and great howto.
momus87 said:
That's some major news for our little community.
Tell me if I'm wrong, but since init starts after the kernel is loaded, it's not useful at all for loading a custom kernel, true?
Click to expand...
Click to collapse
To load a custom kernel we'll need that kexec hack that team freemymoto is working on.
But having a custom init script is a step to CyanogenMod 6 port on Milestone 2, still true?
Click to expand...
Click to collapse
Well, it's possible, but I believe the big issue here is the impossibility of running custom kernels. Even so, a skilled Modder may be able to overcome that and port CM6 to MS2 using Motorola's stock kernel. It has been done for the MS1.
Anyways, great job, and great howto.
Click to expand...
Click to collapse
You're welcome.
Thanks, r2beta0... this is going to help us out a lot!
r2beta0 said:
Well, it's possible, but I believe the big issue here is the impossibility of running custom kernels. Even so, a skilled Modder may be able to overcome that and port CM6 to MS2 using Motorola's stock kernel. It has been done for the MS1.
You're welcome.
Click to expand...
Click to collapse
Guess that would be me
nah just kidding. I've just happened to have some luck porting Froyo and Gingerbread to the bootloader-locked x10 mini pro. I've just ordered my milestone 2 and I will work on CM6. AWESOME JOB on the 2nd init man! Really, thanks!!
edit: just can't stop thanking you! You saved me a lot of work and porting CM will be easy as sh*t for me now! THANKS
Mikevhl said:
Guess that would be me
nah just kidding. I've just happened to have some luck porting Froyo and Gingerbread to the bootloader-locked x10 mini pro. I've just ordered my milestone 2 and I will work on CM6. AWESOME JOB on the 2nd init man! Really, thanks!!
edit: just can't stop thanking you! You saved me a lot of work and porting CM will be easy as sh*t for me now! THANKS
Click to expand...
Click to collapse
You're welcome! You can count on me to provide as much help as I can to free our MS2's from Motorola's hand. I would be very grateful if you could share your knowledge of porting CM to locked devices. I was trying to port MIUI and Shadow mod BR to MS2 but I got stuck when dealing with proprietary files.
Sent from my A953 using XDA App
@r2beta0
Could this port work on Motorola defy?
Sent from my MOTO Defy
demolition23 said:
@r2beta0
Could this port work on Motorola defy?
Sent from my MOTO Defy
Click to expand...
Click to collapse
It's very likely, since the 2 devices are very similar. Most of the files I attached are from Milestone1 and works perfectly on MS2. Though I recommend you to NOT replace your *.rc files with the attached ones since they could be not compatible. It would be better if you edit your own files. Also try it ONLY if you have a working version of ClockworkMod Recovery (or other custom recovery). You may adapt this guide for your device and post it here on XDA, just remember to mention my name on credits
Already posted and hoping someone to port this..
http://forum.xda-developers.com/showthread.php?t=1003449
demolition23 said:
Already posted and hoping someone to port this..
http://forum.xda-developers.com/showthread.php?t=1003449
Click to expand...
Click to collapse
BTW, why do you want to use 2nd-init? You know, this guide is more inclined for devs/mods who want (need) to include this feature on their ROM's. With this you can change the way things are loaded on linux system before android starts up. But to take advantage of that you should know a lot about how linux works and so on. Regular users should look for a ROM based on the features he needs. Most ROM's already have 2nd-init implemented, but it's not something users are aware of.
Possible issue I've come across:
When replacing sh, i can no longer re-open the shell for obvious reasons... potentially I need to already have a second terminal open with shell running in it already?
SBFing and trying again :3
smacky_wolf said:
Possible issue I've come across:
When replacing sh, i can no longer re-open the shell for obvious reasons... potentially I need to already have a second terminal open with shell running in it already?
SBFing and trying again :3
Click to expand...
Click to collapse
I had no such issue here. When executing the steps of this guide I kept two windows opened all the time. One command prompt to run adb push/pull and another window running adb shell.
Thanks to point that out! I will post a warning in the main post. You should have a adb shell window already running to be able to run chmod just after replacing sh.
But don't worry, you don't need to SBF. Just reboot into clockwork recovery, mount /system via menu, and open your adb shell. It uses a different shell so you can fix the problem in /system/bin.
Looks like Motorola Defy now has CyanogenMod 7 using 2nd-init script! Wish same were the case for MS2.
syl0n said:
Looks like Motorola Defy now has CyanogenMod 7 using 2nd-init script! Wish same were the case for MS2.
Click to expand...
Click to collapse
I'm on it, but development is slow
No necessary to use 2nd init.
Just install "droid 2 bootstrap" and Rom Manager will work perfectly.
keylight65 said:
No necessary to use 2nd init.
Just install "droid 2 bootstrap" and Rom Manager will work perfectly.
Click to expand...
Click to collapse
What are you talking about? This guide isn't related to ROM Manager.

Load Kernel Modules On Boot?

Hi guys,
I'm trying to get my Xoom to load some kernel modules automatically when it restarts/boots. I placed the built .ko files in /system/lib/modules, and I tried to edit/replace both init.rc and init.stingray.rc, but they seem to get overwritten by the default file whenever the Xoom restarts. I figured I'd create a service in init.rc that would load the modules (insmod) directly, or call a shell script to load the modules, but neither worked when the init files get overwritten every time. Is there a better solution or way to avoid this?
Thanks in advance for any help.
i will post a init script that will load them tomorrow. Use modprobe for modules. It installs the entire driver stack. Insmod often gives errors because some drivers, like compat-wireless, have 6 or 7 modules. And they have to be loaded in correct order. Modprobe handles all that automatically.
bigrushdog said:
i will post a init script that will load them tomorrow. Use modprobe for modules. It installs the entire driver stack. Insmod often gives errors because some drivers, like compat-wireless, have 6 or 7 modules. And they have to be loaded in correct order. Modprobe handles all that automatically.
Click to expand...
Click to collapse
Thanks bigrushdog, much appreciated. I only use insmod for single modules, and I'm sure it works because when I run it manually it correctly loads and starts the modules I'm using (they are all self-contained single modules with no deps). How do you modify the init scripts so that they are not erased when the device is rebooted?
mattberman said:
Thanks bigrushdog, much appreciated. I only use insmod for single modules, and I'm sure it works because when I run it manually it correctly loads and starts the modules I'm using (they are all self-contained single modules with no deps). How do you modify the init scripts so that they are not erased when the device is rebooted?
Click to expand...
Click to collapse
My bad. I "assumed" you were unlocked and root. Otherwise it becomes many factors more difficult. You would have to write an app extending service. Even then you may not be able to set perms high enough without being root.
bigrushdog said:
My bad. I "assumed" you were unlocked and root. Otherwise it becomes many factors more difficult. You would have to write an app extending service. Even then you may not be able to set perms high enough without being root.
Click to expand...
Click to collapse
I am unlocked and rooted. Sorry, maybe my description of the problem was vague. I'm trying to edit any of the boot scripts to load my kernel modules when the device resets. Whenever I make any edits, they are lost when the device reboots, and my commands/scripts are never called.
That is because the init scripts are in the ramdisk.
drop this in /system/etc/init.d
give it a filename like "06loadModules"
Code:
#!/system/bin/sh
#
# Load any extra modules
MODPATH=/system/lib/modules/
for i in `ls $MODPATH | grep -v bcm4329.ko`
do
modprobe `basename $i .ko` >/dev/null 2>&1
done
exit 0
dont forget to
Code:
chmod 755 /system/etc/init.d/06loadModules
this will cleanly install all modules in /system/lib/modules on boot
bigrushdog said:
drop this in /system/etc/init.d
give it a filename like "06loadModules"
Code:
#!/system/bin/sh
#
# Load any extra modules
MODPATH=/system/lib/modules/
for i in `ls $MODPATH | grep -v bcm4329.ko`
do
modprobe `basename $i .ko` >/dev/null 2>&1
done
exit 0
dont forget to
Code:
chmod 755 /system/etc/init.d/06loadModules
this will cleanly install all modules in /system/lib/modules on boot
Click to expand...
Click to collapse
I don't have an /init.d folder in /system/etc; don't only certain ROMs use init.d? I'm not using any ROM, so maybe that is the problem. If the init scripts are stored in the ramdisk, can I just extract the ramdisk, edit the init scripts and reflash? I know that's more of a hassle, but it should work the same way right? Thanks again for your help.

Better integrating Busybox (2012-11-17)

Most Android ROMs use toolbox as primary binary with symlinks in /system/bin and /system/xbin. The problem with toolbox is that it sucks. On some ROMs it's even so limited that it does not even allow for --prefix
Busybox is a great replacement for toolbox, but in order to use it, you have to call it using 'busybox cmd'. I would much rather use it by calling 'cmd' but this would execute toolbox instead of busybox.
Most would think the command 'busybox --install' would fix this, but it does'nt. It tries to install links at /bin and /sbin.
The script below will replace any toolbox links in /system/bin and /system/xbin that is supported by the busybox version installed on the Android device running the script. This will make busybox the default binary when executing regular commands without adding 'busybox' at the beginning of the command.
For an example 'ls' instead of 'busybox ls'
Download as an update.zip
v1.3.0 (Nov 17, 2012) (MD5: c233964f0f62a16d7376739041e8b250) - busybox_installer.zip (Only for ArmV7 devices)
v1.3.0 (Nov 17, 2012) (MD5: e921a6c4119644a18d4feea565824ab1) - busybox_installer-nobin (Without binaries)
busybox.sh
Code:
#!/sbin/sh
for cmd in test find basename readlink ln rm; do
eval export "_$cmd=\"/sbin/busybox $cmd\""
done
_busybox=$($_find /system -type f -name "busybox")
_toolbox=$($_find /system -type f -name "toolbox")
if $_test -e "$_busybox" && $_test -e "$_toolbox"; then
sToolboxList="watchprops wipe vmstat date uptime reboot getevent getprop setprop id iftop ioctl ionice log lsof nandread newfs_msdos notify ps r schedtop sendevent setconsole setprop sleep smd start stop top"
sBusyboxList="`$_busybox --list`"
for applet in $sBusyboxList; do
if $_test -L /system/bin/$applet; then
if $_test "`$_basename $($_readlink -f /system/bin/$applet)`" = "toolbox"; then
$_ln -sf $_busybox /system/bin/$applet
if $_test -L /system/xbin/$applet; then
$_rm -rf /system/xbin/$applet
fi
fi
elif $_test -L /system/xbin/$applet; then
if $_test "`$_basename $($_readlink -f /system/xbin/$applet)`" = "toolbox"; then
$_ln -sf $_busybox /system/xbin/$applet
fi
elif ! $_test -e /system/bin/$applet && ! $_test -e /system/xbin/$applet; then
$_ln -sf $_busybox /system/bin/$applet
fi
done
for applet in $sToolboxList; do
$_ln -sf $_toolbox /system/bin/$applet
done
fi
Toolbox install links
watchprops, wipe, vmstat, date, uptime, reboot, getevent, getprop, setprop, id, iftop, ioctl, ionice, log, lsof, nandread, newfs_msdos, notify, ps, r, su, schedtop, sendevent, setconsole, setprop, sleep, smd, start, stop, top
Busybox install links
Whatever the currently installed busybox supports that is not in the list of toolbox install links
Change log
Dec 10 2011, 21:39 UTC:
The script will now leave skip replacing /system/bin/reboot as it needs to be pointed at toolbox
Dec 11 2011, 10:08 UTC:
Added an update zip that will configure busybox and it provides an extended 1.4MB binary instead of the regular 480KB most ROM's provide
Dec 12 2011, 09:25 UTC:
Added new busybox build (1.20.0.git 2011-12-11) since there was problem with the old one for some people
Added more busybox search dirs (/system/sbin and /sbin)
Added Toolbox install to make sure that some android specific links uses toolbox instead of busybox. See list above.
Jun 27 2012, 13:45 UTC:
Better Busybox and Toolbox search
Added symlink check to make sure that busybox only replaces toolbox links and not things like "sh -> mksh"
Nov 17 2012, 10:30 UTC:
Added a custom toolbox binary to the ArmV7 installer
Added latest CM9 busybox binary to the ArmV7 binary
Added an auto search function to locate the binaries on the device
Fixed both installers to work with newer devices that uses EXT4 file system
Thanks, dk_zero-cool. I've been looking for a guide to installing BusyBox, since I can only find an add-supported installer in the Android Market.
Thanks, nice job!!
Ran the script, worked and did fine....ONE BIG ISSUE....now if you have any script or app that relies on the "reboot" function, it no longer works. For example, rom manager & bootstrapper will not boot into recovery. I even open up terminal and typed:
Code:
$ su
# reboot
...and nothing...does the reboot in /bin need to not be linked to busybox?
KMDonlon said:
Ran the script, worked and did fine....ONE BIG ISSUE....now if you have any script or app that relies on the "reboot" function, it no longer works. For example, rom manager & bootstrapper will not boot into recovery. I even open up terminal and typed:
Code:
$ su
# reboot
...and nothing...does the reboot in /bin need to not be linked to busybox?
Click to expand...
Click to collapse
Try to relink it back to toolbox and then I will update the script to leave reboot alone.
1: mount -o remount,rw /system
2: rm -r /system/bin/reboot
3: ln -s /system/bin/toolbox /system/bin/reboot
Great! Will try again!
Cool... can I steal this?
I'd implement it with a busybox install script
I'm not a super expert on the subject but is /system/sbin a possible location?
zeppelinrox said:
Cool... can I steal this?
I'd implement it with a busybox install script
I'm not a super expert on the subject but is /system/sbin a possible location?
Click to expand...
Click to collapse
You can use this as you like.
And you can type "echo $PATH" in an adb shell, if /system/sbin is there, then it will work. But why? /system/xbin is usually the default dir for placing busybox, otherwise /system/bin. And you will have to change the script since it will only check in /system/bin and /system/xbin
All times in my scripts report UTC time instead of system time, I am sure there is one other applet in /bin that was linked to toolbox that is now linked to busybox and reporting the date wrong or at least the date/time that busybox says (UTC time).
KMDonlon said:
All times in my scripts report UTC time instead of system time, I am sure there is one other applet in /bin that was linked to toolbox that is now linked to busybox and reporting the date wrong or at least the date/time that busybox says (UTC time).
Click to expand...
Click to collapse
Do the same as before, only this time replace 'reboot' with 'date'
This must be a setting in the busybox compile menu. A new binary might fix this because busybox should be able to display system time. But for now point date back to toolbox and it will work for you.
Yup, did what you just said and all is fine. Thanks! Is there a way you can implement the reboot and date applet ignore in the script within the .zip you made.... I think it will save users some headaches.
dk_zero-cool said:
You can use this as you like.
And you can type "echo $PATH" in an adb shell, if /system/sbin is there, then it will work. But why? /system/xbin is usually the default dir for placing busybox, otherwise /system/bin. And you will have to change the script since it will only check in /system/bin and /system/xbin
Click to expand...
Click to collapse
Well bb is sometimes installed elsewhere.
At first SuperCharger only looked in those 2 locations and stopped when it wasn't found.
What would happen if there was a second version elsewhere?
I suppose it wouldn't matter because of the symlinks.
KMDonlon said:
Yup, did what you just said and all is fine. Thanks! Is there a way you can implement the reboot and date applet ignore in the script within the .zip you made.... I think it will save users some headaches.
Click to expand...
Click to collapse
The reboot fix is already in the zip file.
The date fix I don't want in it, I would much rather fix busybox to work properly.
I'm currently looking at that.
zeppelinrox said:
Well bb is sometimes installed elsewhere.
At first SuperCharger only looked in those 2 locations and stopped when it wasn't found.
What would happen if there was a second version elsewhere?
I suppose it wouldn't matter because of the symlinks.
Click to expand...
Click to collapse
No that does not mater because of the symlinks.
That's why I referrer to the complete path, f.eks, "/system/xbin/busybox" and not just the binary name "busybox".
I am going to try your binary for Busybox and see, I am currently using JRummy's BB installer which installed v1.19.3 which is about 1.06MB....
EDIT: Just flashed the .zip, my phone will not boot past the logo....did a battery pull several times and can't get into CWR....SBF time
KMDonlon said:
I am going to try your binary for Busybox and see, I am currently using JRummy's BB installer which installed v1.19.3 which is about 1.06MB....
EDIT: Just flashed the .zip, my phone will not boot past the logo....did a battery pull several times and can't get into CWR....SBF time
Click to expand...
Click to collapse
Put in your USB cable, open a terminal/console on your computer and try "adb logcat" to see what it says when it stops booting.
You must of cause have adb installed on your computer, and USB drivers if you use windows, which I don't and cant help with.
Already reflashed phone back....sorry, no logcat....
Do it again...
C'mon take one for the team... hehe...
LMFAO!!!! Sorry dude, I ain't gonna do it....will let some other poor soul ....I got honey do's today, it's Sunday!!
Whatever it was I can't recreate it. Works fine when I flash the damn thing.
Here's a thought.....make a script that reverses the toolbox links, I can undo it and try to flash again....I was unable to manually install your busybox version so I think some other toolbox applet is causing me trouble.....

[Q] My init.d script does not work, why?

Hello,
I want to change my voodoo colors at boot, so I made a script in init.d folder:
Code:
#!/system/bin/sh
echo 2447339790 >/sys/devices/virtual/misc/voodoo_color/red_multiplier
echo 2159029280 >/sys/devices/virtual/misc/voodoo_color/green_multiplier
echo 2782492160 >/sys/devices/virtual/misc/voodoo_color/blue_multiplier
echo -14 >/sys/devices/virtual/misc/voodoo_color/red_v1_offset
echo -17 >/sys/devices/virtual/misc/voodoo_color/green_v1_offset
echo -18 >/sys/devices/virtual/misc/voodoo_color/blue_v1_offset
And here is my init.d folder : http://i.imgur.com/nhkdy.png , 99voodoo is my script.
When I paste this codes to android terminal emulator, it is working flawlessly.
But it does not work in init.d folder. Tried different roms which support init.d scripting, but no luck.
What is wrong with it? Can anyone help?
Thanks.
I had the same issue with couple of kernels not sure why im prety sure they even support (Eugene and glados)
you have to set full permissions on the script also but still didn't work for me
I gave up and just used ROM toolbox and made it run at startup works no problem
There must be a solution. What am I doing wrong!?
Do you have Busybox installed?
Hostile89 said:
Do you have Busybox installed?
Click to expand...
Click to collapse
Yes, preinstalled with the rom I've been using:
http://forum.xda-developers.com/showthread.php?t=1397358
features "root, busybox, zipalign, Bash, init.d scripts ... etc".
Any help? No solution?
What is your ROM and kernel combination?
I was using Aosp+ Rom and ICUP-Speedy-3 kernel.
Now, I have just flashed CyberGR rom. Comes with GLaDOS 2.7 kernel. Feature list says "Init.d scripts support", but no luck for me. My script doesn't work with this rom too. What is wrong with it :S
I found the solution.
I was trying to move my script to init.d folder manually via RootExplorer app.
But pushing the same file via adb just worked.
Thanks to this: http://forum.xda-developers.com/showthread.php?t=1424032

Tip (and question): Use busybox instead of toolbox (ICS)

Hey, guys. I noticed ICS comes with a shell tool called "toolbox" (or maybe it's just my ROM). The traditional tool, called Busybox, is also installed. This tool is much more powerful--if basic shell commands like "mv" don't work properly, toolbox is probably to blame.
Or my system, the shell is mksh and the toolbox tools are installed in /system/bin and busybox is in /system/xbin. Is this the same on all ICS ROMs?
The command to modify the system path so the busybox tools are called preferentially to the toolbox tools is the following:
sed '/: place customisations above this line/i\PATH="/system/xbin:$PATH"' -i /etc/mkshrc
Like I said, I'm assuming my ROM is the same as other ROMs. But the point is to find the shell init file and add PATH="/system/xbin:$PATH" to it. As usual, make a system backup before making changes like this.
In this vein, does anybody know how to change the root user's shell? The "chsh" command doesn't exist on Android, nor does /etc/passwd.
What ROM are you using ?
IceColdSandwich (mostly based on AOKP) - http://forum.xda-developers.com/showthread.php?t=1450962
But is the shell and unix toolchain not common to all ICS builds? I don't know why AOKP and or the makers of this build would have chosen to use tools that are so obviously inferior to the more common tools.
To see which environment/toolchain you are using, check out the symlinks for some shell commands:
# ls -l `which mv`
To see if you have busybox installed:
# which busybox
To test it:
# busybox ls /system
To find which file configures your PATH (determines which executables get called):
# grep -r PATH= /etc
If you find a shell init file, you can edit and add the directory you want to the front of the path:
PATH="/directory/containing/busybox:$PATH"
fenstre said:
Hey, guys. I noticed ICS comes with a shell tool called "toolbox" (or maybe it's just my ROM). The traditional tool, called Busybox, is also installed. This tool is much more powerful--if basic shell commands like "mv" don't work properly, toolbox is probably to blame.
Or my system, the shell is mksh and the toolbox tools are installed in /system/bin and busybox is in /system/xbin. Is this the same on all ICS ROMs?
The command to modify the system path so the busybox tools are called preferentially to the toolbox tools is the following:
sed '/: place customisations above this line/i\PATH="/system/xbin:$PATH"' -i /etc/mkshrc
Like I said, I'm assuming my ROM is the same as other ROMs. But the point is to find the shell init file and add PATH="/system/xbin:$PATH" to it. As usual, make a system backup before making changes like this.
In this vein, does anybody know how to change the root user's shell? The "chsh" command doesn't exist on Android, nor does /etc/passwd.
Click to expand...
Click to collapse
You can just change the symlinks, with a quick shell script, run from the directory that has everything simlinked to toolbox
Something like:
for i in `busybox --list`
do
mv $i $i.android
ln -s `which busybox` $i
done
I still don't know the usefulness of busybox
:banghead:
Sent from my Xperia Live with WALKMAN using xda app-developers app

Categories

Resources