test this, this *should* work on locked bootloader devices
download the module http://forum.xda-developers.com/attachment.php?attachmentid=1668583&d=1358911103 and unpack it to
Code:
/system/lib/modules
so it'll be
Code:
/system/lib/modules/cpufreq_smartass2.ko
now open terminal and do
Code:
su
chown root.root /system/lib/modules/cpufreq_smartass2.ko
chmod 0755 /system/lib/modules/cpufreq_smartass2.ko
insmod /system/lib/modules/cpufreq_smartass2.ko lookup_address=0xc00d7d50
if no error produce then congratulations, u've got smartassv2 cpu governor loaded into your kernel
now just open any cpu manager app like setcpu, nofrills cpu control or any other cpu management app and see if smartassv2 is listed as selectable governor or not, and if its listed, try to select it and use it.
the governor will be removed from kernel when u reboot, so create an init.d script to load it automatically on every boot.
Code:
#!/system/bin/sh
if busybox [ -e /system/lib/modules/cpufreq_smartass2.ko ];
then
chown root.root /system/lib/modules/cpufreq_smartass2.ko
chmod 0755 /system/lib/modules/cpufreq_smartass2.ko
insmod /system/lib/modules/cpufreq_smartass2.ko lookup_address=0xc00d7d50
else
return 0
fi;
or a much simple one
Code:
#!/system/bin/sh
insmod /system/lib/modules/cpufreq_smartass2.ko lookup_address=0xc00d7d50
Sent from my KFTT using xda app-developers app
And what performance you get
stefanescupatronu said:
And what performance you get
Click to expand...
Click to collapse
i did it and dont worked because this smartassv2 isnt modded for our kernel, we need it modded with our kernel and do the same steps
Sent from my KFTT using xda app-developers app
http://forum.xda-developers.com/showthread.php?p=28359509 same kernel but not binaries this is near our compatibility
Sent from my KFTT using xda app-developers app
Related
In this moment I testing.... ramzswap working good and smooth on the stock firmware and I put the overklock module speed is 1.1 Ghz
How to do!!!
insmod /yourpath/lzo_compress.ko
insmod /yourpath/lzo_decompress.ko
insmod /yourpath/ramzswap.ko backing_swap=/data/swap256
swapoff /dev/block/mmcblk0p3
swapon /dev/block/ramzswap0
Swappiness I put to 80...
to see info for ramzswap rzscontrol /dev/block/ramzswap0 --stats
memory limit will be set to 25% of ram....
for oveclock u must first find the table_addr u do with this
grep omap2_clk_init_cpufreq_table /proc/kallsyms
insmod /yourpath/overclock.ko omap2_clk_init_cpufreq_table_addr=0xc005e430 max_rate=1100000 max_vsel=68
and must have root...
Sent from my A70H using xda premium
have fun !!!
Yes, I've done the same thing, though without the overclock module. I've also built rzscontrol for arm. In general, I'm very happy with it. I don't use the backing-store option, because the general consensus is that this feature is less efficient than just having a lower-priority regular swap file/partition, and shouldn't have been implemented.
Yes I know
Sent from my A70H using xda premium
Thanks for this overclock kernel..
When I try to install module ramzswap it says "invalid argument" for /data/swap256...
What I am doing wrong?
Thanks
djassa1 said:
When I try to install module ramzswap it says "invalid argument" for /data/swap256... What I am doing wrong?
Click to expand...
Click to collapse
/data/swap256 doesn't exist. You would need to create it first.
# dd if=/dev/zero of=/data/swap256 bs=1M count=256
# mkswap /data/swap256
But that's not really necessary, because ramzswap doesn't really need the backing-swap option as long as you have actual swap available with a lower priority than the ramzswap device. Change that line to
# insmod /yourpath/ramzswap.ko
Keep the rest of the lines in order. Then
# swapon /dev/block/mmcblk0p3
This will re-enable your original swap device, but with a lower priority than /dev/swap/ramzswap0, since it was added later.
Or do this :
insmod ramzswap.ko disksize_kb=20480
swapoff /dev/block/mmcblk0p3
swapon /dev/block/ramzswap0
swapon /dev/block/mmcblk0p3
For backingswap you must copy the swap256 to your /data folder I put in zip the swap256 file....
Sent from my A70H using xda premium
Check this out guys perfect build.prop tweaks which is aligned properly and with auto permission scripts.
Build.prop is sample u can follow the same method which i currently using...
The script function say example when you copy paste or push apk files into system/app or system/framework it will auto set permission for you according like other apk perm...
The script need to be place in system/etc/init.d but for this you must give a permission to followup later just simply move your framework without give permission and restart see it will boot perfectly without any bootloop.
Give a try and please forgive if i wrote anything wrong
VillainZ said:
Check this out guys perfect build.prop tweaks which is aligned properly and with auto permission scripts.
Build.prop is sample u can follow the same method which i currently using...
The script function say example when you copy paste or push apk files into system/app or system/framework it will auto set permission for you according like other apk perm...
The script need to be place in system/etc/init.d but for this you must give a permission to followup later just simply move your framework without give permission and restart see it will boot perfectly without any bootloop.
Give a try and please forgive if i wrote anything wrong
Click to expand...
Click to collapse
Mind to share what tweeks are included in those file?
luiphilip said:
Mind to share what tweeks are included in those file?
Click to expand...
Click to collapse
In the 57zVillainz one i found these, for anyone else who's curious
logFile=/data/logs/perms.log
if [ -f $logFile ]; then
rm $logFile
fi
touch $logFile
mount -o rw,remount /dev/block/stl9 /system
echo "Setting permissions" >> $logFile
for file in /system/app/* /system/framework/* /data/app/*; do
echo " setting permissions (644) for $file" >> $logFile
chmod 644 $file
done
echo "chmodding init.d folder"
chmod 755 /system/etc/init.d
for file in /system/etc/init.d/*; do
echo " setting permissions (755) for $file" >> $logFile
chmod 755 $file
done
echo "Permissions set" >> $logFile
RohinZaraki said:
In the 57zVillainz one i found these, for anyone else who's curious
logFile=/data/logs/perms.log
if [ -f $logFile ]; then
rm $logFile
fi
touch $logFile
mount -o rw,remount /dev/block/stl9 /system
echo "Setting permissions" >> $logFile
for file in /system/app/* /system/framework/* /data/app/*; do
echo " setting permissions (644) for $file" >> $logFile
chmod 644 $file
done
echo "chmodding init.d folder"
chmod 755 /system/etc/init.d
for file in /system/etc/init.d/*; do
echo " setting permissions (755) for $file" >> $logFile
chmod 755 $file
done
echo "Permissions set" >> $logFile
Click to expand...
Click to collapse
So in other words it just sets permissions for certain files in /system and /data every boot?
Sent from my E15i using Tapatalk 2
SpyderX said:
So in other words it just sets permissions for certain files in /system and /data every boot?
Sent from my E15i using Tapatalk 2
Click to expand...
Click to collapse
What is the general effect/outcome if I run this script?
Sent from my WT19i using XDA
SpyderX said:
So in other words it just sets permissions for certain files in /system and /data every boot?
Sent from my E15i using Tapatalk 2
Click to expand...
Click to collapse
Looks like it
Sent from my E15i using Tapatalk
luiphilip said:
What is the general effect/outcome if I run this script?
Sent from my WT19i using XDA
Click to expand...
Click to collapse
Say if you replace certain files in/system to apply a fix or a tweak, and you forgot to change permissions, this will automatically fix it such that you will not get a boot loop.
Sent from my E15i using Tapatalk 2
SpyderX said:
Say if you replace certain files in/system to apply a fix or a tweak, and you forgot to change permissions, this will automatically fix it such that you will not get a boot loop.
Sent from my E15i using Tapatalk 2
Click to expand...
Click to collapse
Thanks for the brief explanation, im new on android and this script mods is somehow not implemented by default. Again, thanks bro.
Sent from my WT19i using XDA
I'm trying to automate some things I do after upgrading nightlies using a shell script. The system seems to execute the shell script (shows messages informing granting of root privileges and successful completion of the script), but the script does not seem to run, ie the changes do not occur. Here's the script if it's of any help :
Code:
#!/system/bin/mksh
# Gain root access
su -
# Replace baseband
rm /system/etc/motorola/bp_nvm_default/*
cp /mnt/sdcard/Download/bp_nvm_default/* /system/etc/motorola/bp_nvm_default/
chown root:root /system/etc/motorola/bp_nvm_default/*
chmod 644 /system/etc/motorola/bp_nvm_default/*
# Make Apex Launcher system app
cp /mnt/sdcard/Download/ApexLauncher.apk /system/app/
chown root:root /system/app/ApexLauncher.apk
chmod 644 /system/app/ApexLauncher.apk
# Move Marimba ringtone to phone
cp /mnt/sdcard/Download/Marimba.ogg /system/media/audio/ringtones/
chown root:root /system/media/audio/ringtones/Marimba.ogg
chmod 644 /system/media/audio/ringtones/Marimba.ogg
I'm amazed there are no replies to this thread.
No one ever tried running a shell script on their rooted phone?
S_xda said:
I'm amazed there are no replies to this thread.
No one ever tried running a shell script on their rooted phone?
Click to expand...
Click to collapse
What did you tried to run the script??, use the terminal or the SManager.
SManager works fine to me
Questions go in the Q&A section
I have been resisting the urge to flash a custom ROM for a bit, but I really miss having init.d support. So I read a few threads for other phones and rolled my own.
Warnings
I borrowed bits and pieces from various places. If you don't know what init.d is, you probably don't want to do this. If you aren't willing to take responsibility for bricking your tablet, don't do this. Seriously, the risk of bricking is very low, but if you aren't comfortable booting into an adb shell from recovery, maybe this is not for you. Strongly suggest a nandroid backup before you get started so if you totally bork things you can just hit rewind.
Note: The latest CWM may prompt you on a reboot that the ROM may overwrite the bootloader and offer to fix it for you. Don't do that. The init.d hack takes over the bootloader install script, but does not change your bootloader! If you accidentally do let it fix things for you, just rebuild the install-bootloader.sh file. The other steps should be fine.
Prerequisites
First, you need root, busybox, and some sort of terminal (either adb, or some terminal you like using on the tablet).
I have found that I like Busybox Installer (from the market; https://play.google.com/store/apps/details?id=com.jrummy.busybox.installer) but for some reason it doesn't create new symlinks unless you click advanced install.
Let's get to it!
In the shell (don't type # or anything after #):
Code:
su # get root
mount -o remount,rw /system # get access to /system (4.04 seems to mount ro as is usual; seems like the original mounted rw)
which run-parts # if you don't see /system/xbin/run-parts you need to install/reinstall busybox; if it is somewhere else, note it
mkdir /system/etc/init.d
Create a file called sysinit -- we are going to put it in /system/bin. You can edit it in place with vi, mount your tablet and edit it on your computer, or create it on the computer and push it via adb. Whatever.
Here's the file (you do need the # and the things after it in the file!):
Code:
#!/system/bin/sh
export PATH=/sbin:/system/sbin:/system/bin:/system/xbin
/system/bin/logwrapper /system/xbin/run-parts /system/etc/init.d
Note that if your run-parts is not in /system/xbin (from the which command) then fix the above to reflect your reality.
In the shell, make it executable
Code:
chmod 755 /system/bin/sysinit
Now go in the init.d directory and create some things you want to run at start up. For example:
Code:
cd /system/etc/init.d
echo '#!/system/bin/sh' >99test # note: you do need the first # in this line but not the 2nd!
echo 'date >>/data/tmp/init.d-log.txt' >>99test
chmod 755 99test
Here's a more practical one (yes, you need the # signs). Name it something like 10diskperf -- don't forget to chmod it.
Code:
#!/system/bin/sh
# Set disk read aheads to 1024
chmod 777 /sys/block/mmcblk0/queue/read_ahead_kb
echo "1024" > /sys/block/mmcblk0/queue/read_ahead_kb
chmod 777 /sys/block/mmcblk1/queue/read_ahead_kb
echo "1024" > /sys/block/mmcblk1/queue/read_ahead_kb
chmod 777 /sys/devices/virtual/bdi/179:0/read_ahead_kb
echo "1024" > /sys/devices/virtual/bdi/179:0/read_ahead_kb
Or here is one to tweak some TCP parameters (25sysctl):
Code:
#!/system/bin/sh
sysctl -w net.core.rmem_max=524288
sysctl -w net.core.wmem_max=524288
sysctl -w net.ipv4.tcp_rmem=6144 87380 524288
sysctl -w net.ipv4.tcp_wmem=6144 87380 524288
Whatever files you put in, you need to remember to make them executable (chmod 755).
Finally, you need to kick it all off at start up. The hack for that is we are going to create /system/etc/install-recovery.sh which apparently runs on each boot.
Code:
cd /system/etc
echo '#!/system/bin/sh' >install-recovery.sh
echo '/system/bin/sysinit' >>install-recovery.sh
chmod 755 install-recovery.sh
Tips and troubleshooting
If you are too lazy to cut and paste I have the files here (View attachment init.d-support.zip) that you can just move to the right places and change permission. If you are really lazy there is lightly tested install script below.
I like to try running the whole thing before a reboot to see if I get any errors:
Code:
/system/etc/install-recovery.sh
I'd suggest putting the 99test file in first. Verify that you get the expected file in /data/tmp and then reboot and check again. Then you can remove 99test.
Same goes for adding new scripts. Try running them from the shell to see if they throw errors before you reboot!
If you have trouble, see if this looks right:
Code:
ls -ld /system/etc/install-recovery.sh /system/bin/sysinit /system/etc/init.d /system/xbin/run-parts
-rwxr-xr-x root root 39 2012-07-14 10:00 install-recovery.sh
-rwxr-xr-x root root 140 2012-07-14 10:01 sysinit
drwxrwxrwx root root 2012-07-14 10:10 init.d
lrwxrwxrwx root root 2012-07-14 09:55 run-parts -> /system/xbin/busybox
For the brave
The install-init.d zip file (View attachment install-init.d.zip) contains a lightly tested script that SHOULD do the install steps for you.
Send the file to your android to someplace that can execute code (e.g., /system/xbin; I had to use adb to put it on the sdcard and then move it to /systemxbin in the shell since I don't have the adb root kernel installed).
Code:
cd /system/xbin # or wherever you have it
chmod 755 install-init.d
./install-init.d
It performs rude checks to see if init.d exists, and tries to handle moving or missing busybox. It only installs 99test as a script.
Let me know if this works or doesn't work for you.
For the extra brave: There is no reason this should only work on the Samsung. This ought to work on pretty much most stock ROMs as long as they execute install-recovery.sh on start up.
Scripts
What do you put in your init.d? If you post anything cool I'll put it up here in the op.
One that gave me some real gains in I/O performance required a new version of the tune2fs executable. By default, it is part of busybox but the busybox one only has a few simple options. I've included a stand alone version and the script 10disktune here View attachment disktune.zip. Unpack the zip and put the 10disktune in /system/etc/init.d (don't forget to chmod) and put tune2fs in /system/bin (chmod that too). Note that busybox has one in /system/xbin but the script specifically calls out the one in /system/bin.
Here's one that will zipalign your apks on each boot
Code:
#!/system/bin/sh
for apk in /data/app/*.apk ; do
zipalign -c 4 $apk
ZCHECK=$?
if [ $ZCHECK -eq 1 ]; then
zipalign -f 4 $apk /cache/$(basename $apk)
if [ -e /cache/$(basename $apk) ]; then
cp -p -f /cache/$(basename $apk) $apk
rm /cache/$(basename $apk)
fi;
fi;
done;
Fin
Corrections welcome. I considered using exec or . to load some of this into one shell but given that it runs once at startup, I figured it is fine as is.
All files for reference
View attachment init.d-support.zip
View attachment install-init.d.zip
View attachment disktune.zip
Great guide, gonna try it tonight.
Sent from a GNote, hell yeah!
SirRhor said:
Great guide, gonna try it tonight.
Sent from a GNote, hell yeah!
Click to expand...
Click to collapse
I'm curious how it went. If you ran into any issues, let me know so I can update the op. Thanks!
Hmm did anyone get this to work?
wd5gnr said:
Hmm did anyone get this to work?
Click to expand...
Click to collapse
I did it on my Galaxy Nexus.
It works great, I had a bit of problem with the sysinit file, but when I downloaded your zip file and used your sysinit, it worked, so it must be a problem from my side
Thanks for this, I can finally use "Odex Me"
aavan said:
I did it on my Galaxy Nexus.
It works great, I had a bit of problem with the sysinit file, but when I downloaded your zip file and used your sysinit, it worked, so it must be a problem from my side
Thanks for this, I can finally use "Odex Me"
Click to expand...
Click to collapse
Great, just wanted to be sure I hadn't made any typos/errors in the guide.
A lot of init.d files collected here: http://forum.xda-developers.com/showthread.php?t=1227269
Also build.prop things, etc.
Thanks, I use your guide and worksperfect for my RK3066 devices. Very simple to understand all steps and what we are doing to our system, perfect for me. Thanks again dude
Melch1zedeK said:
Thanks, I use your guide and worksperfect for my RK3066 devices. Very simple to understand all steps and what we are doing to our system, perfect for me. Thanks again dude
Click to expand...
Click to collapse
Glad to help!
What is thhe utility of this?
moliverac8 said:
What is thhe utility of this?
Click to expand...
Click to collapse
Init.d is how Linux and many Android (which is kind of Linux, after all) systems manage executing commands on boot up.
The /etc/init.d files run in numerical order as root and you can do things like change system settings, manipulate the file system, etc.
See the init.d section linked below for some ideas.
http://forum.xda-developers.com/showthread.php?t=1227269
Question? what is the difference in this method and running a script?
wd5gnr said:
Init.d is how Linux and many Android (which is kind of Linux, after all) systems manage executing commands on boot up.
The /etc/init.d files run in numerical order as root and you can do things like change system settings, manipulate the file system, etc.
See the init.d section linked below for some ideas.
http://forum.xda-developers.com/showthread.php?t=1227269
Click to expand...
Click to collapse
I use the "swap memory script" and was wondering if it would also work this way with the init.d If so would there be any benefit this way over the current way of running it one way or the other? One drawback I see running the script as is is that I have to wait once the system has fully booted until the script has run and I see the Smanager screen to let me know that my memory has been remounted.
Thanks for the info and the learning process.
Here is the script and the link.
http://forum.xda-developers.com/showthread.php?t=1961097
Code:
sleep 5
mount -o remount,rw /
mount -t vfat -o umask=0000 /dev/block/vold/179:25 /mnt/sdcard
sleep 5
mount -o bind /data/media /mnt/extSdCard
As long as the device is ready to mount at boot time and doesn't get remounted, ought to work. Backup and try it
External memory wasn't ready
wd5gnr said:
As long as the device is ready to mount at boot time and doesn't get remounted, ought to work. Backup and try it
Click to expand...
Click to collapse
Thanks for the guide, but I think that the external memory was not ready to be mounted at that time. it didn't see the card till after boot. It was worth a shot, Reverted back to the script in /data and all worked again,
Note: I didn't find /system/xbin/run-parts however, I did find /system/bin/run-parts and changed the path to reflect that, I don't think this was an issue but I'm not 100% sure.
With Android 4.2's multi-user stuff and the dreaded "0" folder, Google broke mounting of CIFS shares for good. (They basically implemented something utterly useless for my needs, and broke something I need on a daily basis.) Cyanogenmod fixed that for mounts outside the /storage hierarchy, but many apps can't go there. And with 4.2.2, Google made using adb on the device very annoying as well, which adds to problems for a workaround for mounting shares in a useful place.
So I looked around for various fixes for that issue and compiled those into one method that works perfectly well for me on a P6810 running the current PAC ROM 20130629. It should probably work for any other CM10.1 or PA3.6x-based ROM as well. A nls_utf8.ko module compiled for the Nexus 10 is included as well, which can be loaded via punchmod (at least in PAC), so you can access shares with Ümläüts in them.
Prerequisites: SManager, SMWidgets, and a working Busybox install (I use Stericson's Busybox Installer).
1.) Extract nls_utf8.ko and punchmod from the attached .zip file and put them in /system/lib/modules. You can put them in some other place as well, but my scripts need to be adjusted then. Next, give the files sufficient permissions:
Code:
chmod 644 /system/lib/modules/nls_utf8.ko
chmod 755 /system/lib/modules/punchmod
2.) Optional: if you want the module to auto-start, create a file called 00punch-nls_utf8 (or whatever you like) with the content below, put it in /etc/init.d and chmod it to 755. To check if nls-utf8 is loaded after a reboot, type lsmod in a terminal window or adb shell - it should display the module name. If punchmod auto-detection fails, read here how to get the right vermagic string for your device: http://forum.xda-developers.com/showthread.php?p=41920265#post41920265
Code:
#!/system/bin/sh
sleep 10
/system/lib/modules/punchmod /system/lib/modules/nls_utf8.ko ""
3.) Here's the script that mounts a CIFS share. Edit the settings on top and either put your correct vermagic string as well, or delete the "$VERMAGIC" part in line 22 and try your luck with auto-detection. I put some sanity checks in the script, but it might not work for all directories in /sdcard (or, /data/media/0, to call it by its 'real' name/location). If you don't want to use the nls-utf8 module, just delete lines 18-23, and iocharset=utf8 in line 67.
Name the script mount-music.sh or something, put the script wherever you like, open SManager and navigate to the script. Run the script with SU permissions. If everything goes well, it will ask you to accept an adb RSA key, and then adb mounts the share. You can also add a desktop widget for quick access to the script with SMWidgets.
Code:
#!/system/bin/sh
# Your settings here
IP="192.168.1.123"
SHARE="Music"
USER="yourusername"
PASS="yourpassword"
MOUNTPOINT="/data/media/0/cifs"
VERMAGIC="3.0.31-CM-ga034655-dirty SMP preempt mod_unload ARMv7 p2v8 "
# Load cifs (if it isn't already loaded)
if [ `lsmod | grep -o cifs` ] ; then
:
else
insmod /system/lib/modules/cifs.ko
fi
# Load nls_utf8 brute-force style (if it isn't already loaded)
if [ `lsmod | grep -o nls_utf8` ] ; then
:
else
/system/lib/modules/punchmod /system/lib/modules/nls_utf8.ko "" "$VERMAGIC"
fi
# Check if cifs $MOUNTPOINT dir exists, create it if not, give sufficient permissions
if [ -d $MOUNTPOINT ] ; then
:
else
mkdir $MOUNTPOINT
fi
chmod 755 $MOUNTPOINT
# Check if $SHARE directory is empty - if not, unmount the share
if [ "$(su root -c busybox ls -A $MOUNTPOINT/$SHARE 2> /dev/null)" == "" ] ; then
:
else
/system/xbin/busybox umount -l $MOUNTPOINT/$SHARE
fi
# Create $SHARE directory if necessary, give sufficient permissions
if [ -d $MOUNTPOINT/$SHARE ] ; then
:
else
mkdir $MOUNTPOINT/$SHARE
fi
chmod 755 $MOUNTPOINT/$SHARE
# Starting adb
adb kill-server
export HOME=/sdcard
# PORT=`getprop service.adb.tcp.port`
setprop service.adb.tcp.port 5555
adb start-server
cat /sdcard/.android/adbkey.pub >> /data/misc/adb/adb_keys
stop adbd
start adbd
adb connect localhost
# Make sure we only use the first device (sometimes there is more than one)
SERIAL=`adb devices | head -n2 | tail -n1 | cut -f1`
if [ "$SERIAL" = "" ] ; then
echo "ERROR: Could not find ADB device.";
fi
# Mounting share via adb
echo Mounting share via adb...
adb -s $SERIAL shell su root -c /system/xbin/busybox mount -t cifs //$IP/$SHARE $MOUNTPOINT/$SHARE -o user=$USER,pass=$PASS,iocharset=utf8,cache=none,directio,CIFSMaxBufSize=130048,rw,file_mode=0777,dir_mode=0777,uid=1015,gid=1015
# If you started adb, then stop it here for security
adb disconnect localhost
stop adbd
PORT=`getprop service.adb.tcp.port`
setprop service.adb.tcp.port $PORT
start adbd
# Show some results
RESULT=`mount | grep $MOUNTPOINT/$SHARE`
if [ "$RESULT" = "" ] ; then
echo "FAILED! //$IP/$SHARE could not be mounted."
else
echo "SUCCESS! //$IP/$SHARE has been mounted on $MOUNTPOINT/$SHARE."
fi
echo
echo All done. You may close this script window now.
4.) This is the script to unmount the share. Name it unmount-music.sh or similar, and edit your settings at the beginning of the script. Again, run it in SManager with SU permissions, and add a desktop widget with SMWidgets if you like.
Code:
#!/system/bin/sh
# Your settings here
SHARE="Music"
MOUNTPOINT="/data/media/0/cifs"
# Check if $SHARE directory exists
if [ -d $MOUNTPOINT/$SHARE ] ; then
# Check if $SHARE directory is empty - if not, unmount the share
if [ "$(su root -c busybox ls -A $MOUNTPOINT/$SHARE 2> /dev/null)" == "" ] ; then
echo "$MOUNTPOINT/$SHARE is empty."
else
su root -c busybox umount -l $MOUNTPOINT/$SHARE
fi
fi
# Show some results
RESULT=`mount | grep $MOUNTPOINT/$SHARE`
if [ "$RESULT" = "" ] ; then
echo "SUCCESS! $MOUNTPOINT/$SHARE has been unmounted."
else
echo "FAILED! $MOUNTPOINT/$SHARE could not be unmounted."
fi
echo
echo All done. You may close this script window now.
Hope this helps some of you. It sure stumped me how incredibly convoluted this simple and much needed procedure has become on Android 4.2.2... just because of that multi-account stuff and new restrictions on adb.
Credits:
Script bits and nls_utf8.ko by H3g3m0n
More script bits by dafunk60 and jmtw000
Punchmod by Jann Horn
Punchmod info by idcrisis
Thanks man, looks awesome, I am going to try it on my 6800.
Do you know how to mount ext4 or ntfs sdcard on CM10.1 based roms?
Removed the original post, still trying to make it work!
I checked vermagic in some existing ko files and found that it is exactly the same as yours.
Sent from my GT-p6800 using Tapatalk HD
m0bster said:
Removed the original post, still trying to make it work!
I checked vermagic in some existing ko files and found that it is exactly the same as yours.
Sent from my GT-p6800 using Tapatalk HD
Click to expand...
Click to collapse
You can try loading the UTF8 module without vermagic string as well, it should work on PAC. Or, make sure you have a blank space at the end of the vermagic string, it is required. Maybe read the short tutorial here: http://forum.xda-developers.com/showthread.php?p=41920265#post41920265
dfkt_ said:
You can try loading the UTF8 module without vermagic string as well, it should work on PAC. Or, make sure you have a blank space at the end of the vermagic string, it is required. Maybe read the short tutorial here: http://forum.xda-developers.com/showthread.php?p=41920265#post41920265
Click to expand...
Click to collapse
I finally managed to mount cifs shares, after loading original cifs and punmode load of nls_utf8.ko.
But I mounted it with cifsmanager. The script always shows "failure to mount" !