I am having a hard time getting certain interactive features of any shell to work with Android Terminal Emulator as soon i acquire superuser privileges by issuing the "su" command. I am no longer able to cycle through the command history which is otherwise done by pressing the volume down key (provided you have the vol. down key bound to the Ctrl key via Terminal Emulator's settings) and then the p key. It will simply display the "^P" control sequence instead of displaying the last entered command. It only becomes an issue once the su command is entered. Does anyone know of any possible workarounds?
bsimpson1 said:
I am having a hard time getting certain interactive features of any shell to work with Android Terminal Emulator as soon i acquire superuser privileges by issuing the "su" command. I am no longer able to cycle through the command history which is otherwise done by pressing the volume down key (provided you have the vol. down key bound to the Ctrl key via Terminal Emulator's settings) and then the p key. It will simply display the "^P" control sequence instead of displaying the last entered command. It only becomes an issue once the su command is entered. Does anyone know of any possible workarounds?
Click to expand...
Click to collapse
Quick answer: install Chainfire's SuperSU and don't look back
Just saw this post searching for some terminal stuff and had to reply cause this was driving me crazy trying to figure it out / fix it. The issue is with the CWM su binary. I never could exactly figure out the exact problem, and I wasn't willing to grep through its source code. I know that the permissions weren't (still might not be) configured correctly at installation. /system/xbin/su should be -srwx 06755 and Owner:Group 0:0 aka root:root at installation but the -s--- 06000 sticky-bit should not persist after installation and remounting /system, i.e., /system/xbin/su should be -rwx 0755 in the AOS. CWM's su has been re-chmod'ing the user-specific sticky-bit when I try changing it.. I'm pretty sure this is at least part of the problem with console/shell/terminal output not being (re)directed correctly with CWM-su executed processes.
Another thing to mention is the "security context" (SELinux additional file permissions) which labels the file with an "object" and "role" among other things. I know that it's set correctly during installation with SuperSU, but I didn't see a command for it in the installation zip's script for CWM-su NOV-17-beta. I'm never really sure what's going on with CWM's giant su binary these days lol This is a pretty important permission setting not to forget, especially if you're running enforced SELinux which is Android 4.4's SELinux' default security. Note: SELinux denies unconfigured files by default, and otherwise configured only allows minimum access to function when called. It then makes sense that if su doesn't have the correct security context, then it's children, shell executions might not either.
So I'm pretty sure the shortcuts (ctrl + c,x,z; esc + ...) stopped functioning correctly as a results of one or both of these issues. I checked almost all the suspects like libncurses.so (cursor library), libjackpal*[2-4].so (term library for execution of scripts), other terminals (same results in: better terminal emulator, connectbot, connectbot VX, Script Manager, JuiceSSH, Server Auditor, and a fresh Terminal IDE installation - could just take over the system with this beast if I had time). The ONLY place CWM su'd cursor works is recovery, flashing AromaFM. There's no SELinux here in this bootstrapped utopia of simplicity.
Chainfire's SuperSU recovery-installation-zip does all of the above mentioned correctly, so the cursor works everywhere(includes su binary and Superuser, and it yields complete removal of CWM's superuser files), the security context that's set to su, deamonsu, *all files that are added or modified* during installation is ubject_r:system_file:s0 via
Code:
chcon u:object_r:system_file:s0 file
. Also you can check SELinux security context with id -Z or maybe ls -Z, depends on those binaries and whether called by busybox, etc..
edit: CWM's su actually isn't used in TWRP; a supersu package is used
7175 said:
Quick answer: install Chainfire's SuperSU and don't look back
Just saw this post searching for some terminal stuff and had to reply cause this was driving me crazy trying to figure it out / fix it. The issue is with the CWM su binary. I never could exactly figure out the exact problem, and I wasn't willing to grep through its source code. I know that the permissions weren't (still might not be) configured correctly at installation. /system/xbin/su should be -srwx 06755 and Owner:Group 0:0 aka root:root at installation but the -s--- 06000 sticky-bit should not persist after installation and remounting /system, i.e., /system/xbin/su should be -rwx 0755 in the AOS. CWM's su has been re-chmod'ing the user-specific sticky-bit when I try changing it.. I'm pretty sure this is at least part of the problem with console/shell/terminal output not being (re)directed correctly with CWM-su executed processes.
Another thing to mention is the "security context" (SELinux additional file permissions) which labels the file with an "object" and "role" among other things. I know that it's set correctly during installation with SuperSU, but I didn't see a command for it in the installation zip's script for CWM-su NOV-17-beta. I'm never really sure what's going on with CWM's giant su binary these days lol This is a pretty important permission setting not to forget, especially if you're running enforced SELinux which is Android 4.4's SELinux' default security. Note: SELinux denies unconfigured files by default, and otherwise configured only allows minimum access to function when called. It then makes sense that if su doesn't have the correct security context, then it's children, shell executions might not either.
So I'm pretty sure the shortcuts (ctrl + c,x,z; esc + ...) stopped functioning correctly as a results of one or both of these issues. I checked almost all the suspects like libncurses.so (cursor library), libjackpal*[2-4].so (term library for execution of scripts), other terminals (same results in: better terminal emulator, connectbot, connectbot VX, Script Manager, JuiceSSH, Server Auditor, and a fresh Terminal IDE installation - could just take over the system with this beast if I had time). The ONLY place CWM su'd cursor works is recovery, flashing AromaFM. There's no SELinux here in this bootstrapped utopia of simplicity.
Chainfire's SuperSU recovery-installation-zip does all of the above mentioned correctly, so the cursor works everywhere(includes su binary and Superuser, and it yields complete removal of CWM's superuser files), the security context that's set to su, deamonsu, *all files that are added or modified* during installation is ubject_r:system_file:s0 via
Code:
chcon u:object_r:system_file:s0 file
. Also you can check SELinux security context with id -Z or maybe ls -Z, depends on those binaries and whether called by busybox, etc..
Click to expand...
Click to collapse
Thanks for such a detailed reply. It's nice to know that the problem wasn't on my end. I can finally stop desperately editing my bashrc file, adding all sorts of obscure environment variables and crossing my fingers.
bsimpson1 said:
Thanks for such a detailed reply. It's nice to know that the problem wasn't on my end. I can finally stop desperately editing my bashrc file, adding all sorts of obscure environment variables and crossing my fingers.
Click to expand...
Click to collapse
Man I'm right there with you. lol yeah my 1MB of cursor-fix bashrc and mksh edits are now resting in peace, blasted that tar.gz coffin out to space with my "working-key-signal" su'd ssh terminal the other day like Spock in The Wrath of Khan, oh yeah. I'm glad to know I wasn't the only person who cared about this so much.
Related
Mod Edit: Unstickied, placed link in wiki:http://forum.xda-developers.com/wiki/index.php?title=Nexus_One Thanks
This is an alternative approach of rooting the Nexus without touching the bootloader.
-no downgrade neccessary
-no battery modification neccessary
-no messing around with SD card slot
-you don't even have to open your phone...
Working and confirmed for ALL ROMs, including European Vodafone EPF30/FRF91, Korean FRF91, AT&T/T-Mo Stock including FRF91
-------
Credits:
-------
- The Android Exploid Crew:
http://c-skills.blogspot.com/2010/07/android-trickery.html
- Amon_RA
- cyanogen
-------
Notes:
-------
- The exploit wasn't found by me (see credits), I just implemented it as a proof of concept for the Nexus One
- Basically this method should work on all currently known ROM versions.
- I tested it on EPF30, Korean FRF91, Vodafone FRF91, US Stock FRF91.
- As usual when doing this kind of stuff: DO THIS AT YOUR OWN RISK.
- It could even work on other Android devices as long as their system partition is at
/dev/block/mtdblock3/ with yaffs2 file system and there is still some space left on the system partition (without any changes).
-------
Prerequisites:
-------
- Locked Nexus One
- Latest Android SDK incl. USB drivers
- Working ADB
- The file "freenexus.zip"
edit:
get it here:
http://multiupload.com/MVT98F5HBY
or
http://dl.dropbox.com/u/1327667/freenexus.zip
MD5: 947C20222056D7C070733E7FCF85CF15
-------
Step-by-step guide:
-------
1. install android sdk & USB drivers
2. extract the content of the zip file into the tools directory of SDK (i.e. \android-sdk-windows\tools)
-> For all Newbies: Take care that you extract the files directly to the tools folder and don't create a new subdirectory freenexus within tools!!! If you did, delete the folder and extract again!!! Check twice that there is no FOLDER freenexus in your tools directory before you continue!!!
3. open a command prompt (Windows: Start, Run, "cmd", OK; Linux: Terminal)
4. change to SDK tools directory (i.e. cd \android-sdk-windows\tools)
5. connect Nexus to USB and check if debugging mode is activated
(Settings/Application/Development/USB Debugging)
6. run "adb devices" in shell and see if there is a device listed. if not back to step 5 or reinstall USB-drivers
7a. for Windows: run "freenexus.bat" in command shell (this copies the neccessary files to /data/local/tmp)
7b. for Linux or manual installation: run the following commands
Code:
adb push freenexus /data/local/tmp/freenexus
adb push Superuser.apk /data/local/tmp/Superuser.apk
adb push su /data/local/tmp/su
adb push busybox /data/local/tmp/busybox
adb shell chmod 755 /data/local/tmp/freenexus
adb shell chmod 755 /data/local/tmp/busybox
8. run the following commands:
Code:
adb shell
(you should see a "$" prompt now)
cd /data/local/tmp
9. on your phone go to a screen where you can easily toggle wifi (widget or settings/wireless)
10. be prepared to toggle wifi immediately after you execute the next step
11. run
Code:
./freenexus
12. toggle wifi on
13. you should see something like that:
[*] Android local root exploid (C) The Android Exploid Crew
[*] Modified by ak for HTC Nexus One
[+] Using basedir=/sqlite_stmt_journals, path=/data/local/tmp/freenexus
[+] opening NETLINK_KOBJECT_UEVENT socket
[+] sending add message ...
[*] Try to invoke hotplug now, clicking at the wireless
[*] settings, plugin USB key etc.
[*] You succeeded if you find /system/bin/rootshell.
[*] GUI might hang/restart meanwhile so be patient.
13b) if you get "permission denied" error, you have most likely not followed the big red newbie hint after point 2. check this by entering "ls -l", if you see a "drwxr-xr-x" and not "-rwxr-xr-x" in front of the line where freenexus is listed you did not follow properly. Search the posts in the thread on how to correct this.
14. run
Code:
rootshell
15. if you succeeded you will be asked for a password, if not try again from step 10
16. enter the password "freenexus"
17. now you should see a "#" as a prompt -> you are root now
18. run the following commands:
Code:
./busybox cp busybox /system/bin
chmod 4755 /system/bin/busybox
busybox cp Superuser.apk /system/app
busybox cp su /system/bin
chmod 4755 /system/bin/su
rm /system/bin/rootshell
exit
exit
19. Check if you keep root rights:
Code:
adb shell
su
20. after you executed the su command the Superuser app on your device should ask you for allowance
21. you should see the "#" prompt again, if you didn't get that try su again
22. done
-------
Comments:
-------
- General
If you are not planning to wipe your data partition (what you probably will do when installing CM6 first time) you should think about deleting all the temp files still lying in /data/local/tmp (for safety reasons and to have more space on /data):
Code:
adb shell
cd /data/local/tmp
rm busybox
rm su
rm Superuser.apk
rm freenexus
rm flash_image (will only exist if you executed the steps below in recovery section)
- Installation of Custom Recovery
If you only want root rights you are done here. If you want to install custom ROMs you have to install
a custom recovery first. Easiest way would be to download "ROM Manager" from the market. There are plenty of tutorials on how to install custom recovery/ROM at xda.
Edit: It is safer to install the recovery manually. In this case or for those of you running into problems with installing custom recovery with ROM Manager (doesn't stick) you can continue with
these steps (without remount of system partition, now tested successfully):
1) Download recovery-RA-nexus-v1.7.0.1.img to the root directory of your SD-Card
- Note: UnMount your SD-Card after copying these files, but keep your phone plugged in
- or don't mount SD-Card at all and push the file via adb to /sdcard
2) Save file "flash_image" to sdk tools directory:
3) In your terminal run
Code:
adb push flash_image /data/local/tmp/flash_image
adb shell
su
- At this point, it will hang until you choose "Allow" on your phone with the SuperUser app pop-up
- $ should now be replaced with #
5) run the following commands:
Code:
[COLOR="Red"]mount -o rw,remount /dev/block/mtdblock3 /system[/COLOR]
cd /data/local/tmp
chmod 755 flash_image
[COLOR="Red"]./flash_image recovery /sdcard/recovery-RA-nexus-v1.7.0.1.img[/COLOR]
rm /system/etc/install-recovery.sh
rm /system/recovery-from-boot.p
(and if everything worked fine:)
rm flash_image
Alternatively you can continue with step 9 and then steps 16-24 from the old rooting method tutorial
to manually install Amon_RA's recovery. You will also need the file flash_image for that (link taken from HBOOT thread).
- HBOOT
If you rooted from a Korean Rom or have installed the latest Vodafone Rom via PASSIMG you probably have
HBOOT 0.35 which makes it currently difficult to install Cyanogenmod (there is an assertion failure in the install script, at least with CM6 RC1/2. Maybe future versions of CM6 will include HBOOT 0.35 in the script) or other custom ROMs. (You are still on 0.33 if you just installed the Vodafone OTA Update)
There is a tutorial to revert HBOOT here:
http://forum.xda-developers.com/showthread.php?t=726258
Instead of using the EPF30 image you can also use any other PASSIMG file (at least if it has HBOOT 0.33,
otherwise this step wouldn't make sense...)
Note that when flashing a PASSIMG with a different HBOOT version there is a reboot after the HBOOT has been flashed, then after reboot the PASSIMG will be loaded again and the rest of the image will be flashed.
To check HBOOT and Radio version: press and hold trackball while turning on the phone. To exit select Reboot with Vol+/- and press Power button.
Caution:
After you have reverted your HBOOT, you have lost your root rights and you are back on stock recovery.
But you can (or have to) repeat the above procedure to get root rights back.
Edit:
The downgrading also downgrades your radio!!! Before installing CM6 you have to flash a Froyo Radio!
Latest one can be found here:
http://forum.xda-developers.com/showthread.php?t=723839
-------
Troubleshooting:
-------
After trying to flash a custom ROM with ROM Manager one user wasn't able to boot the phone normally and also no longer able to boot to recovery. In this rare case try to download a compatible PASSIMG file:
For example EPF30 (Europe Vodafone 2.1)
http://shipped-roms.com/shipped/Pas...ogle_WWE_1.14.1700.1_EPF30_release_signed.zip
or FRF91 (Europe Vodafone 2.2):
http://shipped-roms.com/shipped/Pas...on_VF_2.15.151.5_R_FRF91_MFG_Shipment_ROM.zip (<-this one is currently a zip in zip. You have to extract it once to get the working PASSIMG.zip)
(Appropriate US-PASSIMGs can also be found on shipped-roms.com, most likely EPE76)
Rename the file to PASSIMG.zip (case sensitive, Windows users take care that the file isn't called PASSIMG.zip.zip hidden extension)
Copy it to main folder of SD card.
Boot phone into Bootloader mode (press and hold trackball when turning on the phone, until fastboot mode starts)
Select Bootloader mode by pressing power button.
The bootloader should then start to analyse the PASSIMG.zip and ask you afterwards to install it.
You're phone (not your SD) will be completely wiped after the procedure but should work again (and can be rooted again...)
sweet!! been waiting for this! will try it tomorrow as soon as i wake up! will report back then!
edit: i cant download freenexus.zip maybe use another hoster?
file section edited.
Great tutorial ! Waiting for some feedbacks
(file link doesn't work)
dolomiti7 said:
file section edited.
Click to expand...
Click to collapse
On the left I can see just an empty folder named "SmartDrive"
link doesn't work
dolomiti7 said:
-> after clicking on "Smartdrive Gastzugang starten" you might get an error message, but after klicking ok on the error message
you should be able to access the folder "nexus" on the left side of the window anyway
Click to expand...
Click to collapse
No way! Can't do anything even after i press ok on the error message
if you click on that there should be a subfolder "nexus" that should be clickable too. at least it works here... anyway. someone wants to upload the file to a hoster? rapidshare... contact me
for the early adaptors (will only work 10 times):
rapidshare.com/files/409266634/freenexus.zip
MD5: 947C20222056D7C070733E7FCF85CF15
multiple download sites!:
http://www.multiupload.com/MVT98F5HBY
or here:
http://dl.dropbox.com/u/1327667/freenexus.zip
thank you. added the link.
This worked flawlessly.
Massive thanks.
Hi, I have a Italian Vodafone Nexus One with FRF91, i have followed all the steps and now in my apps there is Superuser Permission with green light. It means that i have root rights? Can I install Cyanogen Mod now? Thanks, excuse my English.
Worked perfectly on a stock AT&T N1 with FRF91. Thanks!
Excellent tutorial step by step...great work!
Can i change the password at the end?
So once gaining root, I can flash a custom recovery with rom manager without braking/unlocking the boot loader?
@fc_themaster:
if the superuser app popped up at step 19/20 then you have root rights. you can try to install ROM Manager from the market and install a custom recovery with that porgram. it also needs root rights so superuser should pop up again at that point.
@PSeeCO: you don't need to change a password. the password was only used for the temporary rootshell which you (hopefully) deletetd with the command "rm /system/bin/rootshell" in step 18. From that point on root rights are controlled via the Superuser app. If you install an already rooted custom ROM it is obsolete anyway.
@jivemaster: yes, we can! just use ROM Manager from the market to install custom recovery.
dolomiti7 said:
@PSeeCO: you don't need to change a password. the password was only used for the temporary rootshell which you (hopefully) deletetd with the command "rm /system/bin/rootshell" in step 18. From that point on root rights are controlled via the Superuser app. If you install an already rooted custom ROM it is obsolete anyway.
Click to expand...
Click to collapse
Perfect, thank you so much!
Okay so ChainsDD's Superuser doesnt work on Honeycomb. The reason is a (unnecessary?) hack used by the developer to link properly and use the mktemp function.
To fix this, I downloaded the sources and compiled them again, but this time avoiding the _mktemp hack. Build instructions:
Code:
(get latest CM sources)
# cd <path-to-project-directory>
# repo init -u git://github.com/CyanogenMod/android.git -b gingerbread
# repo sync
(do a generic build)
# source ./build/envsetup.sh
# lunch full-eng
# make
(take a break, this takes a long time)
(fix the su binary)
# cd system/extras/su
# vi su.c
(make the fix, just replace _mktemp with mktemp and remove its declaration)
# mm
(the new su binary should be available in out/target/product/generic/system/xbin)
The fixed binary is attached with this post. Just install Superuser from the market or install it after downloading from ChainsDD's thread (link above). Push the fixed su binary and away you go!!
Code:
# adb push su /system/xbin
# adb shell chmod 4755 /system/xbin/su
Let me know how it goes...
Source Code: https://github.com/j4mm3r/android_system_extras
j4mm3r said:
Okay so ChainsDD's Superuser doesnt work on Honeycomb. The reason is a (unnecessary?) hack used by the developer to link properly and use the mktemp function.
To fix this, I downloaded the sources and compiled them again, but this time avoiding the _mktemp hack. Build instructions:
Code:
(get latest CM sources)
# cd <path-to-project-directory>
# repo init -u git://github.com/CyanogenMod/android.git -b gingerbread
# repo sync
(do a generic build)
# source ./build/envsetup.sh
# lunch full-eng
# make
(take a break, this takes a long time)
(fix the su binary)
# cd system/extras/su
# vi su.c
(make the fix, just replace _mktemp with mktemp and remove its declaration)
# mm
(the new su binary should be available in out/target/product/generic/system/xbin)
The fixed binary is attached with this post. Just install Superuser from the market or install it after downloading from ChainsDD's thread (link above). Push the fixed su binary and away you go!!
Code:
# adb push su /system/xbin
# adb shell chmod 4755 /system/xbin/su
Let me know how it goes...
Source Code: https://github.com/j4mm3r/android_system_extras
Click to expand...
Click to collapse
Works great! My Root is up and working! Thank you!
Updated OP in the other thread to direct people here. Method tested and working perfect. Many thanks to j4mm3r.
How do I make it read/write so I can push the new SU over?
Thanks!
Thank you, gentle sir!
chhaggerty said:
Updated OP in the other thread to direct people here. Many thanks to j4mm3r.
Click to expand...
Click to collapse
Usually this works on the HC image
# adb remount
Or the long form:
# adb shell mount -o remount,rw /dev/block/mmcblk1p2 /system
18.4009 said:
How do I make it read/write so I can push the new SU over?
Thanks!
Click to expand...
Click to collapse
j4mm3r said:
Thank you, gentle sir!
Usually this works on the HC image
# adb remount
Or the long form:
# adb shell mount -o remount,rw /dev/block/mmcblk1p2 /system
Click to expand...
Click to collapse
Thank you, worked like a charm.
Well, I got the SU pushed over and ran the command to set permissions and rebooted but still no root after reboot.
I just got the nook so I am probably do something wrong.
Stuck on root access issue
Many thanks to those who worked on HoneyComb (HC) v4 on eMMC and the rooting solution.
I have root after first flashing to eMMC and checking with terminal. I downloaded and pushed the new SU and still appear to have root -- according to terminal.
The Superuser app opens just fine, but Root Explorer crashes and Rom Manager/CWR complain about not having elevated rights. I *think* I have the latest version of both.
Note: I have only run the two commands above -- and not the list of commands in the OP.
What am I missing here?
Many thanks,
Landlocked
When I type SU in terminal emulator I get an error stating:
"reloc_library[1315]: 1749 cannot locate _mktemp..."
one way to quickly check if you have it working is to do the following:
- Get to a shell:
# adb shell
(this should give you the "[email protected]:/ #" prompt)
- Become un priviledged:
[email protected]:/ # su 1000
[email protected]:/ $
(the "$" indicates that you are no longer root)
- Try to become root again:
[email protected]:/ $ su
This should open up the Superuser dialog asking you to allow or deny superuser request, which means that its working as expected. If you need more help then join on #nookolor on irc.freenode.net (see http://nookdevs.com/IRC for instructions for IRC). I can help you there.
landlocked said:
Many thanks to those who worked on HoneyComb (HC) v4 on eMMC and the rooting solution.
I have root after first flashing to eMMC and checking with terminal. I downloaded and pushed the new SU and still appear to have root -- according to terminal.
The Superuser app opens just fine, but Root Explorer crashes and Rom Manager/CWR complain about not having elevated rights. I *think* I have the latest version of both.
Note: I have only run the two commands above -- and not the list of commands in the OP.
What am I missing here?
Many thanks,
Landlocked
Click to expand...
Click to collapse
Did you replace the "su" binary with the one in the first post?
When I type SU in terminal emulator I get an error stating:
"reloc_library[1315]: 1749 cannot locate _mktemp..."
Click to expand...
Click to collapse
j4mm3r said:
one way to quickly check if you have it working is to do the following:
- Get to a shell:
# adb shell
(this should give you the "[email protected]:/ #" prompt)
- Become un priviledged:
[email protected]:/ # su 1000
[email protected]:/ $
(the "$" indicates that you are no longer root)
- Try to become root again:
[email protected]:/ $ su
This should open up the Superuser dialog asking you to allow or deny superuser request, which means that its working as expected. If you need more help then join on #nookolor on irc.freenode.net (see http://nookdevs.com/IRC for instructions for IRC). I can help you there.
Click to expand...
Click to collapse
I get this error:
Thanks for the info, J4mm3r. I can switch from root to standard user back to root on the NC just fine. None of the programs that are supposed to ask for root are prompting me -- as they do on my Droid 2.
I downloaded the new SU (above) and pushed it over using the sample commands.
I dont think you have replaced the "su" binary with the one that I posted.
18.4009 said:
I get this error:
Click to expand...
Click to collapse
Sorry, for the clutter, but I have appeared to have made some progress. I used the new SU (above) and repeated the steps in this thread:
http://forum.xda-developers.com/showthread.php?t=941445
Rom Manager now properly asks for for SU permission and installed CWR. Root Explorer still crashes, but that may be a file version issue.
j4mm3r said:
I dont think you have replaced the "su" binary with the one that I posted.
Click to expand...
Click to collapse
Strange I pushed you su over to /system/bin and now I have root
This is working perfectly. Thank you so much. All my root apps work properly now.
thanks j4mm3r for the fix
now we just need a fresh hcv5 rooted image to play with.
landlocked said:
Sorry, for the clutter, but I have appeared to have made some progress. I used the new SU (above) and repeated the steps in this thread:
http://forum.xda-developers.com/showthread.php?t=941445
Rom Manager now properly asks for for SU permission and installed CWR. Root Explorer still crashes, but that may be a file version issue.
Click to expand...
Click to collapse
I did the exact same thing, used new SU and completed the steps in the thread above and just installed busybox from titanium bu. Root Explorer is working fine for me.
j4mm3r you are da man! I have a tear in my eye right now, as I am so happy that this got Superuser working. I had lost root and your fix got it back and also now Superuser is asking for permission on everything I have tried thus far (SetCPU, RootExplorer, Root Check, Quick Boot).
The dev support surrounding HC on the NC is nothing short of spectacular. So many thanks go out to so many dang-smart people out there.
THANKS!!
Glad to be of help...
360Razir said:
j4mm3r you are da man! I have a tear in my eye right now, as I am so happy that this got Superuser working. I had lost root and your fix got it back and also now Superuser is asking for permission on everything I have tried thus far (SetCPU, RootExplorer, Root Check, Quick Boot).
The dev support surrounding HC on the NC is nothing short of spectacular. So many thanks go out to so many dang-smart people out there.
THANKS!!
Click to expand...
Click to collapse
Hey,
So a few months ago, I installed either an older version of Busybox, or the newer version I installed never stuck. Basically, I have two folders that contain the busybox commands: /sbin and /system/xbin. In Terminal Emu., when I enter a Busybox command, it seems to only acknowledge the older folder (/sbin). eg if I type in "busybox ifconfig..." or "busybox ipconfig...." I'm told that there's no such command, in so many words. How do I go about fixing this?
Would it mess anything up if I moved the contents of the newer folder (/system/xbin) into /sbin ?
Also, should there be a busybox file located anywhere (ie a file in root that's executed when "busybox" is typed into Term. Emu?) I can only locate the one in the internal sdcard directory ("busybox-stericon")
Thanks
bumpity
alljokingaside said:
Hey,
So a few months ago, I installed either an older version of Busybox, or the newer version I installed never stuck. Basically, I have two folders that contain the busybox commands: /sbin and /system/xbin. In Terminal Emu., when I enter a Busybox command, it seems to only acknowledge the older folder (/sbin). eg if I type in "busybox ifconfig..." or "busybox ipconfig...." I'm told that there's no such command, in so many words. How do I go about fixing this?
Would it mess anything up if I moved the contents of the newer folder (/system/xbin) into /sbin ?
Also, should there be a busybox file located anywhere (ie a file in root that's executed when "busybox" is typed into Term. Emu?) I can only locate the one in the internal sdcard directory ("busybox-stericon")
Thanks
Click to expand...
Click to collapse
I'm no expert, but based on my experience with Linux, I'd say that the safest thing to do would be to create a symbolic link of all the files in /system/xbin/busybox (or wherever) to /sbin/busybox (or wherever)
If you could post the directory listings of "/sbin" and "/system/xbin" it might help.
alljokingaside said:
Hey,
So a few months ago, I installed either an older version of Busybox, or the newer version I installed never stuck. Basically, I have two folders that contain the busybox commands: /sbin and /system/xbin. In Terminal Emu., when I enter a Busybox command, it seems to only acknowledge the older folder (/sbin). eg if I type in "busybox ifconfig..." or "busybox ipconfig...." I'm told that there's no such command, in so many words. How do I go about fixing this?
Would it mess anything up if I moved the contents of the newer folder (/system/xbin) into /sbin ?
Also, should there be a busybox file located anywhere (ie a file in root that's executed when "busybox" is typed into Term. Emu?) I can only locate the one in the internal sdcard directory ("busybox-stericon")
Thanks
Click to expand...
Click to collapse
There is a directory hierarchy in the Android file system.
You can normally see three different directories for binaries. These have the following priority:
/system/bin
/system/xbin
/sbin
This means that if there are two binaries with the same filename, the binary in the more prioritised map will be executed.
In your case, the /system/xbin has a higher priority than /sbin.
As I see it, you have the following choices:
Keep them co-existing. To select an indiviual binary, enter
/sbin/busybox [function] [arguments]
or
/system/xbin/busybox [function] [arguments].
Remove the unwanted one.
If you are unsure of which you want to discard,
just enter the commands as written in the first choice (without any functions of course).
I hope this post helps you.
I've been a "rooter" for years now. Had 3 HTC Ones, all rooted and one S-Off. Never had an issue like this. I can seem to get BusyBox to install. When I do get it to install it eventually uninstalls itself for some odd reason. Any suggestions?
What I had to do, is flash busybox from TWRP, installing from playstore did not work at all. It has something to do with HTC security.
I just tried that and couldn't seem to find where it's stored.
Sent from my HTC One using XDA Premium 4 mobile app
Added a couple edits, explained at the end of some paragraphs in case someone comes across this, don't like leaving things incorrect if I know it. I strongly recommend enabling xtrace in the shell to check what's actually being executed, you see your functions and aliases expanded too. With all (busybox ash)|mksh|bash|zsh you can do 'set -x' at any time, append it when calling the shell: 'sh -x' or 'sh -o xtrace' with 'sh' being a symlink to any of the mentioned shells; sh runs the shell in posix mode.
Diesel321 said:
I've been a "rooter" for years now. Had 3 HTC Ones, all rooted and one S-Off. Never had an issue like this. I can seem to get BusyBox to install. When I do get it to install it eventually uninstalls itself for some odd reason. Any suggestions?
Click to expand...
Click to collapse
This sounds like SELinux shenanigans. I don't have the HTC One, but I've experienced similar oddities with a SELinux enforced system. (latest TWRP includes SELinux which might be why a twrp doesn't make a difference) With the addition of the SELinux filesystem, a new "file context" permission is attributable to each file/process. The context defines a user, basic function, that it's in the right place, and a sensitivity parameter. There's some good basic info on the SELinux wiki page with commands.
If your system is using enforced SELinux, a program like busybox installed without setting context is going to be denied to exist/run by default, but this depends on how SELinux is configured. I'm guessing it's context is not being set, so it's getting purged on reboot. Another possible SELinux related issue : a custom kernel that doesn't support SELinux is installed on a rom with SELinux --> bad mix, so if that's the case don't be surprised if more issues like this crop up or a data wipe in your sleep randomly occurs out of nowhere --This happened to me twice actually after disregarding this warning-- You can check your SELinux status with
Code:
getenforce
-in adb or terminal emu. This should also be displayed in phone info menu in settings. Make sure it's "permissive" or "enforced". Permissive logs warnings of what SELinux would do if enforced. You can change SELinux to permissive with:
Code:
setenforce 0
This only works if both your kernel and rom are Selinux compatible. Btw you'll probably find all your SELinux command tools in /system/bin symlinked from toolbox. There's also runcon (run with a context), chcon(change context), restorecon (restore original context), and updates have started integrating a flag (usually -Z) to **filter in** SELinux permissions, e.g. toolbox ls -Z. Busybox does not seem to have updated its tools that could support this, at least on Android. *Even Vanirs busybox 1.22.1.awesome doesn't have the ls -Z function. I was shocked to find out "Toolbox!" was actually useful for something, had a mental breakdown over it a couple months ago. [edit: After reading up on some busybox technical stuff, I found that busybox in its rarely seen full version can in fact be compiled with SELinux extended functions. The reason that almost every rom dev out there uses a busybox that doesn't include every function is portability, case rom to rom ;; older to newer vice versa ;& so that problems will be minimized ;; esac.
**(filters not a good way to put it at 2nd glance, sounds confusing. I mean 'test' or read ACLs<extended perms)
So I would check busybox' context after installing it:
Code:
ls -Z "$(which busybox)"
If it's undefined or unconfined, we will change it to this:
Code:
u:object_r:busybox_exec:s0
.. We can fix it ourselves over adb or in a su'd mksh/bash shell, (use supersu since cwm superuser does not pass arguments correctly or at all in most situations):
Code:
su --shell mksh exec -c mksh -x --
First try to restore original context from file_contexts and see if it works:
Code:
restorecon "$(which busybox)"
Then set busybox' context:
Code:
sync && mount -w -o remount -t ext4 /system /system
chcon u:object_r:busybox_exec:s0 "$(which busybox)"
sync && mount -r -o remount -t ext4 /system /system
*** added "-t ext4" to mount command- it should then work with toolbox or busybox no errors
The other thing I might guess besides all this SELinux file context stuff is that the installation of the busybox binary didn't write to disk. If you run fsync off in your kernel, a fast reboot soon after busybox installation could very possibly lead to data loss of recent files. Similarly, but without a huge risk of collateral damage, recent changes to files could be lost if you have writeback journaling enabled for /system and you rebooted within (dirty expire + dirty writeback) / 100 seconds. A normal reboot that spends 5-10 seconds dumping and getting everything written to disk should be fine though. IF the new busybox' "mount" applet/function is incompatible or broken or outdated, a mount failure could occur leading to data loss. Backup toolbox mount in /system/bin should be enough to save this though, so I'm sticking with my diagnosis of a "SELinux gotcha".
Hope this helps, nothing worse than losing busybox or su functionality. As a side note, in case this problem takes a few days to figure out, check out Terminal IDE if you haven't before. It is definitely a nice busybox replacement to say the least if you need backup/better primary tools, at least temporarily. It's probably the most valuable app/terminal/busybox/Java/c/c++/ide/apkbuilder I've ever seen. ZERO ads, no net connection. You can get the latest apk off Google code, and there's a thread on xda by the creator Spartacus Rex. The tools and configurations are much more heavy duty than anything I've seen for Android. It has great well written tutorials to walk anybody through java, c, some shell stuff and utilizing ssh,telnet,iirc,git to make using android more like a linux machine. I've really gotten into this so I thought I would mention it.
7175 said:
... Busybox does not seem to have updated its tools that could support this, at least on Android. *Even Vanirs busybox 1.22.1.awesome doesn't have the ls -Z function. I was shocked to find out "Toolbox!" was actually useful for something, had a mental breakdown over it a couple months ago. [edit: After reading up on some busybox technical stuff, I found that busybox in its rarely seen full version can in fact be compiled with SELinux extended functions. The reason that almost every rom dev out there uses a busybox that doesn't include every function is portability, case rom to rom ;; older to newer vice versa ;& so that problems will be minimized ;; esac.
Click to expand...
Click to collapse
This must be the only sensible post on XDA, that has both Busybox and SELinux in the same post! Thanks.
Any ideas where to get a fully context featured Busybox? Tried to look in those tips you gave, but they're all outdated, i.e Busybox versions lower than 1.22.1.
tl;dr: working as root, I want to create a file that is world-readable.
Background: I'm using sshdroid and sshfs to access my phone, and termux on the phone itself. Sshdroid is configured to let me log in as root (ssh public key, not password), which is useful for other reasons. Working in sshdroid, I want to be able to create a file that is readable from termux (and other apps, notably tasker).
Example interaction (I have previously set directory permissions to allow access):
sshdroid> echo aaa > foo
sshdroid> chmod 644 foo
termux> cd /data/data/berserker.android.apps.sshdroid/home
termux> cat foo
cat: can't open 'foo': Permission denied
termux> ls -l foo
-rw- r-- r-- 1 u0_a202 u0_a202 4 Feb 10 00:55 foo
This seems to be SELinux-related, or possibly something to do with ACLs or extended attributes (lsattr shows nothing interesting; getfacl doesn't seem to be available in termux and sshdroid so I can't check that).
Experimentation shows that I can do "touch foo" in termux, then move foo to sshdroid's home and chmod it to 644. That works. But if I want to use sshfs via sshdroid to move a bunch of files to the phone, that's not a practical approach.
I'm guessing that SE Linux Switch or SE Linux Mode Changer would solve the problem, but in my usage scenario it would be suboptimal to have to reboot whenever I wanted to use sshfs, and likewise it seems suboptimal to permanently disable SELinux.
I'm thoroughly experienced in Unix/Linux but not in SELinux. So I'd love it if somebody were to point out a glaringly obvious solution.