Related
This is hack for the userinit.sh script that allows to override
system programs with different binaries or just add some new
executable programs to your rom as you can use your ext3 partition
as storage. One more advantage is that your customizations
will be persistent even after a update.
For this to work you have to add this lines to your /system/sd/userinit.sh script:
Code:
mount -o remount,rw /dev/rootfs /
mkdir /usr
chown root.root /usr
chmod 755 /usr
mkdir /system/sd/bin
chown root.shell /system/sd/bin
chmod 755 /system/sd/bin
ln -s /system/sd/bin /usr/bin
mount -o remount,ro /dev/rootfs /
After a reboot, you'll find a newly created bin
directory in /system/sd/ linked to /usr/bin.
/usr/bin is the first directory to be searched
in path in CM-mod ROMs so any program dropped
there will be found and executed before others with
same name in the system. So you can simply:
Code:
adb push new_program /usr/bin
adb shell
cd /usr/bin
chmod 755 new_program
chown root.shell new_program
This is experimental stuff and therefore USE IT AT YOUR OWN RISK.
Tested on CM-mod-3.6.7.2 and CM-mod-3.6.8 and works fine for me.
So if I were to use this method. I could 'truely' replace the home screen with one of the 3rd party ones. ie aHome or dxTop? As it is now, I've noticed that even setting aHome as default, Home still runs in the background. Using Advanced Task Manager to confirm this btw.
If this is the case, I'll be using this shortly. As I'm tired of just running 3rd party programs in addition to the programs they are suppose to replace.
Its like using windowblinds in windows, instead of just replacing the whole shell. lol
followinginsanity said:
So if I were to use this method. I could 'truely' replace the home screen with one of the 3rd party ones. ie aHome or dxTop? As it is now, I've noticed that even setting aHome as default, Home still runs in the background. Using Advanced Task Manager to confirm this btw.
If this is the case, I'll be using this shortly. As I'm tired of just running 3rd party programs in addition to the programs they are suppose to replace.
Its like using windowblinds in windows, instead of just replacing the whole shell. lol
Click to expand...
Click to collapse
This only lets your run cli programs. This is below the dalvik system so it won't help you change the launcher.apk for ahome or dxtop.
Ok I see what your saying now. Misunderstood the exact intent of the changes
Cool trick, thanks. I already had a /system/sd/bin, so I modified it a little to skip creating it and doing the chmod etc on it.
Slight mod to avoid the whole thing if /usr is already there.. .
Code:
if ! [ -d /usr ]
then
mount -o remount,rw /dev/rootfs /;
mkdir /usr;
chown root.root /usr;
chmod 755 /usr;
ln -s /system/sd/bin /usr/bin;
mount -o remount,ro /dev/rootfs /;
fi
This is useful to me as my userinit.sh is the new one from the compcache thread and can be run to get status info on compcache after boot. No need to remount the filesystem and all that when what we need is already there.
I don't think you can skip the creation of /usr as it is lost
after a reboot at least on cm-mod, you can skip the creation
of system/sd/bin if it already exists tough. OTOH running:
Code:
mkdir /usr
chown root.root /usr
chmod 755 /usr
mkdir /system/sd/bin
chown root.shell /system/sd/bin
chmod 755 /system/sd/bin
ln -s /system/sd/bin /usr/bin
will do no harm as mkdir and ln will fail if the targets already exist
and chown and chmod will just ensure that you can run your
programs.To be on the safe side i would suggest:
Code:
mount -o remount,rw /dev/rootfs /
mkdir /usr
chown root.root /usr
chmod 755 /usr
# we should check if /system/sd is mounted
if [ ! -d /system/sd/bin ] ; then
mkdir /system/sd/bin
chown root.root /system/sd/bin
chmod 755 /system/sd/bin
fi
ln -s /system/sd/bin /usr/bin
mount -o remount,ro /dev/rootfs /
This would be a great place to put a set of the GNU utilities like ls, ln, cp, mv, etc to go along with bash. Busybox is great and all, but there are some advanced options in the GNU versions that aren't available in Busybox. Has anyone compiled them for Android? I might try copying the Debian ones over and see if they work without the rest of the chroot. I'm thinking I'll need at least some of /lib from debian for them to work though.
ttabbal said:
This would be a great place to put a set of the GNU utilities like ls, ln, cp, mv, etc to go along with bash. Busybox is great and all, but there are some advanced options in the GNU versions that aren't available in Busybox. Has anyone compiled them for Android? I might try copying the Debian ones over and see if they work without the rest of the chroot. I'm thinking I'll need at least some of /lib from debian for them to work though.
Click to expand...
Click to collapse
Have you tried a fully configured busybox with desktop options enabled?
Attached just for reference my .config.
farmatito said:
Have you tried a fully configured busybox with desktop options enabled?
Attached just for reference my .config.
Click to expand...
Click to collapse
Nope. Is there a binary available? I don't have a cross compiler set up right now.
Try this, You can create all the symlinks with this command:
Code:
adb push busybox /usr/bin
adb shell
cd /usr/bin
./busybox --install .
For full functionality you should also add /etc/passwd, /etc/shadow, /etc/group, /etc/gshadow. I link them to /system/sd/etc/ to have them rw
Code:
mkdir /system/sd/etc
chmod 644 /system/sd/etc
/system/bin/chown root.root /system/sd/etc
/system/bin/chown root.root /system/sd/etc/passwd
/system/bin/chown root.root /system/sd/etc/group
/system/bin/chown root.root /system/sd/etc/shadow
/system/bin/chown root.root /system/sd/etc/gshadow
/system/bin/chown root.root /system/sd/etc/fstab
chmod 644 /system/sd/etc/passwd
chmod 644 /system/sd/etc/group
chmod 600 /system/sd/etc/shadow
chmod 600 /system/sd/etc/gshadow
ln -s /system/sd/etc/passwd /etc/passwd
ln -s /system/sd/etc/shadow /etc/shadow
ln -s /system/sd/etc/group /etc/group
ln -s /system/sd/etc/gshadow /etc/gshadow
Remove the su link to busybox for now as it interferes with
the superuser app (otoh you could set a root passwd and
use busybox's su BUT ONLY FROM A SHELL)
Code:
rm /usr/bin/su
You should also:
Code:
passwd root
addgroup -g 65534 nogroup
You can even use ash as your default shell by doing:
Code:
if [ -e /usr/bin/busybox ] ; then
mount --bind /usr/bin/sh /system/bin/sh
fi
# Fix scripts in /system/bin
for i in am ime input monkey pm svc
do
if [ `grep -c "#!/system/bin/sh" /system/bin/$i` -eq 0 ] ; then
echo "#!/system/bin/sh" > /system/bin/$i.tmp
cat /system/bin/$i >> /system/bin/$i.tmp
mv /system/bin/$i.tmp /system/bin/$i
chown root.shell /system/bin/$i
chmod 755 /system/bin/$i
fi
done
Thanks! That worked great.
farmatito said:
Try this, You can create all the symlinks with this command:Remove the su link to busybox for now as it interferes with
the superuser app (otoh you could set a root passwd and
use busybox's su BUT ONLY FROM A SHELL)
Click to expand...
Click to collapse
Hey farmatito - just stumbled onto this thread and am going to follow this but I am unclear on how to remove the su link to busybox? Any direction would be appreciated! Thanks.
Edit: I realize you mean to just rm it from /system/sd/bin - duh. thanks for this thread! I like having the full busybox bin.
cd /usr/bin
rm su
farmatito said:
cd /usr/bin
rm su
Click to expand...
Click to collapse
Yeah, I figured that out - thanks. I had edited my above post saying such.
another question for you - I was going through your busybox config file - and am wondering which directory you store it in so that it is used when installing busybox?
prscott1 said:
Yeah, I figured that out - thanks. I had edited my above post saying such.
another question for you - I was going through your busybox config file - and am wondering which directory you store it in so that it is used when installing busybox?
Click to expand...
Click to collapse
Download the source code from www.busybox.net
extract it
cd busybox
cp my_config .config
make oldconfig
make
You need a cross compiler to build it
you can download one at
http://www.codesourcery.com/sgpp/lite/arm/portal/release830
or
http://www.codesourcery.com/sgpp/lite/arm/portal/release827
Quick stupid question please... tried searching but haven't found much.
After doing the userinit.sh mod shown here and using the new busybox (thanks for that, btw!), I noticed that a lot of the commands (including 'ls' which is now using /usr/bin/ls) show ansi colors in a terminal that supports them (i.e. 'Terminal' or 'Better Terminal' app) which is awesome but 'adb shell' looks mostly horrible with escape sequences instead of colors, like this:
Code:
# cd /system/sd
cd /system/sd
# ls -l
ls -l
drwxrwx--x 2 system system 2048 Aug 19 16:04 ←[1;34mapp←[0m
drwxrwx--x 2 system system 1024 Aug 16 02:12 ←[1;34mapp-private←[0m
drwxr-xr-x 2 root root 4096 Aug 19 20:40 ←[1;34mbin←[0m
drwxrwx--x 2 system system 7168 Aug 19 16:04 ←[1;34mdalvik-cache←[0m
drw-r--r-- 2 root root 1024 Aug 19 20:39 ←[1;34metc←[0m
drwxr-xr-x 2 root root 12288 Jul 10 02:29 ←[1;34mlost+found←[0m
drwxrwxrwx 2 root root 1024 Jul 22 18:15 ←[1;34mmedia←[0m
-rwxr-xr-x 1 root root 331 Aug 19 20:28 ←[1;32muserinit.sh←[0m
Do you guys set your $TERM variable to something that makes the adb terminal more "sane" or is not possible because adb is limited and I should just ssh or telnet in, etc.?
I've tried setting $TERM to various standard things (ansi/vt100/xterm/etc.) but the dumb adb terminal remains.. well.. dumb.
rub1k said:
Quick stupid question please... tried searching but haven't found much.
After doing the userinit.sh mod shown here and using the new busybox (thanks for that, btw!), I noticed that a lot of the commands (including 'ls' which is now using /usr/bin/ls) show ansi colors in a terminal that supports them (i.e. 'Terminal' or 'Better Terminal' app) which is awesome but 'adb shell' looks mostly horrible with escape sequences instead of colors, like this:
Code:
# cd /system/sd
cd /system/sd
# ls -l
ls -l
drwxrwx--x 2 system system 2048 Aug 19 16:04 ←[1;34mapp←[0m
drwxrwx--x 2 system system 1024 Aug 16 02:12 ←[1;34mapp-private←[0m
drwxr-xr-x 2 root root 4096 Aug 19 20:40 ←[1;34mbin←[0m
drwxrwx--x 2 system system 7168 Aug 19 16:04 ←[1;34mdalvik-cache←[0m
drw-r--r-- 2 root root 1024 Aug 19 20:39 ←[1;34metc←[0m
drwxr-xr-x 2 root root 12288 Jul 10 02:29 ←[1;34mlost+found←[0m
drwxrwxrwx 2 root root 1024 Jul 22 18:15 ←[1;34mmedia←[0m
-rwxr-xr-x 1 root root 331 Aug 19 20:28 ←[1;32muserinit.sh←[0m
Do you guys set your $TERM variable to something that makes the adb terminal more "sane" or is not possible because adb is limited and I should just ssh or telnet in, etc.?
I've tried setting $TERM to various standard things (ansi/vt100/xterm/etc.) but the dumb adb terminal remains.. well.. dumb.
Click to expand...
Click to collapse
What terminal are you using?
I use konsole on linux and everything looks fine.
Cannot say if there is a suitable terminal for windows,
maybe the one that comes with the mingw compiler.
If nothing works you can just:
Code:
cd /usr/bin
rm ls
farmatito said:
Download the source code from www.busybox.net
extract it
cd busybox
cp my_config .config
make oldconfig
make
You need a cross compiler to build it
you can download one at
http://www.codesourcery.com/sgpp/lite/arm/portal/release830
or
http://www.codesourcery.com/sgpp/lite/arm/portal/release827
Click to expand...
Click to collapse
Many thanks!
Oh, sorry, I should have specified that.
This was using adb from my Vista x64 laptop (yeah, sorry, stuck with win32 for using adb so terminal choices rather limited).
So, basically, it was just running "adb[.exe] shell" from a Windows command prompt.
Tried bash under cygwin and even though it has full ansi coloring support, it looks like adb.exe isn't very terminal friendly because extended/escaped ansi still don't translate.
No big deal; I'll remove /usr/bin/ls for now or temporarily alias 'ls' to /system/xbin/bb/ls while I'm in an adb shell.
Wondering what else I could be using via the USB connection to get a shell prompt within my G1... easiest way is to turn on the wifi and telnet/ssh in, I guess?
EDIT: Duh, just started telnetd and forwarded the port using adb and problem solved (using putty to telnet in as described here and it works very nicely).
rub1k said:
Quick stupid question please... tried searching but haven't found much.
After doing the userinit.sh mod shown here and using the new busybox (thanks for that, btw!), I noticed that a lot of the commands (including 'ls' which is now using /usr/bin/ls) show ansi colors in a terminal that supports them (i.e. 'Terminal' or 'Better Terminal' app) which is awesome but 'adb shell' looks mostly horrible with escape sequences instead of colors, like this:
Code:
# cd /system/sd
cd /system/sd
# ls -l
ls -l
drwxrwx--x 2 system system 2048 Aug 19 16:04 ←[1;34mapp←[0m
drwxrwx--x 2 system system 1024 Aug 16 02:12 ←[1;34mapp-private←[0m
drwxr-xr-x 2 root root 4096 Aug 19 20:40 ←[1;34mbin←[0m
drwxrwx--x 2 system system 7168 Aug 19 16:04 ←[1;34mdalvik-cache←[0m
drw-r--r-- 2 root root 1024 Aug 19 20:39 ←[1;34metc←[0m
drwxr-xr-x 2 root root 12288 Jul 10 02:29 ←[1;34mlost+found←[0m
drwxrwxrwx 2 root root 1024 Jul 22 18:15 ←[1;34mmedia←[0m
-rwxr-xr-x 1 root root 331 Aug 19 20:28 ←[1;32muserinit.sh←[0m
Do you guys set your $TERM variable to something that makes the adb terminal more "sane" or is not possible because adb is limited and I should just ssh or telnet in, etc.?
I've tried setting $TERM to various standard things (ansi/vt100/xterm/etc.) but the dumb adb terminal remains.. well.. dumb.
Click to expand...
Click to collapse
If you are on a windows pc, try using cygwin - works great.
hi,
after latest upgrade (htc desire, open desire 2.3, busybox, app2sd), i have issues with the access to the file system on /system (via terminal emulator from the phone).
all works fine using adb, but when i try to delete or copy a file to /system (directly on phone), i have a error.
i have searched over inet, but i don't find :/
i attach a example below
Code:
# mount -o rw,remount /dev/block/mtdblock3 /system
# cd /system/etc/test
# ls
-rw-rw-rw root root 124 ul 22 13:54 test1
-rw-rw-rw root root 124 ul 22 13:54 test2
# rm test1
error deleting test1: directory not empty
# ls
-rw-rw-rw root root 124 ul 22 13:54 test2
# ls test1
test1
edit:
i have the same issue when i connect to my phone using adb (and the phone started, not in recovery mode)..
Code:
# mount -o rw,remount /dev/block/mtdblock3 /system
# cd /system/app
# cp -f /sdcard/install/nosense/system/app/Terminal.apk .
cp: can't create './Terminal.apk': Out of memory
# cp -f /sdcard/install/nosense/system/app/Terminal.apk .
cp: can't create './Terminal.apk': Out of memory
# cd /system/app
# cp -f /sdcard/install/nosense/system/app/Terminal.apk .
cp: can't create './Terminal.apk': Out of memory
# cd /system/app
# cp -f /sdcard/install/nosense/system/app/Terminal.apk .
cp: can't create './Terminal.apk': Out of memory
Hi there... are you new to the desire?
As far as I can remember, writing to /system/ outside of ADB in Recovery is not possible on the Desire - an unfortunate limitation of the current root methods which hasn't been circumvented yet.
oh! thx!
i have received my desire a few days ago.
my old phone was a nexus.
i agree! and sorry for the inconvenience
What inconvenience?
I was a little confused too when I started reading about root on the Desire, and the info is hard to find (buried in one [or a few] of the many root tutorials)...
The really interesting part, IMO, is whether this limitation causes any problems with root-apps. But there don't seem to be any other than Adfree, and there seem to be patched versions that work with the Desire now (IIRC by moving the Hosts file out of /system/ and symlinking to it)
Hello,
I have a Samsung Captivate running the I9000XWJM2 Firmware on the stock kernel with Samset 1.7 ROM installed. Rooted with busybox. I've noticed that intermittently my ADB Shell will just quit. I was tinkering with the userinit.sh hack to a2sd my phone when it stopped giving me any output. Is this a known issue and is there a repair action other than reflashing the phone?
Here is an example:
C:\Program Files (x86)\Android-SDK\tools>adb shell
$ su
su
# ls
ls
# pwd
pwd
/
# busybox --help
busybox --help
# cd /system
cd /system
# pwd
pwd
/system
# ls
ls
# ls -al
ls -al
# mount
mount
# busybox mount
busybox mount
Click to expand...
Click to collapse
Any guidance would be greatly appreciated. I really don't want to rebuild my phone again.
My root had somehow broken. Re-applying the root update.zip seems to have repaired the issue.
[originally posted in galaxy tab 1 forum by mistake...]
I used clockworkmod recovery and the cwm-root-gtab2.zip package to root my Tab 2. su appears to be installed ok, and I can get root permissions by running it from an adb shell:
~ $ adb shell
[email protected]:/ $ id
uid=2000(shell) gid=2000(shell) groups=1003(graphics),1004(input),1007(log),1009(m ount),1011(adb),1015(sdcard_rw),1028(sdcard_r),300 1(net_bt_admin),3002(net_bt),3003(inet),3006(net_b w_stats)
[email protected]:/ $ su
[email protected]:/ # id
uid=0(root) gid=0(root) groups=1003(graphics),1004(input),1007(log),1009(m ount),1011(adb),1015(sdcard_rw),1028(sdcard_r),300 1(net_bt_admin),3002(net_bt),3003(inet),3006(net_b w_stats)
[email protected]:/ # ls -la /system/bin/su
-rwsr-sr-x root shell 22364 2008-08-01 12:00 su
[email protected]:/ #
So the su binary is present and has setuid bit set on its permissions. But if I run it from a SSH session, or via a terminal emulator on the Tab itself, I get permission error:
[email protected]:/ $ su
Permission denied
1|[email protected]:/ $
Various root checking apps report similar problems. What am I doing wrong? Other threads suggest steps to recreate the su binary with the correct 6755 permissions, but as far as I can see, everything is already as it should be permissions-wise.
Thanks.
First off ran in to the same problem as you I could not get that root to work through cwm method so i did some more research and found my answers here http://androidjinn.com/how-to-root-galaxy-tab-2-p3113-on-ueclk7-android-4-1-1-firmware.html assuming that you are on the gtp3113 model and on stock jb like i am and not looking to flash other roms lol i havent been able to find a way to load cwm without loosing my root again
aj9507 said:
First off ran in to the same problem as you I could not get that root to work through cwm method so i did some more research and found my answers here xxxxxxx assuming that you are on the gtp3113 model and on stock jb like i am and not looking to flash other roms lol i havent been able to find a way to load cwm without loosing my root again
Click to expand...
Click to collapse
Thanks, but unfortunately my model is P3110.
Hi,
I'm having an issue with all terminal emulators (Android Terminal Emulator, ConnectBot, ...) after upgrading my Nexus 10 from Android 4.2.2 to 4.3.
The terminal is not recognizing the actual size of the screen and it is fixed to 80 columns and 20 rows. I can temporarily fix it typing "stty cols 180 rows 35", but those values depend on the screen rotation, font size, etc.
This is really weird, and I wasn't having this issue before the upgrade.
Anyone else has this problem or know how to solve it?
Thanks!
Ok, i've been doing some tests.
It seems to be a 'su' bug, it is not receiving the SIGWINCH signal.
If I type without su:
trap 'echo sigwinch' SIGWINCH
It is executed every time I rotate the tablet or popup the keyboard.
But, under su, the same command is not working.
It may be a permission issue.
Any ideas?
I can confirm having the same issue with my Nexus 10 and android 4.3. As soon as I run su - from the terminal (Android Terminal Emulator) the lines start wrapping at 80 characters.
Hi,
i've been working on this trying to find a solution.
Here is what I saw:
Every time I enter su or enter chroot (i have a chrooted debian), the tty number is changed to another one. That isn't the usual tty behavior!
So, if the normal user is in /dev/pts/0 , root could be in /dev/pts/1 and chroot in /dev/pts/2.
If I rotate the screen /dev/pts/0 cols and rows are changed even if I am as root, I can verify that by typing:
stty -F /dev/pts/0 -a
But, if I am at /dev/pts/1 i'm not receiving that SIGWINCH signal. In common linux distributions, that is not happening as pts number doesn't change.
Here is my (not so perfect) solution for the chrooted debian:
Write a fix_stty.sh script as root:
#!/bin/bash
sttypath=/bin
tty0=$(ls --sort time /dev/pts/ | head -n 1 | awk '{print $1}')
stty0=$($sttypath/stty -F /dev/pts/$tty0 -a | head -n1)
rows=$(echo $stty0 | sed -e 's:.*rows\ \([0-9]\+\).*:\1:g')
cols=$(echo $stty0 | sed -e 's:.*columns\ \([0-9]\+\).*:\1:g')
$sttypath/stty rows $rows cols $cols
Save it in /usr/local/bin
Make it executable:
chmod +rx /usr/local/bin/fix_stty.sh
Add to ~/.bashrc this line:
trap '/usr/local/bin/fix_stty.sh' DEBUG
Or if you use non-root users:
trap 'sudo /usr/local/bin/fix_stty.sh' DEBUG
And add to sudoers file:
%sudo ALL = (ALL) NOPASSWD: /usr/local/bin/fix_stty.sh
Logout and login again, and it will fix the rows and columns before each command.
----
For su, outside the chrooted linux write a script fix_stty.sh:
sttypath=/system/xbin
tty0=$(/system/xbin/busybox ls -t /dev/pts | head -n1)
stty0=$($sttypath/stty -F /dev/pts/$tty0 -a | head -n1)
rows=$(echo $stty0 | sed -e 's:.*rows\ \([0-9]\+\).*:\1:g')
cols=$(echo $stty0 | sed -e 's:.*columns\ \([0-9]\+\).*:\1:g')
$sttypath/stty rows $rows cols $cols
Save it to /system/xbin
(You should remount /system as rw: mount --remount -orw /system)
Then, make it exec:
chmod 755 /system/xbin/fix_stty.sh
And, finally you should type at each su login:
trap '/system/xbin/fin_stty.sh' SIGINT
(i don't know why DEBUG isn't here)
So you have to press Ctrl+C to fix it.
----
Alternatively, you can write an infinite loop or a simple daemon to fix it, but i don't like daemons on my tablet.
If anyone has a better solutions, please post it.
Hi all. I've been mulling over this problem as well. I believe the issue is because in 4.3, SuperSU now uses a "proxy", where commands are sent form the process which called su to daemonsu, which is launched at system startup. Chainfire explains a bit more in his G+ posts the reasons for doing this, but I think the key here is that root processes are now launched on a different tty, because they are launched by a different process (namely, daemonsu). Starting a root shell (whether system shell or ubuntu/debian chroot) now results in the creation of three pts devices, as opposed to the usual one. However, other shells not launched locally are fine. For example, starting the SSH server in my chroot and logging in via SSH is always fine.
I'm still trying to figure out a permanent solution to this problem. I still don't have a full understanding of the problem as I'm still trying to wrap my head around how Linux handles terminals and TTYs. I do have a few ideas floating around my head, though:
Change daemonsu and su to support full termios/line-discipline/whatever-we-need through the "pts bridge" that he is using
Create TTY(pts) pairs on demand, and have a modified Terminal Emulator connect to those directly when we want a shell
Have a background-ed process in the original terminal catch SIGWINCH and pass it to the root terminal
Still quite a bit a figure out though. I may just go through Terminal Emulator's source code to see how it work to get a better picture too. But that's gonna take time. I've also created a little native utility which creates two pts pseudo-TTYs and shuffles data between them. I'm still experimenting. Will post more as I learn more.
Just to let you all know that I've got a system working for myself: http://blog.tan-ce.com/android-root-shell/
The way I'm doing it uses a daemon, much like the su daemons ChainFire and Koush are using. The benefit of doing it this way is that I'm not confined by the application container, which is good for security when used by applications, but is annoying when you are using the terminal itself. I remember having to do hacks with adb servers to get around those.
But if you don't want a daemon, you can still set one up manually, just look at the last section of the README on how to use pts-wrap and pts-exec.
I gave this a try.
First, I've noticed that pts-wrap and pts-exec symbolic links were missing.
And I don't think the line '/system/etc/install-recovery-2.sh' in pts-daemon-start file is needed at all.
I'm using ChainFire SuperSU and pts-shell is not working as expected or catching SIGWINCH signals. I just don't see any difference with the standard shell. Maybe I misunderstood how it works.
alf_tux said:
I gave this a try.
First, I've noticed that pts-wrap and pts-exec symbolic links were missing.
And I don't think the line '/system/etc/install-recovery-2.sh' in pts-daemon-start file is needed at all.
Click to expand...
Click to collapse
My mistake, I forgot to create the symlinks for those two.
install-recovery-2.sh is an idea I took from CharinFire's SuperSU. Basically, it seems as if people are using install-recovery.sh to install startup scripts, and having the script try to call install-recovery-2.sh allows you to chain recovery scripts. For example, if you install this on a system with SuperSU, it will be installed as install-recovery-2.sh. If the system doesn't already have an install-recovery.sh, it'll install itself as install-recovery.sh.
Anyway, I've fixed and uploaded a new zip.
alf_tux said:
I'm using ChainFire SuperSU and pts-shell is not working as expected or catching SIGWINCH signals. I just don't see any difference with the standard shell. Maybe I misunderstood how it works.
Click to expand...
Click to collapse
Are you running pts-shell from a regular (non-root) shell, or from a root shell? It should be run from a non-root shell. (It will give you a root shell once it runs.) Only pts-passwd and pts-daemon is meant to be run as root.
tan-ce said:
Are you running pts-shell from a regular (non-root) shell, or from a root shell? It should be run from a non-root shell. (It will give you a root shell once it runs.) Only pts-passwd and pts-daemon is meant to be run as root.
Click to expand...
Click to collapse
Yes, here is my the terminal output:
[email protected]:/ $ ps | grep pts
root 136 1 760 180 ffffffff 00000000 S /system/xbin/pts-daemon
[email protected]:/ $ pts-shell /system/bin/sh
(pts-shell) /system/bin/sh
Could not connect to socket: Permission denied
255|[email protected]:/ $ su pts-shell /system/bin/sh
[email protected]:/ #
As you see, I can only run pts-shell as root.
alf_tux said:
Yes, here is my the terminal output:
[email protected]:/ $ ps | grep pts
root 136 1 760 180 ffffffff 00000000 S /system/xbin/pts-daemon
[email protected]:/ $ pts-shell /system/bin/sh
(pts-shell) /system/bin/sh
Could not connect to socket: Permission denied
255|[email protected]:/ $ su pts-shell /system/bin/sh
[email protected]:/ #
As you see, I can only run pts-shell as root.
Click to expand...
Click to collapse
Sorry, I realized that the correct command should be:
[email protected]:/ $ su -c pts-shell /system/bin/sh
(pts-shell) /system/bin/sh
(pts-shell) Enter your password:
[email protected]:/ #
Anyway I can only run this as root.
Oh yeah, I found the bug. Sorry, my bad. I've fixed it and uploaded a new copy of the update ZIP, but you don't have to upgrade if you don't want to. Running
Code:
# chmod 0701 /data/pts
should be sufficient to fix the problem. Then you should be able to run pts-shell from a regular (non-root) shell.
tan-ce said:
Oh yeah, I found the bug. Sorry, my bad. I've fixed it and uploaded a new copy of the update ZIP, but you don't have to upgrade if you don't want to. Running
Code:
# chmod 0701 /data/pts
should be sufficient to fix the problem. Then you should be able to run pts-shell from a regular (non-root) shell.
Click to expand...
Click to collapse
I don't think that was the the bug:
[email protected]:/ $ su
[email protected]:/ # ls -l /data/pts
-rw------- root root 61 2013-08-28 19:09 passwd
srw-rw-rw- root root 2013-08-28 18:59 pts
[email protected]:/ # chmod 0701 /data/pts
[email protected]:/ # ls -l /data/pts
-rw------- root root 61 2013-08-28 19:09 passwd
srw-rw-rw- root root 2013-08-28 18:59 pts
[email protected]:/ # ^D
[email protected]:/ $ pts-shell /system/bin/sh
(pts-shell) /system/bin/sh
Could not connect to socket: Connection refused
255|[email protected]:/ $
I have also tried:
chmod 0701 /data/pts/pts
And
chmod 0701 /data/pts/*
I'm getting the same connection refused. Maybe you can send me a debug version, I can run it just to find what is going on.
alf_tux said:
I'm getting the same connection refused. Maybe you can send me a debug version, I can run it just to find what is going on.
Click to expand...
Click to collapse
That's strange. Could you show me the output of ls -la? (The "a" is needed to see the permissions for /data and /data/pts itself)
After that, perhaps you could try "chmod 0711 /data/pts"
There isn't a debug version. The error message comes from the part of the code which tries to open a unix socket located at /data/pts/pts. For this to work, /data and /data/pts must have the execute bit set, and /data/pts/pts needs to have the readable and writable bit set for you. Otherwise you'll get a "permission denied".
Perhaps it might be easier for me to just move the socket to /dev like what koush does for Superuser... it's possible the permissions on my /data is non-standard.
On a side note, I'm also currently trying to contribute to koush's Superuser project to fix terminal handling. With any luck, I (or someone else?) will succeed and we won't really need my pts-multi tools anymore.
tan-ce said:
That's strange. Could you show me the output of ls -la? (The "a" is needed to see the permissions for /data and /data/pts itself)
After that, perhaps you could try "chmod 0711 /data/pts"
There isn't a debug version. The error message comes from the part of the code which tries to open a unix socket located at /data/pts/pts. For this to work, /data and /data/pts must have the execute bit set, and /data/pts/pts needs to have the readable and writable bit set for you. Otherwise you'll get a "permission denied".
Perhaps it might be easier for me to just move the socket to /dev like what koush does for Superuser... it's possible the permissions on my /data is non-standard.
On a side note, I'm also currently trying to contribute to koush's Superuser project to fix terminal handling. With any luck, I (or someone else?) will succeed and we won't really need my pts-multi tools anymore.
Click to expand...
Click to collapse
Yes, I agree that fixing su would be better.
I don't have my tablet right know, i don't remember well /data /data/pts and /data/pts/pts read and exec bits. I will see better whan I have my tablet with me.
Here is the output:
/data:
drwxrwx--x system system 2013-08-28 18:59 data
/data/pts:
drwxr-xr-x root root 2013-08-28 19:06 pts
[email protected]:/ $ ls -la /data/pts
-rwxrwxrwx root root 61 2013-08-28 19:09 passwd
srwxrwxrwx root root 2013-08-28 18:59 pts
[email protected]:/ $ pts-shell /system/bin/sh
(pts-shell) /system/bin/sh
Could not connect to socket: Connection refused
255|[email protected]:/ $
I suppose it isn't a permission problem.
alf_tux said:
I suppose it isn't a permission problem.
Click to expand...
Click to collapse
You're probably right, my Nexus 10 could be a bit different because of the semi-botched update I went through. Well, good news on two fronts: First, I updated pts-multi (latest update zip here) to use /dev/pts-daemon as the socket instead of /data... It works on mine, and I think it should work on yours, because Superuser puts its socket there too.
Second, I finished some modifications to the su binary in Superuser (source code here), and I've submitted a pull request to Koush. He says he'll do a code review of my changes, and we'll see how it goes.
tan-ce said:
You're probably right, my Nexus 10 could be a bit different because of the semi-botched update I went through. Well, good news on two fronts: First, I updated pts-multi (latest update zip here) to use /dev/pts-daemon as the socket instead of /data... It works on mine, and I think it should work on yours, because Superuser puts its socket there too.
Second, I finished some modifications to the su binary in Superuser (source code here), and I've submitted a pull request to Koush. He says he'll do a code review of my changes, and we'll see how it goes.
Click to expand...
Click to collapse
T/hanks! I tried your new update and I think it's working!
Can you add a passwordless option? Or if password is blank just don't ask for it
alf_tux said:
T/hanks! I tried your new update and I think it's working!
Can you add a passwordless option? Or if password is blank just don't ask for it
Click to expand...
Click to collapse
Ok, but I took the easiest way out... If you set the environment variable PTS_AUTH, pts-shell will read the password from there instead of prompting you for it. So, if you're writing a script to spawn a root shell, do:
Code:
#!/system/bin/sh
export PTS_AUTH="your password here"
pts-shell /system/bin/sh
The latest update zip is here.
Thanks a lot tan-ce!!
It's working just as I expected!
Glad to hear it.