Thursday, December 29, 2016

Fingerprint Authentication on Ubuntu 16.04

Just for fun, I googled around about how to enable fingerprint login in my X201 with Ubuntu 16.04. And then I came across this super cool tool that let you not only login, but to 'sudo' using fingerprint! How cool is that? Goodbye typing password while thinkering around with system-privilege :)

Here's how you install it:
https://launchpad.net/~fingerprint/+archive/ubuntu/fingerprint-gui


Friday, December 2, 2016

Some Daemons are Not Automatically Started on Ubuntu 16.04

I had a crucial daemon to prevent my laptop from restarting, which is thinkfan (explained here):
http://www.antoniusdharijanto.com/2014/09/corner-cases-of-ubuntu-1404-on-lenovo.html

After upgrading to 16.04, the daemon is no longer started automatically. I noticed this because my laptop restarted itself due to overheating. And the reason is because Ubuntu 16.04 uses systemctl daemon manager as oppose to upstart that 14.04 earlier used.

Here's the solution:
1. Make sure thinkfan is upgraded to the latest (e.g. sudo apt-get update && sudo apt-get install thinkfan). Latest version has systemctl enabled for it.
2. Check if thinkfan can run: sudo systemctl start thinkfan.service
3. Enable the daemon if (2) succeeded: sudo systemctl enable thinkfan.service
Optional:
4. To get it to restart automatically upon crash:
Edit /etc/systemd/system/multi-user.target.wants/thinkfan.service and add 'Restart=always' under [Service] section.

P.S. I notice the same think with mysql daemon. Using the same command, systemctl is smart enough to redirect the command onto sysv that mysql is using.

Enjoy!


Source:
https://www.digitalocean.com/community/tutorials/how-to-configure-a-linux-service-to-start-automatically-after-a-crash-or-reboot-part-1-practical-examples

Thursday, December 1, 2016

Ubuntu 16.04 stucked on boot logo after an upgrade from 14.04

Yesterday I finally decided to let Ubuntu autoupgrade system update my 14.04 into 16.04. After some time, my laptop got really hot, which seems to be caused by some CPU-intensive operations of the upgrade. It got too hot until a point that the firmware decided to shut my laptop down forcefully. Crap! I'm in the middle of an update!

Yes, as you can already guess, my laptop now stucked on boot logo! What's even worse, the boot logo didn't even animate, which means it hung and I can't use emergency mode or tty2!

I almost thought I had to re-install the entire OS from scratch, which would have been much painful considering all the programming tools and libraries I've painstakingly installed throughout the past year! Fortunately, many people out there shared how they recovered their systems!

[SOLUTION]
There really are two things that need to be done:
1. Complete the unfinished upgrade
2. After (1), turned out my system still wouldn't boot, so need to diagnose and debug this.


1. Complete the unfinished upgrade
This can be done via "chroot"-ing onto the broken system via Live CD. For those unfamiliar, "chroot" is a mechanism to "get into" another Linux installation from a currently running one. In this case, the currently running is one from Live CD and the other one is mine that wouldn't boot. It's done as follow:

a. fdisk -l #Figure out the disk where your other Linux is installed
b. mount /mnt/ /dev/sdX #'/dev/sdX' would be from step (a)
c. for i in /sys /proc /run /dev /dev/pts; do sudo mount --bind "$i" "/mnt$i"; done # This is so the chroot-ed system has access to current Linux's hardware nodes that are necessary, for example for internet connection
d. sudo chroot /mnt/ #After this, you're shell is under the other Linux!

It's time to complete/fix the upgrade that has been halted.
a. sudo apt-get update # Update the list of cached components
b. sudo apt-get upgrade # Upgrade the system


2. After (1), turned out my system still wouldn't boot, so need to diagnose and debug this.
For me, there's still a problem that causes my Linux to get stuck on boot loop. After a while, the system got into emergency mode, where there's an option to go into root shell to do something. 

On the emergency mode:
1. journalctl
The shell immediately prompted me to run this command, so I did and found out the culprit:
"timeout waiting for device dev-disk-by..... " and several line below that, it seems that the failure is due to the system trying to mount /dev/disk/by-uuid/XXX that didn't exist. Turned out this was the path to my Windows partition, which changed after an upgrade to 16.04


2. vim /etc/fstab
I commented out the line that tried to mount the no-longer-existing path. And voilla! It worked like a charm!

Credit: 
http://www.webupd8.org/2014/01/how-to-fix-non-bootable-ubuntu-system.html
http://forums.debian.net/viewtopic.php?f=10&t=118828

Monday, October 3, 2016

Changing Device Permission Permanently through udev

Sooo, I've just bought a Raspberry PI for a project, along with a $5 webcam for a Computer Vision experiment. I immediately tried the quality of the camera using "cheese" Linux program on my Ubuntu laptop, and it worked out fine. Unfortunately, in Raspberry PI, the program simply wouldn't detect the camera.

After hours of debugging, apparently the problem was with permission. The webcam enumerates as /dev/video0, which has 0660. Since "cheese" runs as "other", it doesn't have the permission to read it. Manually modifying it through "chmod o+rw /dev/video0" does the job. However, I want a more permanent and elegant solution.

The solution is to use udev. Here're the steps:
1. Get the webcam's vendorId and productId through lsusb/dmesg.
2. Get its DRIVER and SUBSYSTEM (properties required for udev setting) through "udevadm info -a -n [device_path]" (device_path is sth like /dev/video0)
3. Create new rules as instructed here: https://wiki.archlinux.org/index.php/Udev#Video_devices
4. As a reference, in my case the rule file is created here: /etc/udev/rules.d/83-webcam.rules, with the content being: KERNEL=="video[0-9]*", SUBSYSTEM=="video4linux", SUBSYSTEMS=="usb", ATTRS{idVendor}=="05e3", ATTRS{idProduct}=="0510", SYMLINK+="video-cam1", MODE="0666"

What's bold is the part that specifies the permission.


Hope this helps!

Tuesday, December 1, 2015

Syncing Android Open Source Project Code Through Unreliable Connection

Since AOSP code is really big, there are multiple problems that can arise when syncing using slow and unreliable Internet connection. For this, the regular old "repo sync -j4" wouldn't work well.

So what are the issues?

1. Repo tries to download each of the branches available for each of the projects
This behavior is handy, but is undesired in a situation where Internet connection is slow.

To get repo to only sync the defined branch, use -c flag. For example repo sync -j4 -c

2. When a project failed to be downloaded, the whole sync is aborted.
You have been waiting for your sync for hours and suddenly your connection went down, and so the sync failed. You were hoping that you can just re-run the sync command again and continue where the it left off. Unfortunately, you found that the sync restarts!

To work around this, append "-f" to the repo command. This forces the sync to continue even if one or more projects fails.

3. Syncing with -f gets aborted because the computer is restarted or there is power outage.
Unfortunately, in this situation, repo doesn't partially download each of the projects. Even with -f flag, the projects would only be downloaded to the directory once it finishes fetching all the projects. In other words, when the sync is terminated abruptly, you'll have to restart it from the beginning!

To work around this, sync each of the projects individually using repo sync -j4 -c -f [project_name], where project_name can be found from the manifest file of interest.

I personally created a simple script to dump each of the paths that would be synced, and then did an xarg to sync each of them individually:

a. My scala script to dump each of the paths. I'm sure this can be done way way more efficiently using sed, but I'm just not familiar enough with it nor have the time to learn.

#!/bin/sh
exec scala "$0" "$@"
!#

import java.io.File;
import java.util.Scanner;
import java.util.List;
import java.util.ArrayList;

def getPath(s: Scanner) : List[String] = {
    val list : List[String] = new ArrayList[String]()

    def getPath(path : List[String], s : Scanner) : List[String] = {
        if (!s.hasNextLine) return path
        val line = s.nextLine
        if (line.contains("path=")) {
            val tmp = line.substring(line.indexOf("path=") + "path=".size)
            val tmp2 = tmp.substring(1, tmp.indexOf("\"", 1))
            if (!tmp2.equals("")) path.add(tmp2)
            return getPath(path, s)
        } else {
            return getPath(path, s)
        }
    }

    return getPath(list, s)
}

var f = new File("/home/aharijanto/tmp/cm12path.txt")
var s = new Scanner(f)
val l = getPath(s)
val it = l.iterator

while (it.hasNext) {
    println(it.next)
}

Save the script about as repopath.scala, and then run it like:
./repopath.scala > ~/tmp/path.txt

2. Go to the directory where repo is init-ed
cat ~/tmp/path.txt | xargs -I xxx sh -c 'echo xxx > ~/tmp/log.txt ; repo sync -j4 -c -f xxx'

This way, in case of the sync being aborted, you just need to check on the log file and continue from the project that failed.

Saturday, October 24, 2015

Understanding how Ubuntu Touch is forked out of AOSP

This post is meant for readers who have familiarity with AOSP building. As I just got my new Nexus 5 x, as a side project, I decided to try to port ubuntu-touch to my old phone: HTC One m7.

First of, Ubuntu touch is built on top of AOSP project. It's using a fork of Android kernel, frameworks, and build system. More precisely, the diagram below explains the architecture:

(note that I didn't draw the diagram, credit goes to Ubuntu's official page: https://developer.ubuntu.com/en/start/ubuntu-for-devices/porting-new-device/)

In the past, Ubuntu Touch project based the Android code they're using of Cyanogen's fork of AOSP (http://cyanogenmod.org), however they recently moved to pure AOSP version. To be precise, by the time of this writing, they're using version 4.4.2.r1. As for my device, since there's a Cyanogen support for it, I think ubuntu-touch can be ported with reasonable effort.

I think using AOSP instead of building the project from scratch is a really smart move. I can imagine that not only it will speed up their development process, but they may also benefit from improvements that Google are periodically making to the code. And the neat thing about AOSP code is that, the Java portion of it is pretty-well isolated from the the build system, making it a perfect fit for Ubuntu Touch that doesn't rely on Java.

Before we begin exploring the changes that Ubuntu Touch made atop of AOSP, I'd like to give a crash intro towards AOSP. First, it is built on top of a modified Linux kernel. Some substantial modifications that are worth to mention are wakelock-support and binder-IPC. The first provides userspace a way to prevent Linux to go to deep-sleep state or LP0. Unlike desktop, when a mobile device is put to sleep (e.g. power button is pressed), we may not want it go to deep-sleep right away. Sometimes we want the sleep to be delayed until a certain task is completed. (e.g. until a data synchronization is completed or until an email is sent). And for binder, it is a lightweight IPC mechanism that is used all over Android. It provides the needed security and flexibility that are expected by a mobile application. For example, when an IPC occurs, the caller identity can be retrieved, which in turns allows an application to see whether the caller has the appropriate permission required for the request. And in terms of flexibility, Google has build a very convenient userspace frameworks on top of its kernel driver implementation. This frameworks allows IPC communication between Java applications, native applications, and even Java-native applications. From my little observation so far, Ubuntu Touch seems to also rely on wakelock and binder.

Now, lets go back to the changes towards AOSP that Ubuntu Touch made. When Android kernel completes its initialization, it calls the very first process, init. This process then does all the userspace initialization, such as creating sysfs nodes and settings proper permissions, and kick-starting different daemons. What's necessary to know here is that init is the one that starts a Java virtual machine that Android heavily uses. init forks itself and runs zygote, which handles all Java-related stuffs. And as Ubuntu Touch does not use Java, a modification was made so zygote never runs. For more details, refer to the code under phablet/system/core. In particular, look for the following commit:

commit 1742098c17be31d968dce45a8eda4552602398c7
Author: Ricardo Salveti de Araujo <ricardo.salveti@canonical.com>
Date:   Fri Jan 10 03:06:09 2014 -0200

    init.rc: adding sensorservice and ubuntuappmanager
    
    Also removing some unused services.
    
    Change-Id: I7881bf436319ed09cbac46450c51710b6cf93c11
    Signed-off-by: Ricardo Salveti de Araujo <ricardo.salveti@canonical.com>

[To be continued...]

1. upstart -> ./ubuntu/upstart-property-watcher/upstart-property-watcher.c:78:#define
http://upstart.ubuntu.com/

2. 

Friday, October 23, 2015

CUDNN Benchmark Tools

I was trying to evaluate whether my embedded device, NVIDIA Shield TV, was capable of running a particular CNN learning algorithm in real-time. Instead of directly implementing the entire learning algorithm with the risk of not being able to meet the targeted performance, I decided to study the feasibility first by writing a benchmark tool. It runs forward convolutions with different configurable parameters (number of feature maps, batch size, filter size) and algorithm.

For those who are not familiar with CUDNN library, it supports different algorithms for running a forward convolution; some try to minimize GPU memory footprint, while some other focus on performance without worrying about memory-footprint. Perhaps the idea is to support different GPUs with different specifications (number of CUDA cores, memory size, etc), as well as different use-cases.

Sample output:
n, w, h, c, k, filter_dim, avg_time(us), max_time(us)
1, 3840, 2160, 1, 1, 3, 74383, 75142
1, 3840, 2160, 1, 1, 5, 88465, 88819
1, 3840, 2160, 1, 1, 9, 159752, 160324
Total time taken=322600 us.

Since the output is comma-separated, they can easily be parsed by spreadsheet processor. 

Check the code out here:
https://github.com/blacksoil/CUDNN-BenchmarkUtility