Using Ubuntu touch on a Nexus 5


Well, this is an interesting one. I decided to go ahead and dig through my old parts bin and came across my much loved Nexus 5 android phone. Since I had just recently went ahead and discovered that OpenWRT has RTL-SDR capabilities, I wondered whether I could achieve a similar feat on the Nexus 5. This became an interesting rabbit hole to go down. I have recently been using a Raspberry Pi 3 as a base-station for my RTL-SDR hobbies (capturing NOAA satellite passes, attempting to receive SSTV images from the International Space Station, listening to ADS-B traffic, decoding pager traffic, and decoding information on 433 MHz). It works quite well when it is within range of my home network, but away from there, it becomes a bit more tricky due to the lack of a real-time clock, my propensity for configuring everything through SSH, and not wanting the additional battery draw from a dedicated screen. The Nexus 5 has a screen, decent battery, ability to connect to USB devices using an OTG cable, and most importantly runs Android (This is where my opportunity starts).

Android is, in my opinion, a great mobile operating system. Unfortunately, for my needs it is too locked down since I enjoy running non-standard drivers and thoroughly enjoy a tool called AutoWX2 to capture satellites. AutoWX2 is a collection of python scripts that greatly simplifies capturing satellite passes, and in the downtime between passes, listens to other radio traffic. Keep in mind, all of the following steps will be using Linux to perform all of the commands referenced.

The first step in all of this is to get a full Linux system installed on the Nexus 5. This is accomplished easily enough with the UBPorts tool to install Ubuntu Touch available here. Following the on-screen directions will install Ubuntu Touch to the Nexus 5.

Next up, problem number 1. The root file system for Ubuntu Touch has a size of 2 GB, out of which 130 MB are available for additional software. Well, this presents an issue as the first time we “sudo apt update && sudo apt upgrade -y && sudo apt dist-upgrade -y” we fill this 130 MB with apt cache files and downloads, and then the phone stops attempting to install updates. This is even before we attempt to install Python, git, build-essential, and additional software required to get our all in one system running.

Looking through various forums provided possible options for getting a larger root partition, or failing that, Ubuntu Touch has Libertine available, which allows a sandboxed Linux environment. All of the options I attempted, rewriting the ubuntu.img or system.img (either should work as they are hard links pointing to the same inode) file to append additional data to the end and then resizing the filesystem afterwards failed. I was about to attempt installing the software through Libertine, when I had an epiphany. The file system is mounted on boot. With the file system mounted on boot, I cannot change the underlying system, and rebooting after changing it won’t help as on reboot, it still sees the ubuntu.img as 2GB although it shows as larger when using “ls -hl /userdata/ubuntu.img”. The necessary steps are to first install a recovery firmware that supports adb connections. For this I used TWRP. To install the recovery, reboot the phone to fastboot by holding volume down + power, and upon boot you should see the andoid. Once connected, navigate to where TWRP downloaded in terminal and issue “fastboot flash recovery twrp-3.3.0-0-hammerhead.img” changing the twrp part to match the version downloaded. Once the recovery is flashed, we can “Recovery Mode” by using the volume up/down keys to select that option, and using the power button to perform the reboot.

Once inside the recovery is loaded, we want to mount the partition of /dev/block/mmcblk0 that contains our file system. This is the point where we have to find out where the file system resides. First verify that the phone is recognized as an adb device using “adb devices”. If recognized, you will see List of devices attached, a hex number and recovery. You may need to disconnect and reconnect the USB cord a few times to have it recognized as an adb device. By default, the system/ubuntu image is accessible on a mounted partition located at /data/ . In order to get the image off the phone where we can modify it, we again rely on adb, this time using “adb pull /data/ubuntu.img ./” This will take a few minutes to transfer as the file is 2 GB and will be transferring by USB.

Once the transfer is complete, we can resize the image file using dd. To make the image approximately 6GB we use “dd if=/dev/null of=./ubuntu.img bs=1M seek=6000 count=0” to make the file larger or smaller, modify the seek parameter to be how many MB you want the image to be. Once this completes (should be extremely quick) run “ls -hl” to verify that the file is now resized.

Should look like this if using 6000

Next step is to check the filesystem using “e2fsck -p ./ubuntu.img”. Using the -p switch automatically fixes any errors found. Once the file check is complete, we need ensure the file system is informed about the changes. To do this we use “resize2fs ./ubuntu.img”. Once complete we then use adb to transfer the image back to the phone. This is accomplished with “adb push ./ubuntu.img /data/ubuntu.img”.

When the file has completed transferring we have one last thing to do. We need to recreate the hardlink from ubuntu.img to system.img. Connect to the phone using adb using “adb shell” and then “cd data”. If we “ls” here we should see the following.

Almost done\

Since we have destroyed the hardlink, we need to remove the system.img, and then recreate the hardlink. This is done with “rm system.img && ln ubuntu.img system.img”. This command first deletes the system.img file, and then recreates the file as a hardlink to ubuntu.img. This can be confirmed using “ls -lhi” which lists the files, sizes in human readable format, and lists the inode (where on the disk the file is stored).e2fsck -p /dev/sdb1

On my phone, the inode of both system.img and ubuntu.img is 15 (the first column) showing that both files are the same as they reside in the same location on the disk. Don’t worry that the size is misreported as it is a limitation of busybox. Upon reboot into the full Linux distro, it is reported correctly.

Once complete we can reboot the phone normally, set a passcode (needed to enable developer mode), and enable developer mode under the about section in settings. At this point, any software available in the repositories is available to be installed to your shiny Ubuntu phone!

After fussing with this setup for multiple days, I came to the realization that autowx2 will not run on the Nexus 5 due to a lack of 64-bit python to run pypredict, which relies on pyradiomics. If anyone has any suggestions on an alternative automated weather satellite and SSTV from the ISS receiver, please offer suggestions.

2 thoughts on “Using Ubuntu touch on a Nexus 5”

  1. Great guide. The directions on to run all of these commands on the device itself didn’t work for me but yours worked perfectly!

    One small typo: “adb pull /data/system.img ./” should be “adb pull /data/ubuntu.img ./” to fit with the rest of your guide.

    1. Great catch. Both files are exactly the same as they are referencing the same inode, but I should have double checked my work as it is confusing when the file randomly changes. Will be updated in the guide.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.