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

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

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

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!