Related
Before reading.
This article requires that your phone is Rooted and has Busybox installed.
HTC owners, S-off your phone as well.
Android is a great operating system for SmartPhones. Only problem with it (From a more technical users point of view) is the small useless bad excuse of a linux system running behind the UI. Some of the smaller issues can be fixed by installing Busybox that provides a better basic set of tools to work with, but it's not enough. What I would like is to be able to use almost any real linux cli application, daemon, library etc. Also some compilers would be great. I'm using an HTC desire which has more than enough power to do things like compiling (I know, I have done it.), and so has a lot of other SmartPhones. Why would one need this when there is cross compilers you can use on regular and faster machines? Well, because It's fun, why else. I did not spend all that money on a SmartPhones just to make a few phone calls and write a few text messages. My old Sony Ericsson did that quite well. I spend that money to get a phone with many possibilities that I could play with.
I tried to search the web for some helping instructions on how to port a real linux system to this phone. What I mostly got, was people who ported linux systems that would run as an extra OS on the phone, some even with an Xserver accessible via VNC. Sounds fun, but not what I was after. I did not want an extra OS using CPU and unnecessary RAM. I just wanted some extra tools, libs etc to work with and the regular linux user management. I managed to find an old article from someone using Debians armel version on an old G1 phone. I thought that if it worked on that phone, it would be possible to do so on mine. So I started playing around with that.
The way this works is by installing a bare minimum debian on an second partition. This will not boot anything up since it will just work as extra tools and lib using the already booted android linux system.. You will still only have one OS but more tools (Including the nice APT package system) to work with.
Now there is two ways of using debian on android.
The first way is to setup the Debian in an chroot environment. This has some flaws like I have not yet been able to make the chroot start second jobs, which means that you will be able to start applications and daemons running in the current shell session. But you will not be able to make them run in the background. But as an development environment it will still work great, as you will be able to use the Debian libs and compilers.
The second way (The way I was after) is to setup Debian using the UAFS kernel module. This is used to merge directories into one with different rules for each. For an example you would be able to merge /debian_root/etc and /system/etc into a shared /etc with RW on Debians etc and RO on Androids forcing any changes to be made in /debian_root/etc. Using this option you will use Debian to extend the Android Linux part. Android UI with Debian Shell.
This article is split into 3 parts. The first part is the setup of Debian. Must be done whether you want chroot or a merged system. In the second part we will cover the setup of the chroot environment.
The third part is the setup of the merged system. This will require one thing in order to work.
You will need a kernel with the uafs module which is not default in most android kernels. You will need to compile your own kernel. People using the Thalamus kernel, can download a kernel with this module kernel-2.6.37.2_AUFS.zip. A big thanks to Thalamus for providing this. Note that this kernel was a special request from me that he was kind enough to provide. It comes with absolutely no guaranties. Do not email spam him about errors you might encounter using it as this is not an official release.
Note that once you mount the Debian system, you will not be able to mount the SD Card when connecting it to your PC. You can download the App “Multi Mount SD-Card” from Market which will be able to mount your SD Card on your PC while mounted on your phone. This app should also speed up transfers on 2.6.37 kernels, or so I have heard.
Part 1: Building Debian
We are going to run debian from a file containing a ext2 filesystem. If your SD Card is big enough you might be able to create an extra partition and force it to mount as something else other than ext-sd, but in this article we are going to use a partitioned file.
Also, this will require that you have the tool “debootstrap” on your PC. This is found in Ubuntu and Debian, dont know about other Linux distro's or Operating systems. If you don't use Linux or an distro with debootstrap you can download a Ubuntu Live CD from the Ubuntu website. This can be run on CD, DVD and USB disks without installing it. For this article I have used Ubuntu 10.10.
Open a terminal on your Ubuntu/Debian/LiveCD PC and cd to the folder where you want to temp. store your debian. I will call this path “debian_dir”
The first thing we will do is to create the partitioned file.
I'm creating a file with 1.5GB of space. You can create the size you want.
Don't use 0 in the size, dd don't like that.
Code:
cd debian_dir
dd if=/dev/zero of=debian.img seek=1499999999 bs=1 count=1
mke2fs -F debian.img
mkdir debian
mount -o loop debian.img debian/
Now that we have created the file and mounted it, we should download and place debian inside of it. First we will install debootstrap.
Code:
apt-get install debootstrap
debootstrap --arch armel --foreign squeeze debian http://ftp.us.debian.org/debian
umount debian/
Debian Squeeze is Debian 6.0 which replaces the old Lenny.
Copy the debian.img file to your SD Card on your phone. I placed mine in the root of the SD Card.
Now open a terminal on your phone. You can download one from market. There are some free once, but the paid “Better Terminal” is the best to work with in my opinion.
Note: All shell work is done on the phone from now on.
First we need some temp. exports.
Type the fallowing:
Code:
export PATH=/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin:$PATH
export HOME=/root
export TERM=linux
export DM=/data/local/debian
export DI=/sdcard/debian.img
Now we will create the Debian dir and then create a loop device which we will use to mount the Debian image to the Debian dir.
Code:
mkdir -d $DM
mknod /dev/loop0 b 7 0
mount -o loop,noatime $DI $DM
Now that we have debian mounted in our debian folder, we need to finalize the installation. Not all files as been installed yet. Don't forget to activate Mobile Network or Wifi.
chroot $DM /debootstrap/debootstrap –second-stage
We also need to insert the debian repository and a DNS (I use OpenDNS).
You can use whatever you want for the DNS, you routers IP for an example. It should have some default Ips configured.
Code:
echo “deb http://ftp.us.debian.org/debian squeeze main contrib non-free” > $DM/etc/apt/sources.list
echo “208.67.222.222” > $DM/etc/resolv.conf
Now change the root to the debian dir and set a root password and make sure that certain folders already exists.
Code:
chroot $DM /bin/bash
passwd root
mkdir root
exit
Now we need to make sure that certain variables exists and that the values is as they should be. So we will alter the /system/bin/sh that android uses as login shell.
Code:
cd /system/bin
mv sh sh0
Create a new /system/bin/sh file with the fallowing content.
This will ensure that these variables is created and/or changed every time you enter a new shell session. You can call another shell like bash or ash instead /system/xbin/sh, just make sure to use ash or sh at the top, since bash does not seam to understand [email protected]
Warning: It is very important that the /system/bin/sh file is made correct. Android will not boot if anything is wrong with this file. It should be exactly like the one I posted, and you cannot make it on your PC and push it to the phone. Don't know why, it works fine with other shell scripts, but not that one.
Enter an adb shell from your PC and use vi or nano (You can download nano here here) to copy and paste the content directly into the ADB Shell.
Note: ADB from the recovery will always work. It does not use /system/bin/sh
Code:
#!/system/xbin/sh
/system/xbin/sh --login [email protected]
Make sure that it has execute rights. Then type sh in the terminal to make sure that it works before you close your ADB Shell session.
Code:
chmod a+x /system/bin/sh
sh
sh0 will not be used, it's up to you wether you want to save it or not. Just make sure that /system/xbin/sh exists, otherwise
copy /system/bin/sh0 to /system/xbin/sh.
Now we need the profile file that is needed by this method. This file will make sure that we have all our variables and the data that they should contain.
Android does not keep very good track of these things. Place this data in the file /system/etc/profile
Code:
export TERM=linux
export TERMINFO=/etc/terminfo
export PATH=/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin:/vendor/bin:/system/bin:/system/xbin
if [ "$EUID" == "0" ]; then
if [ -z "$HOME" ] || [ -z "$USER" ] || [ -z "$GROUPS" ]; then
export HOME=/root
export USER=root
export GROUPS=0
fi
else
# Make sure that this user id variable exists.
if [ -z $EUID ]; then
export EUID=$(echo $(id | cut -d "(" -f 1) | cut -d "=" -f 2)
fi
# If we have an /etc/passwd file available,
# we should also make sure to get name, group and home info from that file and
# store in the default linux variables.
if [ -f /etc/passwd ]; then
# Create the user info variables based on user id and /etc/passwd
export USER=$(grep "x:${EUID}:" /etc/passwd | cut -d : -f 1)
export GROUPS=$(grep "x:${EUID}:" /etc/passwd | cut -d : -f 4)
export HOME=$(grep "x:${EUID}:" /etc/passwd | cut -d : -f 6)
fi
fi
export ADID=$EUID
if [ "$PS1" ]; then
if [ "$BASH" ]; then
# The file bash.bashrc already sets the default PS1.
if [ ! -z $HOME ] && [ -f $HOME/.bashrc ]; then
. $HOME/.bashrc
elif [ -f /etc/bash.bashrc ]; then
. /etc/bash.bashrc
else
export PS1='\h:\W\$ '
fi
else
if [ "$EUID" == "0" ]; then
PS1='\w # '
else
PS1='\w $ '
fi
fi
else
PS1='\h:\W\$ '
fi
if [ -d /etc/profile.d ]; then
for i in /etc/profile.d/*.sh; do
if [ -r $i ]; then
. $i
fi
done
unset i
fi
We will also need an /etc/bash.bashrc which is needed because /etc/profile not always gets executed.
Code:
if [ "$ADID" != "$EUID" ]; then
# Some times /etc/profile is not executed (For an example when using Androids su command).
# /etc/bash.bashrc however it used instead. So we just execute it manually in these cases.
# If you create a local bashrc ($HOME/.bashrc), remember to include this check.
# /etc/bash.bachrc is not used when a local file exists.
if [ -f /etc/profile ]; then
. /etc/profile
# Since /etc/profile links back to this file,
# we will make sure not to start an unending loop.
# the profile file should update this, but it's better to be on the safe side.
if [ "$ADID" != "$EUID" ]; then
export ADID=$EUID
fi
fi
fi
PS1='\h:\W\$ '
And last we have some user and group configurations in order to make Debian better work with Android. Open your Android terminal emulator and make sure it opens as user and not root. Now type "/system/xbin/id".
What we need here is the uid, gid and the ids of each accosiated groups along with the names of it all. In my terminal I have "uid=10048(app_48) gid=10048(app_48) groups=1015(sdcard_rw),3003(inet)".
What we will do it create this user along with the groups in our Debian inveroment. However, I use the uid name and gid name "bterm" instead of app_48, but still with the original IDs. The inet and sdcard_rw groups will be created as system groups. Do the same for your app user and group if you don't want any login possibilities with this user. I however have assigned home and password to this user.
This needs to be doen in chroot
Code:
chroot $DM /bin/bash
groupadd --system --gid 1015 sdcard_rw
groupadd --system --gid 3003 inet
groupadd --gid 10048 bterm
adduser --home /home/bterm --gid 10048 --uid 10048 bterm
gpasswd -a bterm sdcard_rw
gpasswd -a bterm inet
exit
Now your ready for the next step. Remember that the user you have created, is the user used by your terminal emulator when you are not logged on as root. This ID is only assigned to that specific app, if you install another terminal, it will get another ID.
Part 2 – Setting up a chroot environment
The best way of doing this is to make two small scripts and place them in /system/bin or /system/xbin. One script for doing the mount after phone boot. And one script for entering the chroot when open a new shell session.
Here is the mounting script that I call mkdebian.
This needs to be executed once every time the phone has rebooted. If your ROM supports init scripts, you can add it there for auto-mount on boot.
Code:
#!/system/bin/sh
export DM=/data/local/debian
export DI=/sdcard/debian.img
# Create the loop device and mount the debian image
mknod /dev/loop0 b 7 0
mount -o loop,noatime $DI $DM
# Let's make sure that we can access our sd card from within the chroot
if [ ! -d "$DM/mnt/sdcard" ]; then
mkdir $DM/mnt/sdcard
fi
mount --bind /mnt/sdcard $DM/mnt/sdcard
# Now we make sure that the chroot has access to all the device maps
if [ ! -d "$DM/dev" ]; then
mkdir $DM/dev
fi
mount --bind /dev $DM/dev
# We also need to make proc, sys etc available from within the chroot
chroot $DM mount -t proc proc /proc
chroot $DM mount -t sysfs sysfs /sys
# And last fix the mtab
chroot $DM rm -f /etc/mtab
chroot $DM ln -s /proc/mounts /etc/mtab
echo “Debian was mounted in $DM/”
Now for the script that I called “debian”.
This script will make you enter the chroot environment using one single command. Every time you exist the debian chroot, you can enter back using the command “debian”.
Code:
#!/system/bin/sh
chroot /data/local/debian/ /bin/bash
And that is it. Open a terminal, type debian and start using your debian environment. It might be a good idea to run aptitude update or apt-get update before you start using the package manager.
Part 3 – Settings up a merged Android/Debian environment
This is the fun part to play with. A merged Android/Debian environment without the usage of chroot. This only requires a script to be executed at boot, or after boot.
Remember that this will not work unless your kernel has the aufs module.
Code:
#!/system/xbin/sh
export DM=/data/local/debian
export DI=/mnt/sdcard/debian.img
# Now we mount the debian image to our debian folder.
mknod /dev/loop0 b 7 0
mount -o loop,noatime $DI $DM
# These two directories exists in both android and debian,
# so these are going to be merged together.
mount -t aufs -o dirs=$DM/etc=rw:/system/etc=ro aufs /system/etc
# For some reason, mounting /sbin with aufs does not work.
# So we make a little cheat with symbolic links instead.
mount -o remount,rw /
mv /sbin /sbin0
ln -s $DM/sbin /
rm -rf /sbin/adbd
rm -rf /sbin/ueventd
ln -s /sbin0/adbd /sbin/
ln -s /sbin0/ueventd /sbin/
# Let's get all the debian root directories out to the real root dir.
rm -rf /root
for x in tmp root lib bin boot home media opt selinux srv usr var
do
ln -s $DM/$x /
done
if [ -f /system/xbin/bash ]; then
mount --bind /bin/bash /system/xbin/bash
mount --bin /system/xbin/bash /system/xbin/sh
else
mount --bind /bin/bash /system/xbin/sh
fi
echo "Debian has been merged with Android..."
Run this at startup and start using all of debians possibilities (Don't run it yet).
The / dir is left with RW permissions. If this is set to RO then apt-get will not work. It writes tmp log files to this dir when running. It does not matter since all changes to this dir is restored to default on every boot.
Also dont forget to run apt-get update or aptitude update to update the package list.
You are now able to install and run almost anything (CLI Only) that runs on debian systems and other linux dists. Personally I'm currently running OpenSSH Server and Lighttpd with PHP. A perfect small transportable web server.
You can use either /etc/init.d/[your service] start
or
service [your service] start
to start daemons you have installed.
Now you can use the "mkdebian" command to merge your new Debian with Android.
Note: The command “su” from debian works differently than the android “su” command.
The debian command uses the regular linux management to provide access which means that it will ask for your root password that you created in the first part. The android command will just provide you with su rights without a password. Both commands provides su rights to both android and debian, so it is possible to remove the android command and create a new Android/Java based SU app for the Android UI that will require root password.
Note: There is a small problem with the Android "su" command. It does not recheck the /etc/profile.
That means that if you log on using the regular user, and then uses the "su" command, user variables does not get updated with su paths.
Using the Debian "su" command will work fine, just note that this command will promp for password. Also logging in using the root account
directly works fine.
Good luck
[Edit: 2011-03-09 11:06]
- Changed the /etc/profile script in Part 1
- Added /etc/bash.bashrc script in Part 1
- Changed User and Group setup and moved it from Part 3 to Part 1
- Fixed error in /system/bin/sh
All of this will fix some permission problems with Debian
[Edit: 2011-03-08 11:21]
- Fixed problems with user management by adding an /etc/profile and changing /system/bin/sh and the debian merge script. Using the "login" command is no longer needed.
[Edit: 2011-03-07 08:49]
- Fixed bug in Part 1 sh script.
[Edit: 2011-03-07 00:20]
- Added a new /system/bin/sh script to Part 1
- Added the way we create missing users and groups in Part 3
[Edit: 2011-03-06 19:36]
- Inserted a warning text in part 1 about avoiding problems when creating a new /system/bin/sh.
Applying Host name
If you want to set a custom hostname for your phone, you can create an init script (If your ROM supports it).
Code:
#!/system/bin/sh
# Get the hostname if it exists, or set it to localhost
if [ -f /system/etc/hostname ]; then
_HOSTNAME=$(cat /system/etc/hostname)
if [ -z $_HOSTNAME ]; then
_HOSTNAME=localhost
fi
else
_HOSTNAME=localhost
fi
# Update the Hostname
echo "$_HOSTNAME" > /proc/sys/kernel/hostname
# Update the hosts file
echo "127.0.0.1 localhost.localdomain localhost" > /etc/hosts
# If the hostname is not localhost, we add one more line to the hosts file
if [ "$_HOSTNAME" != "localhost" ]; then
echo "127.0.0.1 $_HOSTNAME" >> /etc/hosts
fi
This will look in /system/etc/ for the regular linux hostname file. If it exists, it will take the hostname from that file and set as the global hostname.
If it does not exist, "localhost" is used instead. Also it creates the /system/etc/hosts file.
Add or Edit your hostname like this.
Code:
echo "myhostname" > /system/etc/hostname
Note: Remember to delete the hosts and hostname files in your debian /etc/ dir when using merged environment. Otherwise they will overwrite the once in /system/etc/ as debian has first priority.
Manipulating the Android Permissions
Androids permissions works by providing a User ID for each application. This user (Application) can then get a range of different permissions by being added to groups with the permissions required by the app. For an example an app that needs to write to the SD Card, should be a member of Androids sdcard_rw group which translates into 1015 in a Linux group id. Using the numeric values of the Android groups, we can assign these permissions to shell users, daemons etc.
An example:
I had problems with my Http Server because I wanted my www folder on my sdcard. But, the www-data user and group could not be allowed to write to the SD Card, which I needed it to do, because Android controls what permissions the SD Card should have, not even root can change that.
What I did was creating a system group that I named sdcard_rw (Same name as the android, just to better keep track of the groups) with the same Id as the Android sdcard_rw (1015). I then assigned that group to my www-data user (gpasswd -a www-data sdcard_rw) and now my lighttpd had Read/Write access to my sdcard.
You can use the same example for creating a regular SSH User by using the Android shell group or for any other type of user that needs some Android permissions to work properly.
[Edit: 2011-03-08 21:13]
- Added an permission example
Great...
I was just looking into this myself for the last few days.
strange how there isn't more of this being talked about.
at least I have been unable to find anything.
Omg this sounds awesome,
Will try this when u get home and will report back
Sent from my Nexus One using XDA App
I'm still trying to work out some problems with User Rights on SD Card. Can't get lighttpd to be allowed to create files in my SD Card www dir (Does not matter what user and group I set it to use). I can't even get the root account to be allowed to change permissions on SD Card files and folders. It's not the biggest problem, but will report back when I figure it out.
Nice! I've been constantly disappointed for the past year at how un-Linuxy Android is under the hood and unimpressed with the old chroot tricks. This looks much better and I'll try it soon.
I have added a new /system/bin/sh script that can be found in Part 1. This script will automatically look for bash and, if that exists, try to find bash.bashrc, .profile or .bashrc in /etc or the users home dir. If bash does not exist, it looks for sh instead. If you have both one of the Android specific compiled bash, then Debians bash is used when available as this is made to work in a real linux environment. Android bash does not seam to work that way. Also debians packages gets updates via APT.
Also I changed the way groups and users is created in Part 3. Manually inserting them to /etc/passwd, /etc/shadow and /etc/group did not seam to be enough. The users and groups where only half registered. For an example the command "login" gave me a lot of errors, and i had problems with user rights. By using adduser and addgroup in a chroot before the first merge, the user management seams to work as it should now.
I was playing with Debian on my phone just a few days ago too. I've found that same G1 article you mentioned, and installed Lenny in a chroot environment. Background daemons work fine for me, I've installed OpenSSH and I'm using ConnectBot connecting to 127.0.0.1 to get a terminal, so I don't have to chroot every time. I even have X with tightvnc server + android-vnc-viewer. Running the desktop Firefox on my phone is fun Although not very useful. I'm still thinking about what awesome things we could do with this that we couldn't otherwise.
Anyway, great howto.
Do you have any details on the Thalamus kernel? What phone is it for? Overclocked, audio hack, etc? Or is it just a vanilla kernel with the extra module?
What applications can we dream up?
The first thing that springs to mind is could this be used to create a low power server running bittorrent and the like?
Would a cheap device like the Vodafone 845 be under-powered for this?
Can you connect to a usb hub to allow multiple devices to be connected to it? I'm thinking usb network adapters, external storage, etc.
How much additional effort on top of this guide would be needed?
Just curious...
will not... - -!
Well I learned one thing. Don't make Shell scripts when you are tired. I started a shell loop on phone bootup with my /system/bin/sh fix (Which had been changed). When using the merged environment, you need (for now) to enter /bin/login when you open a new shell and login as user with the password you created in Part 3. This will make Debian take over the user management which among other things will make sure that the right variables etc. exists. I have tried to locate where android controls new shell sessions, but I cant seam to find it.
When you make Debian take over, you can use your Linux shell as any other. .bashrc, .profile, /etc/bash.bashrc, /etc/profile files, change default shell (bash, sh, ash) in /etc/passwd and so on.
#9 Well the kernel is the same that is found in the Oxygen 2.0.1, so it's an gingerbread rom (2.3.3). If it works only in Oxygen, I don't know but I don't think so.
#10 He he, Could not say. For now I'm just trying to make it work as I want it to work. After that I might start playing around with different things.
The "login" command is no longer needed. I finally found a way to successfully control user variables and management, making Android and Debian work together as one when merging the two.
This is amazing. Totally going to do this later tonight when I get home.
If you merge using AUFS instead of making a chroot, you should perhaps use the system user (Id: 1000, Group: 1000) as the regular user.
There are only two static users in Android, 0 and 1000.
Android just isn't made to work as an multi-user system. This is how the Java UI is made, and we really need to Linux part to be compatible with that part of the OS. Instead of multi-users, android uses it's apps as users. Each app works as one user with different id. So the 10048 I used as regular user is just the ID of mine "Better Terminal". Switching to another terminal app changed the EUID.
Use the root and only root to work with in the shell. And then delete Debians "su" command and stick with the one from android. Debians need all users that execute "su" to be written to the /etc/passwd.
All GNU tool and library, that's Great. thanks a lot.
I have added an example of how to apply Android rules to shell users, daemons etc. Some daemons will need this in order to function.
I have added this in Thread 2 below the hostname example.
I also changed the main Thread. Found a fix for the rest of the permission problems, including the Android "su" command issue.
I have tested this Android/Debian merge using several methods (ADB, SSH, different local terminals) and it worked on most. I had one problem with one local terminal app that did not execute /etc/profile and some Debian users in /etc/passwd that didn't either.
To fix this I changed /system/bin/sh from using "/system/xbin/sh --login [email protected]" to instead use "/system/xbin/sh --rcfile /system/etc/profile [email protected]". I then moved the Debians /bin/bash to /usr/bin/bash and made a similar script file in /bin/bash > "/usr/bin/bash --rcfile /etc/profile [email protected]". You can make the same for /bin/sh if you don't like using bash for your /etc/passwd users.
Remember to change the bash bind mount in the mkdebian script from /bin/bash to /usr/bin/bash
Use whatever method works on your phone.
This looks like a ton of fun, and could be very useful. I'd like to try this on my NookColor (N2Acard, CM7.1), probably using The Guardian Project's lilDebi image as a base. They go the chroot route with their installer, and I'm going to have to do some hacking on their scripts to make them work with the NookColor. I figure if I'm going to have to hack on it, I might as well put my efforts toward a more ideal solution.
Question: It doesn't look like the CM7.1 kernel supports aufs. That is,
Code:
cat /proc/filesystems
doesn't return aufs as one of the supported filesystems.
Aside from a lack of elegance, is there any reason we can't apply your /sbin workaround to "merging" the whole filesystem? [I recognize there's a certain amount of ignorance behind the question; I figure there's only one way to cure that: Ask.]
OR, how difficult might it be to take a complete CM7.1 kernel and add aufs support to it?
'preciate any help I can get!
mailman1175 said:
This looks like a ton of fun, and could be very useful. I'd like to try this on my NookColor (N2Acard, CM7.1), probably using The Guardian Project's lilDebi image as a base. They go the chroot route with their installer, and I'm going to have to do some hacking on their scripts to make them work with the NookColor. I figure if I'm going to have to hack on it, I might as well put my efforts toward a more ideal solution.
Question: It doesn't look like the CM7.1 kernel supports aufs. That is,
Code:
cat /proc/filesystems
doesn't return aufs as one of the supported filesystems.
Aside from a lack of elegance, is there any reason we can't apply your /sbin workaround to "merging" the whole filesystem? [I recognize there's a certain amount of ignorance behind the question; I figure there's only one way to cure that: Ask.]
OR, how difficult might it be to take a complete CM7.1 kernel and add aufs support to it?
'preciate any help I can get!
Click to expand...
Click to collapse
here's where you get aufs patches.
you'll have to build the kernel yourself to make it work.
to the OP:
using the aufs mount method instead of a chroot...
I have a small problem, I don't know if it shows up with your .img filesystem method, but with an sd-ext partition used intead of the .img file, apt-get fouls massively when trying to update/upgrade libc6.
it complains about the libc6*.so existing in two places at once, and requests the existing one be removed. If it's removed, then nothing in the Linux install works, because just about everything is compiled against libc. I can use busybox to manipulate files with the libc6 removed or hidden away, but can't seem to get past the error since dpkg and apt don't work without some version of libc installed.
Any hints/suggestions? I like your scripts a lot better than the chroot ones I cobbled together from everyone else's work last year for similar purposes before I got aufs working in a kernel.
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.
I'm trying to understand why I still get such "Permission denied" errors though I'm UID root.
I will describe my setup and particular error, but I think a proper explanation of what's happening may interest others.
I just need occasional root shell for reverse engineering sessions, and from what I know, a simple way to achieve this is to boot a modified initial ramdisk that contains a properly modified /default.prop, and/or a setuid shell, and/or some kind of su command.
I managed to successfully boot the device (Moto G) with my custom modified image using "fastboot boot custom_boot.img".
First I can verify it's actually "my initrd.img" that's in use:
Code:
[email protected]_umts:/ $ cat /default.prop
#
# ADDITIONAL_DEFAULT_PROPERTIES
#
[I]ro.secure=0[/I]
ro.allow.mock.location=0
[I]ro.debuggable=1[/I]
This does _not_ allow me to get root shell (with "adb shell"):
Code:
[email protected]_umts:/ $ id
[I]uid=2000(shell)[/I] gid=2000(shell) groups=1003(graphics),1004(input),1007(log),1009(mount),1011(adb),1015(sdcard_rw),1028(sdcard_r),3001(net_bt_admin),3002(net_bt),3003(inet),3006(net_bw_stats) context=u:r:shell:s0
So, I added a setuid copy of /system/bin/sh to the initial ramdisk, at "/sbin/shell0".
Code:
[email protected]_umts:/ $ ls /sbin/shell0 -l
[I]-rwsr-xr-- root shell[/I] 157424 2014-07-14 16:08 shell0
[email protected]_umts:/ $ /sbin/shell0
# id
[I]uid=2000(shell)[/I] gid=2000(shell) groups=1003(graphics),1004(input),1007(log),1009(mount),1011(adb),1015(sdcard_rw),1028(sdcard_r),3001(net_bt_admin),3002(net_bt),3003(inet),3006(net_bw_stats) context=u:r:shell:s0
# exit
[email protected]_umts:/ $ /sbin/shell0 +p
[email protected]_umts:/ # id
[I]uid=0(root)[/I] gid=2000(shell) groups=2000(shell) context=u:r:shell:s0
[email protected]_umts:/ # ls /data/
[I]opendir failed, Permission denied[/I]
Here, it appears that I have to use the "+p" flag to prevent the shell to immediately get back to the real user id (2000), despite the suid bit is set on /sbin/shell0.
But I don't understand I don't have the permission neither to open simple directories as /data, nor to read the interesting stuff in the /proc subsystem, though I'm uid=0 (root).
I've also tried adding to the initial ramdisk a simple su command, at /sbin/test_su, that does the setuid(0)/setgid(0)/execve(...) thing (snippets available at android.googlesource.com).
But though this properly keep the supplementary groups I had lost within the previous try above, I still can't read into /data:
Code:
[email protected]_umts:/ $ ls -l /sbin/test_su
[I]-rwsr-xr-- root shell[/I] 6316 2014-07-14 17:12 test_su
[email protected]_umts:/ $ test_su
[email protected]_umts:/ # id
[I]uid=0(root) gid=0(root)[/I] groups=1003(graphics),1004(input),1007(log),1009(mount),1011(adb),1015(sdcard_rw),1028(sdcard_r),3001(net_bt_admin),3002(net_bt),3003(inet),3006(net_bw_stats) context=u:r:shell:s0
[email protected]_umts:/ # ls /data/
[I]opendir failed, Permission denied[/I]
From a un*x point of view, it seems weird to me that the shell still answers "opendir failed, Permission denied" while I'm uid/gid 0 (root).
I will continue to investigate, notably regarding SELinux which may enforce rules I'm not aware of, but would also greatly appreciate anyone who could put some light on this issue. At least for me it's an issue, as I don't understand what's happening.
Thanks.
t0kt0ckus said:
So, I added a setuid copy of /system/bin/sh to the initial ramdisk, at "/sbin/shell0".
Click to expand...
Click to collapse
Note that making a setuid shell executable might not be 100% reliable. When I've tried this with bash, it quickly realizes that getuid() != geteuid(), and drops the root permission.
I don't see this happening in your logs, but it's something to watch out for. Typically I've just used simple wrapper programs like the attached file to guarantee that the real/effective/saved UIDs are 0/0/0.
From a un*x point of view, it seems weird to me that the shell still answers "opendir failed, Permission denied" while I'm uid/gid 0 (root).
I will continue to investigate, notably regarding SELinux which may enforce rules I'm not aware of, but would also greatly appreciate anyone who could put some light on this issue. At least for me it's an issue, as I don't understand what's happening.
Click to expand...
Click to collapse
Chainfire is probably the best person to comment on Android SELinux matters. If you look through his old G+ posts you may be able to determine which restrictions apply to your security context.
Do you see any denials logged in dmesg? (Or is that inaccessible too?)
If there is a /selinux/enforce file, does it read back '0' or '1'?
Thank you for your answer.
cernekee said:
Note that making a setuid shell executable might not be 100% reliable. When I've tried this with bash, it quickly realizes that getuid() != geteuid(), and drops the root permission.
I don't see this happening in your logs, but it's something to watch out for. Typically I've just used simple wrapper programs like the attached file to guarantee that the real/effective/saved UIDs are 0/0/0.
Click to expand...
Click to collapse
I've looked at your attached source, the main difference with my own wrapper is that you fork the process, I've tried also, behavior is the same. But, after reading your comment, I've modified my setuid/execve code, to make it more verbose about the real/effective/saved UIDs (using getresuid()).
Code:
[email protected]_umts:/ $ test_su
Initial UIDs
ruid: 2000
[B]euid: 0[/B]
suid: 0
Setting UIDs ...
New UIDs
[B]ruid: 0
[/B]euid: 0
suid: 0
[email protected]_umts:/ # ls /data/
[I]opendir failed, Permission denied[/I]
1|[email protected]_umts:/ #
It clearly appears that, POSIX speaking, all go fine until the "Permission denied" error:
the effective uid is already 0 (just after the "adb shell" command), which is expected and documented, as the content of my /default.prop prevents the shell to revert its effective uid to its real one, which would then be 2000 (shell)
after the setuid(0) call, the real uid is successfully set to 0, as expected, because the suid bit is set AND we were already privileged (if not privileged, setuid() should only change the effective uid, as for "man 2 setuid")
after execve(..), the whole prompt, "[email protected]_umts:/ #", again confirms the real uid is 0 (root)
Chainfire is probably the best person to comment on Android SELinux matters. If you look through his old G+ posts you may be able to determine which restrictions apply to your security context.
Click to expand...
Click to collapse
Yes, I definitely need to dig into the SELinux/Android stuff (see bellow), and will try to find the Chainfire posts you propose.
Do you see any denials logged in dmesg? (Or is that inaccessible too?)
If there is a /selinux/enforce file, does it read back '0' or '1'?
Click to expand...
Click to collapse
Neither dmseg (which is accessible) nor logcat shows any related error or warning.
I haven't any /selinux/enforce file, but it clearly appears from information bellow that SELinux is activated and enforced:
Code:
[email protected]_umts:/ $ getenforce
[B]Enforcing[/B]
[email protected]_umts:/ # setenforce 0
setenforce: Could not set enforcing status: Permission denied
[email protected]_umts:/ $ cat seapp_contexts
isSystemServer=true domain=system
user=system domain=system_app type=system_data_file
user=bluetooth domain=bluetooth type=bluetooth_data_file
user=nfc domain=nfc type=nfc_data_file
user=radio domain=radio type=radio_data_file
user=_app domain=untrusted_app type=app_data_file levelFrom=none
user=_app seinfo=platform domain=platform_app type=platform_app_data_file
user=_app seinfo=shared domain=shared_app type=platform_app_data_file
user=_app seinfo=media domain=media_app type=platform_app_data_file
user=_app seinfo=release domain=release_app type=platform_app_data_file
user=_isolated domain=isolated_app
user=shell domain=shell type=shell_data_file
user=log domain=log_app type=system_data_file
user=sprint_extension domain=carrier_ext type=platform_app_data_file
user=smartcard domain=smartcard type=smartcard_data_file
I'm a noob at SELinux, and I may be wrong, but I think a rule policy could prevent a user, being it root, to achieve certain actions. I need to read stuff about this.
The initial boot image that I modify (just add my suid shell /sbin/test_su) is the 4.4.2 one from sbf, and I expand/repack it using standard un*x tools (gunzip,cpio,...) and abootimg. Anything wrong with that ?
I build the C files using:
Code:
$ echo $CC
<android-ndk>/toolchains/arm-linux-androideabi-4.8/prebuilt/linux-x86_64/bin/arm-linux-androideabi-gcc --sysroot=<android-ndk>/platforms/android-19/arch-arm
$ $CC -o test_su test_su.c
Should I use particular flags for gcc, to make it produce SELinux aware object files ?
[EDIT: stupid question, answer is no]
Again, thanks for your help and ideas.
Just for information (for thus who are as dumb as I am): acquiring uid=(euid=suid=)0 is of little or no help within a user application, you're (obviously) still constrained by capabilities you can't acquire unless involving some kind of exploit.
To get a shell that's not restricted by the SE policies (on the 4.4 branch), the main way seems to have somewhat a system daemon capable to spawn /system/bin/sh with appropriate privileges/capabilities upon su client requests: so you again need an exploit.
So, for my understanding, starting with KitKat you can't anymore get a useful adb root shell through the uid=0 thing (traditional su), you have either to flash a custom rom or involve an exploit.
Hello Everyone!
I have spent the last 4 full days trying to fix device and every road I go down leads to a dead end. At this point my frustration and exhaustion has got to the point where I am afraid to proceed for fear I will destroy my phone making the whole ordeal pointless. I will spare you all the details as they are comical at this point and try to provide only the basic information. I used the nexus 5 root kit to gain root access in order to repair an issue with my phone and this is what root checker pro said...
Congratulations! You have root access!
Super User Application Status:
SuperSU application - version 2.02 - is installed!
System File Properties for Root Access:
Standard Location
Check Command: ls -l /system/bin/su:
Result: /system/bin/su: No such file or directory
Analysis: File /system/bin/su does not exist.
Standard Location
Check Command: ls -l /system/xbin/su:
Result: -rwxr-xr-x root root 125424 1970-01-05 10:08 su
Analysis: Setuid attribute is not present BUT root user ownership is present. Root access IS correctly configured for this file! Executing this file can grant root access!
Alternative Location
Check Command: ls -l /sbin/su:
Result: /sbin/su: Permission denied
Analysis: File system permissions restricted and denied access.
Alternative Location
Check Command: ls -l /system/xbin/sudo:
Result: /system/xbin/sudo: No such file or directory
Analysis: File /system/xbin/sudo does not exist.
Root User ID and Group ID Status:
Root user id:
uid=0(root)
Root group id:
gid=0(root)
System Environment PATH: /sbin /vendor/bin /system/sbin /system/bin /system/xbin
ADB Shell Default User:
ADB shell setting for standard access, stored in default.prop, is configured as: shell (non root) user - ro.secure=1
Results provided on your Nexus 5 - Android 4.4.4 device by Root Checker Pro version 1.3.7 from joeykrim in the Android Market
If someone could provide me with instructions on how to proceed I would be eternally grateful, I have become a wash in all the information out there as well as paralyzed by it. Even better if anyone has a spare few moments having a skype buddy there while I execute the instructions would be so very comforting although I realize people have better things to do with their time.
The one good thing to come of this is I now have a keen interest in Android development and look forward to finding and taking classes so in future I am not such a lost fool.
Very grateful for any help offered,
Garrett
[email protected]
Skype ID: thisguyto
1. using fastboot, unlock your bootloader. if its unlocked, ignore this step.
2. flash a custom recovery via fastboot.
3. flash SuperSU via your custom recovery.
4. boot up with root.
no root toolkit needed.
or, read the stickie threads here on xda to get detailed instructions http://forum.xda-developers.com/goo...urce-guides-info-threads-linked-read-t2784527
What is toybox?
Toybox combines many common Linux command line utilities together into a single BSD-licensed executable. It's simple, small, fast, and reasonably standards-compliant.
Toybox's main goal is to make Android self-hosting by improving Android's command line utilities so it can build an installable Android Open Source Project image entirely from source under a stock Android system. After a talk at the 2013 Embedded Linux Conference explaining this plan (outline, video), Google merged toybox into AOSP and began shipping toybox in Android Mashmallow.
Toybox aims to provide one quarter of a theoretical "minimal native development environment", which is the simplest Linux system capable of rebuilding itself from source code and then building Linux From Scratch and the Android Open Source Project under the result. In theory, this should only require four packages:
1) Set of posix-ish command line utilities
2) Compiler
3) C library
4) Kernel.
This provides a reproducible and auditable base system, which with the addition of a few conveniences (vi, top, shell command line history...) can provide a usable interactive experience rather than just a headless build server.
Why is toybox?
The 2015 toybox talk starts with links to three previous talks on the history and motivation of the project: "Why Toybox", "Why Public Domain", and "Why did I do Aboriginal Linux (which led me here)?". If you're really bored, there's even a half-finished a history page.
The toybox maintainer's earlier minimal self-hosting system project, Aboriginal Linux, got its minimal native development environment down to seven packages in its 1.0 release (busybox, uClibc, gcc, binutils, make, bash, and linux) and built Linux From Scratch under the result. That project was the reason toybox's maintainer became busybox maintainer, having done so much work to extend busybox to replace all the gnu tools in a Linux From Scratch build that the previous maintainer handed over the project (to spend more time on buildroot).
Despite the maintainer's history with busybox, toybox is a fresh from-scratch implementation under an android-compatible license. Busybox predates Android, but has never shipped with Android due to the license. As long as we're starting over anyway, we can do a better job.
These days, toybox is replacing busybox in Aboriginal Linux one command at a time, and each toybox release is regression tested by building Aboriginal Linux with it, then building Linux From Scratch under the result with the new toybox commands. The list of commands remaining is tracked in the roadmap, and the replacing busybox in Aboriginal Linux is one of the main goals for toybox' 1.0 release.
Building LFS requres fewer commands than building AOSP, which has a lot more build prerequisites. In theory some of those can be built from source as external packages (we're clearly not including our own java implementation), but some early prerequisites may need to be added to bootstrap AOSP far enough to build them (such as a read-only version of "git": how does repo download the AOSP source otherwise?)
Source: http://www.landley.net/toybox/about.html
Downloads:
http://www.landley.net/toybox/bin/
GitHub:
https://github.com/landley/toybox
In case
Busybox vs toybox, who's the best?
Armv7 build?
Inviato dal mio Nexus 4 con Tapatalk 2
Waiting armv7 build. Thanks
Very interesting project!!:good: I've been doing as much of my development that I can on Android, but this will be a way to keep it all localized! This is exactly what we need:victory:. Great development!!:good::highfive:
What's the time frame for a Armv7 build? (no rush, just anxious with anticipation)
Can anyone suggest me which one to download for moto x play
hello i have toybox on my marshmallow(low end device) , i want to how to make swapfile on the SD card(VRAM),(RAM runout fast) all apps for VRAM use busybox so they wont work
so ive tried ot use terminal shell with "swapon" but i guess i missing something, i searched all over the net didnt found to much on toybox
what command\string i need?
sorry if i am on the wrong thread and sorry for my bad English
PS
i can adjust my ZRAM but its zram its swapfile on the RAM also its limited to 0-200MB and i need more
thanks
I obtain this toybox from my Xperia m, cm 13 rom, from this path /sbin/toybox and this is for armv7 arch.
https://mega.nz/#!toURVICL!M7048C6RhYlhuZcoxXzvF5Zm7ALvZIql93asmysJas0
Any updates for this?
Sent from my ? LG G4 H811 ???
Deleted
ToyBox:
https://forum.xda-developers.com/android/software-hacking/tool-official-toybox-android-t3290884
BusyBox + ToyBox:
https://forum.xda-developers.com/an...zip-busybox-v1-26-2-flashable-binary-t3581875
download modif, BB 1.28.3, TB Armv7 build:
https://drive.google.com/file/d/1jM4CMB3sF_wRvUaLv5n8hVkLA65glbZj/view?usp=drivesdk
use Terminal Emulator:
typing: busybox (enter)
typing: toybox (enter)
@Paget96
toybox does not require a separate dev developed binary for android devices like busybox does?
like meefik, stericson, osm0sis ones....!
Edit:- answer is here https://github.com/landley/toybox/issues/122
HemanthJabalpuri said:
@Paget96
toybox does not require a separate dev developed binary for android devices like busybox does?
like meefik, stericson, osm0sis ones....!
Click to expand...
Click to collapse
Nope
Sent from my WAS-LX1 using Tapatalk
usage is sometimes different between toybox and busybox. since twrp has started replacing busybox with toybox some scripts won't work properly anymore. this mean sometimes it is necessary to port flashable zip (for example when awk is used). for those who want to test shell scripts on pc i share my little wrapper shell script for quick testing applets syntax
Code:
acpi arch ascii base64 basename blkid blockdev bunzip2 bzcat cal cat
catv chattr chgrp chmod chown chroot chrt chvt cksum clear cmp comm
count cp cpio crc32 cut date devmem df dirname dmesg dnsdomainname
dos2unix du echo egrep eject env expand factor fallocate false fgrep
file find flock fmt free freeramdisk fsfreeze fstype fsync ftpget
ftpput getconf grep groups gunzip halt head help hexedit hostname
hwclock i2cdetect i2cdump i2cget i2cset iconv id ifconfig inotifyd
insmod install ionice iorenice iotop kill killall killall5 link ln
logger login logname losetup ls lsattr lsmod lspci lsusb makedevs
mcookie md5sum microcom mix mkdir mkfifo mknod mkpasswd mkswap mktemp
modinfo mount mountpoint mv nbd-client nc netcat netstat nice nl nohup
nproc nsenter od oneit partprobe passwd paste patch pgrep pidof ping
ping6 pivot_root pkill pmap poweroff printenv printf prlimit ps pwd
pwdx readahead readlink realpath reboot renice reset rev rfkill rm
rmdir rmmod sed seq setfattr setsid sha1sum shred sleep sntp sort
split stat strings su swapoff swapon switch_root sync sysctl tac tail
tar taskset tee test time timeout top touch true truncate tty tunctl
ulimit umount uname uniq unix2dos unlink unshare uptime usleep uudecode
uuencode uuidgen vconfig vmstat w watch wc which who whoami xargs
xxd yes zcat
Do you plan to add dd and gzip?
Painfully they are missing.
posix [dd] Partially implemented
lsb <gzip> Not started yet
http://www.landley.net/toybox/status.html
Very usefult. It helps me.
Thank you very much
I have two Xiaomi phones with A11.
Both have /sytem/bin/toybox installed
Is it common that toybox is pre-installed by default?