Archive for the ‘linux tips’ Category

Freeing up resources for use by GNU/Linux on your android device

December 7, 2014 1 comment

I had an old samsung galaxy 3(GT-15801) which was lying around unused with a broken screen and decided why not install GNU/Linux on it. If raspberry pi can run raspbian well, then this phone could try to do as well. Have a look at my earlier post here on how I installed debian wheezy on it. While I was able to install and run debian successfully, this phone has only 256 MB of RAM and android uses most of it, there was only 4-6 MB that was free at any time. I removed all the extra apps from installed play store and some bloatware installed on the system partition and kept only the essential ones in case I need it later.

But android always makes use of all the available free memory to make apps open faster and I’m only going use debian on it. I connect remotely to debian on the phone using ssh. But simply killing the running android system processes wont work as android will restart them immediately.

My guide builds on the one used here :

Remember these commands must be run on an adb shell and not to be typed directly on your android device.

Get root on your android device and issue,

stop zygote   #or just stop

This stops the zygote and system server process from running and will not be restarted again automatically. Now if you check the available RAM in your device, you can see more that 50% of it is free. As there is no android’s virtual machine running none of the android apps will run and you will not be able use your device physically. If you still need more memory you can just use the stop command to free up other unused system processes.

To restart it if your want to use android back on the device, just use

start zygote #or just start

In general, issue ps command and look for processes that have its PPID (parent process id) as 1, which means that these processes are started by init as a service. you can get service name for this processes from /init.rc file on android and use stop command to prevent it from running.

Let’s take a look at how to stop mediaserver process for an example.

Filter the output of ps command to look for processes with parent process id 1. Below is the output from my phone, when i grep the ps output to get processes having id 1.

# ps | grep ” 1 ”
root      1     0     272    248   c030f5dc 0000ef8c S /init
system    2164  1     176    116   c050be58 0001264c S /system/bin/akmd2
shell     2165  1     680    316   c03fc378 afd0da1c S /system/bin/sh
system    2166  1     752    296   c0510ed4 afd0dcbc S /system/bin/servicemanager
root      2167  1     3688   580   ffffffff afd0e35c S /system/bin/vold
system    2168  1     1852   336   ffffffff afd0e35c S /system/bin/notified_event
root      2169  1     3672   552   ffffffff afd0e35c S /system/bin/netd
root      2170  1     628    308   c0559cec afd0e67c S /system/bin/debuggerd
system    2172  1     8764   868   ffffffff afd0e67c S /system/bin/drexe
system    2173  1     1036   348   c0292b1c afd0eca8 S /system/bin/npsmobex
media     2175  1     50960  7276  ffffffff afd0dcbc S /system/bin/mediaserver
bluetooth 2179  1     1208   720   c030f5dc afd0eb2c S /system/bin/dbus-daemon
root      2181  1     756    320   c05eba1c afd0da1c S /system/bin/installd
keystore  2182  1     1560   404   c0559cec afd0e67c S /system/bin/keystore
shell     2183  1     3308   176   ffffffff 0000ecd4 S /sbin/adbd
shell     2199  1     308    128   c030f5dc 0000fffc S /system/bin/immvibed
radio     2298  1     14480  2172  ffffffff afd0e35c S /system/bin/rild
root      4282  1     6120   1040  c030f5dc 40419364 S /usr/sbin/sshd
wifi      4333  1     2300   1340  c030f5dc afd0dde4 S /system/bin/wpa_supplicant
root      7823  1     122864 28164 c030f5dc afd0dde4 S zygote
dhcp      9231  1     800    404   c030f5dc afd0eb2c S /system/bin/dhcpcd

From the above output, to stop /system/bin/mediaserver we have to find the service name for the process used by android. To find it, look for the process name in /init.rc file used by init process.

# grep “/system/bin/mediaserver” /init.rc
service media /system/bin/mediaserver

This is my output, when i look for the process mediaserver in /init.rc file. The service name for the process is the second word of the output which is media here. Now to stop mediaserver process just use,

stop media

In general to stop an android service use the format,

stop <servicce-name>

This will stop the service from running. If you need to start a stopped service use the format,

start <service name>

This way more than 60-70 % of RAM can be made available for use by your debian or ubuntu or any other GNU/Linux installed on android and android will not get in your way.

One important thing to note is that if your root access is controlled by an android app like Superuser or SuperSU, to notify or to get permission from user for root access, once zygote is stopped and you exit as root on your shell, you’ll not be able to gain root again without restarting the device, as you stopped the android runtime and your su will fail with segmentation fault without the controlling app running.


Installing Debian wheezy on android (chroot method)

December 7, 2014 4 comments

This is a yet another guide on how to install Debian GNU/Linux on your android phone. While there are huge number of resources available on the Internet dedicated on how to install GNU/Linux to your android phone, this guide aims to show how to do it step by step manually without the use of any additional android applications and tools.

Before we begin, there are some prerequisites that should be met to install GNU/Linux on your android device,

  • Root access to your android device and busybox installed.
  • Your android’s Linux kernel should support loop devices and one of etx2/3/4 filesystems
  • A system running Debian GNU/Linux

If these prerequisites are met, then let’s get down to our first step, which is creating a chroot image.

Note: commands which required to be run as root are prefixed with sudo.

Debian has a tool called debootstrap which automates the process of creating a base debian system which can be chrooted into. Install debootstrap if you don’t have it installed already.

sudo apt-get install debootstrap

Now run debootstrap in terminal with the following arguments,

sudo debootstrap –arch armel –foreign wheezy ./wheezy

Note: Issue with WordPress fonts makes double dashes appear as single dash. single dash which appears before arch and foreign needs to be replaced with double dash

As we are creating a Debian system for a different architecture than an x86 system in which debootstrap is run, –arch armel argument is used to instruct debootstrap to create debian base system for arm architecture. –foreign instructs it to do initial unpack only, a second stage install is done on the actual hardware. wheezy instructs it to create a wheezy system. Replace with any other name like squeeze or jessie or testing or stable to create an appropriate system image. ./wheezy tells it to download the packages to directory named wheezy in the current directory from where debootstrap is run. And finally a repository url to fetch the packages from. You can use your local repository here, but make sure it has packages for the architecture armel. See man page of debootstrap if you need more information.

While this process runs let’s create an image file to hold the Debian system. I prefer to use an image file instead of creating an dedicated partition on the sdcard, as this way its portable and can be resized later easily when you need more space. To create an image file with size 1GB run the following command,

dd if=/dev/zero of=./linux.img bs=1M count=1024

If you need any other size replace count with appropriate value. Any size can be used according to the free space on your android’s sdcard, but a minimun of 1GB is recommended.Once it completes a file named linux.img with specified size is in the current directory.

Before creating a file system on this file, check what ext filesystem your android’s Linux kernel supports by running the following command in your android terminal.

grep ext /proc/filesystems

My phone’s kernel supports only ext2, so I’m creating an ext2 filesystem on this image file.

sudo mkfs.ext2 linux.img

Once filesystem is created, this image file can be mounted anywhere on the system, like an ordinary disk drive. I’m creating a directory named tmpmntpnt under tmp and for mounting this image file,

mkdir /tmp/tmpmntpnt

sudo mount -o loop linux.img /tmp/tmpmntpnt/

After this is done, check whether the debootstrap has completed successfully. If it is complete, copy the files under wheezy directory created by debootstrap to this linux.img mounted under /tmp/tmpmntpnt/ using,

cp -rp ./wheezy/* /tmp/tmpmntpnt/

-rp is used to recursively copy the files and preserving the files ownership and permissions. Once the files are copied, unmount the image using the command,

sudo umount /tmp/tmpmntpnt

Now the first step which is creating a chroot image is complete.

Before moving on to the second step, copy the linux.img just created to your android’s sdcard.

Moving on to second step, preparing your android device and mounting the image.

There is a lot of typing that needs to be done on the android device, so its preferable you use adb shell to type commands from your workstation to android device instead typing it directly in the device. Install android-tools-adb in debian which enables us to connect to android device over usb.

sudo apt-get install android-tools-adb

While installation is going on, enable android usb debugging in your android device settings under developer tools menu and connect the device to your workstation using usb cable and after adb-tools is installed,run

adb shell

to connect to your android shell. Once it connects and shows the $ prompt issue su command to get root. All the commands below needs to be run as root in your android shell.

Sdcards in android are mounted with nodev,noexec and nosuid. As we’ll be bind mounting device files and executing binaries with suid root, we’ll need to remount sdcard as,

busybox mount -o remount,exec,dev,suid /sdcard

Then, create a loop device to mount our linux.img,


mknod /dev/block/loop$loopno b 7 $loopno

This creates a block device with major number 7, minor number 254. These numbers are chosen by looking at the existing loop devices created by android os in my phone by running,

ls -l /dev/block/loop*

brw——- root     root       7,   0 2014-12-06 16:50 loop0
brw——- root     root       7,   1 2014-12-06 16:50 loop1
brw——- root     root       7,   2 2014-12-06 16:50 loop2

My android creates loop devices with major number 7 with incrementing minor numbers. You just have to choose the same major number and a minor number thats not yet used. As you install more apps to sdcard, it’ll create loop device for each of them, to prevent conflict I used 254, which is unlikely to be used any time soon. You can just use the same numbers I used without looking for all this stuff if you are not interested.

Once the loop device is created, associate our linux.img to this loop device using,

losetup /dev/block/loop$loopno /sdcard/linux.img

Now to mount it, create a directory under /data/local


mkdir $mntpt

Then mount the loop device to this directory,

busybox mount -t ext2 -o relatime /dev/block/loop$loopno $mntpt

Take care to replace ext2 with the filesystem you used for the linux.img.

This completes the second step.

Moving on to the third step, which is completing second-stage installation and setting up debian system.

Once the image has been mounted, bind the kernel directories from your android to debian using,

for f in dev dev/pts proc sys ; do mount -o bind /$f $mntpt/$f ; done

This above step bind mount /dev /dev/pts/ /proc/ /sys to debian image, which means that it will be available to both android and debian and changes made from debian to any of the files in these directories will reflect in android and vice versa. These directories are required for the proper functioning of debian.

You can also optionally bind mount your sdcard to make it accessible under debian by using,

sdcard=$(readlink -f /sdcard)

mkdir $mntpt/media/sdcard

mount -o bind $sdcard $mntpt/media/sdcard

This will make files in sdcard available to both debian and android.

Now our debian system is ready to be chrooted into. Before doing that we’ll need to set some environment variables, so that the binaries in debian work properly. If this not set up correctly, debootstrap will fail to run.

export PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:$PATH
export HOME=/root

Then setup /etc/resolv.conf file to enable dns resolution so that external addresses can be connected to,

echo “nameserver” > $mntpt/etc/resolv.conf
echo “nameserver” >> $mntpt/etc/resolv.conf

Now chroot into debian and complete the second stage installation,

chroot $mntpt /bin/bash -l
debootstrap/debootstrap --second-stage

This will take a while to complete. Once it completes, your debian system is ready 🙂

You can now use apt-get to install additional binaries. Let’s take a look at how to install openssh-server to remotely connect to our debian system.

Before using apt-get, repository needs to configured in /etc/apt/sources.list, just as you would do on a normal debian system. To do this run,

echo “deb wheezy main contrib non-free” > /etc/apt/sources.list

Now refresh repository information and install openssh-server

apt-get update

apt-get install openssh-server

After this is complete don’t forget to set password for root using passwd command to remotely log in to. Then try connecting to your device by using ssh from your workstation.

ssh root@<ip address of your android device>

If you are able to connect successfully, then congrats, you have installed yourself a debian system on your android from scratch. To unmount the debian system logout from the debian environment and unmount the directories mounted above using umount command.

Automate this mount and unmount process by putting the commands inside a script and installing it under /system/bin, so that it’ll save you from typing the commands over and over.

A quick hacked up script to mount and log in to the debian system and unmount it.



sdcard=$(readlink -f /sdcard)

if [ “$arg” == “unmount” ] ; then
umount $mntpt/media/sdcard
for f in dev/pts dev proc sys ; do umount $mntpt/$f ; done
umount $mntpt
losetup -d $loopdev
rm $loopdev
exit 0;

mknod $loopdev b 7 $loopno
losetup $loopdev /sdcard/linux.img
busybox mount -t ext2 -o relatime $loopdev $mntpt
for f in dev dev/pts proc sys ; do mount -o bind /$f $mntpt/$f ; done
mount -o bind $sdcard $mntpt/media/sdcard
export HOME=/root
export USER=root
export TERM=screen
export PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:$PATH

chroot $mntpt /bin/bash -l

Save this script under /system/bin by mounting /system partition as rw and assign executable permissions to the script by

mount -o remount,rw $(mount | grep system | cut -d " " -f 1,2)
cp /sdcard/linux /system/bin/linux
chmod 755 /system/bin/linux
mount -o remount,ro $(mount | grep system | cut -d " " -f 1,2)

From now on, you’ll be able to login to debian by just using linux and unmount it by issuing linux umount from android shell.
Update: to free memory used by android and make it available to Debian see

Sourcing a shell script in bash

March 9, 2014 Leave a comment

When a script is called using “.” or “source” command, then a script is said to be sourced. There are different ways of sourcing a script which are given below:

source script-name


. script-name

The difference between executing a script normally and sourcing a script is that, when a script is normally executed, a new shell is created and commands inside the script are executed in the new shell. The environment variables of the parent process are made available to the child process, but the local variables are not.

But when a script is sourced, the commands of the sourced script are executed in the same shell as the script from which it is called. And therefore all the local variables of the parent script is available to the sourced script. It is typically executed as if the contents of the sourced script are the contents of the parent script.

Generally scripts are sourced, when the variables of a script is required to be used inside another script, so that each of the variables which are required do not have to exported to be made available inside the sourced script.

Lets verify this with simple proof of concept.

Write a script as given below, which will be used to invoke the other script in different ways.

echo “In caller script”
echo “$0″


export BLOG=”$BLOG”

echo “BLOG=$BLOG”

ps -o pid,ppid,cmd | grep -v “ps”

echo “————————————”
echo “Inside directly called script”

echo “————————————”
echo “Inside sourced script”
. ./

echo “————————————”
echo “Back in the caller script”
exit 0

Here is the caller script, we have defined two variables, BLOG and PLATFORM. variable BLOG is also exported using the “export” command, then the contents of variables are displayed and then there is ps command executed to display the processes currently running in the terminal from which it is called. Output of ps command is formatted such that it displays process id, parent process id and the name of the process. Then we have a child script “” which is normally called and then the same script is called again, but this time it is sourced.

Now lets define the contents of the called script.

echo $0
echo “BLOG=$BLOG”

ps -o pid,ppid,cmd | grep -v “ps”
exit 0

Inside called script we display the value of variables BLOG and PLATFORM, which is not defined in this script. and then we have a ps command, which is the same one as used in the caller script. By default ps command also prints the process details of itself, so to reduce the clutter of output we ignore the information about ps command itself, by piping it to grep. Then we have an exit command at the end of script.

Now as we have contents of both caller script and called script in place, let’s execute the script and look at the output. When the caller script is executed from the terminal, this is the output we get:

In caller script
4291  2884 bash
16158  4291 /bin/bash ./
Inside directly called script
4291  2884 bash
16158  4291 /bin/bash ./
16161 16158 /bin/bash ./
Inside sourced script
4291  2884 bash
16158  4291 /bin/bash ./

Now let’s analyze the output of the scripts. output:

  • First the display statements in the caller scripts are executed and it is as expected.
  • Then the ps command output has two lines, which shows the process currently executing in the terminal from which the script was called, first line is the bash shell with process id “4291”, which is executed when a terminal is opened. Next line shows the process id of the caller script “16158” and the command name of the process.

output of when directly executed:

  • Next the display statements of script output which is called normally shows variable BLOG has a value, because BLOG is exported in the script and as this is the child process of script, it is made available here, but PLATFORM variable is not, because this runs as an independent child process.
  • ps command output of the directly called script shows that the is indeed the parent process of script.

output of when sourced:

  • Next the display statements of called script which is sourced shows that, command name of script is same as that script(output of “echo $0”). Then the variables both has a value, even as the PLATFORM variable is not exported. As a new bash shell is not created this time and these variables become local to
  • finally ps command output proves that there is no new process created this time, when is sourced.
  • Also, it is important to note that the display statements “Back in the caller script” is not printed as “exit 0” is given in When that statement is executed in the script is exited as well, because both and runs under same process and this does not happen when it is called normally.

Hope this example is useful in understanding the concept of sourcing shell scripts.

Fix Touchpad tap to click not working on Linux mint 16 petra

January 18, 2014 Leave a comment

Touchpad tap to click is by default disabled on Linux mint 16 and you can easily enable it by going to System settings -> Mouse and touchpad -> Touchpad  and selecting “Enable mouseclicks with touchpad”. This is fairly straight forward.

enable touchpad tap to click

enable touchpad tap to click

However, for some people who have upgraded from older versions of Linux mint instead of doing a fresh clean install of Mint 16, they might have two versions of system settings installed, like shown below.

Screenshot from 2014-01-18 12:35:53

Both are different system settings application and not displayed twice due to some menu configuration error, it’ll become obvious once you open both side by side.The fact that both applications have the same name and icon is very deceptive for the normal eyes.You might have used both applications but you might be unaware of this fact, unless you look for it. Here, is a screenshot showing both opened side by side.

screenshot showing a comparison of gnome system settings and cinnamon system settings side by side

comparison of gnome system settings and cinnamon system settings

Applicaion window open in the right is Gnome settings application and any changes you make through here is not of any use, unless you are running Gnome desktop. Window shown in the right is the cinnamon system settings application and this is where you have to make your changes if are running default Linux Mint Cinnamon desktop.

Here is a comparison of how touchpad settings looks in both Gnome and Cinnamon settings applications.

comparison of cinnamon and gnome touchpad settings

Cinnamon system settings is easily distinguishable from Gnome settings by the fact they have a “switch to advanced/normal mode” link at the bottom of the application screen. Finally, the link has found some way of being actually useful 😉

gnome-control-centre is the application responsible for Gnome system settings, it has a lot of dependent applications, that removing the application will mess with your system, unless you know what  you are doing. So, if you are not absolutely sure what you are doing, I’ll ask you to not remove it.

Tip for the day – Fix your terminal displaying junk characters

August 24, 2013 Leave a comment

Sometimes when reading a binary file your terminal font may be set to junk values and whatever you type will appear as junk. This may happen when reading a binary file through cat command, opening the raw device files like /dev/random /dev/urandom, or reading  /proc/kcore memory file. Below screen shot shows how terminal looks when this happens,

Terminal displaying all characters as garbage after reading a binary fileWhen you are working in GUI environment within a terminal emulator this may not be a problem as you can close and reopen a new terminal. But this is a problem when you’re working in text environment.

There is an easy way to fix this problem by resetting the terminal. Yes typing reset command in the terminal will reset your terminal back to normal state.

Easy way to fix script errors that occur when scheduled with cron

February 4, 2013 Leave a comment

Some scripts that work fine when run manually in a shell environment will just fail when scheduled with cron. This is due to shell environment variables not available to those scripts when cron executes the scripts. You can verify this by running env or printenv commands in both the shell in which you manually execute the script and in cron by schedule it to the nearest minute and writing it to a file.

# m h  dom mon dow   command
35 * * * * env > /tmp/env.log

By comparing both outputs you can find that the environment variables available in cron are very limited.

Most errors will arise due to commands in your script not available in location set by cron environment PATH variable. You can compare the value of PATH variable in both outputs and tell that the executable paths cron looks in is very limited. You can fix this by giving the full path to commands in your shell script, but you have to look for where the executables are located and modify all those scheduled scripts.

However there is one easy fix to this problem. The important thing to note is cron allows you to set environment variables in the crontab file. So you could just add the variables you wanted to be available to cron at the top of the crontab file as shown below.

# m h  dom mon dow   command
38 * * * * env > /tmp/env.log

Now schedule the script again and check the output of /tmp/env.log file. You can see that the values you passed were availabe to cron. By this way you can run those scripts just the way it is without any modifications.

configure battery power settings in Gnome

January 25, 2013 Leave a comment

Gnome desktop does not allow users to set the values for battery critical state, Power settings will only allow users to set what action is to be taken when the battery is critical. By default it is considered critical when battery backup time is  5 minutes and it will initiate battery critical action when backup time remaining is 2 minutes. This default behavior is questionable because 2 minutes will not be sufficient for all users to find a power source and as most batteries used today are lithium-ion batteries, their life will get significantly reduced by this default behavior when drained so low so often.

Fortunately, this can be changed in configuration editor. systems using older Gnome versions such as Gnome2 desktops had a tool called Gconf-editor to change these configuration settings. Newer Gnome versions such as systems using Gnome3 desktop use a tool called dconf-editor to make changes to these configuration settings.Install this tool by using below command from terminal

sudo apt-get install dconf-editor

After installing open dconf-editor and look for following path in the left pane



In the right pane look for the fields,




and change the time values for the fields according to your preferences.Note that the time is defined in seconds.

Description for the fields and the type of value it accepts will be available at the bottom pane, when you select the fields.

Alternatively, if you want your system to consider the battery percentage instead of remaining time, uncheck the key


and modify the keys




to your preference.Now your system should take the values you defined after the next boot or restart your system for the settings to take effect immediately.