Converting a Ubuntu and Windows dual-boot installation to UEFI

UEFI is the successor to BIOS for communicating with the Firmware on your Mainboard.
While the first BIOS was released with the IBM-PC in 1981, the first UEFI version (EFI 2.0) was released 25 years later in 2006 building upon the lessons learned in that timespan. So UEFI is without any doubt the more modern solution.

The user-visible advantages of using UEFI instead of BIOS are

You could reinstall both Windows and Ubuntu to get UEFI. However it is also possible to convert existing installations of both on the fly – without the backup/ restore cycle. You should still do a backup in case something goes wrong though.

Prerequisites

Only the 64bit Versions of Windows support UEFI. Therefore this guide assumes that you run the 64bit versions of both Windows and Ubuntu.

Furthermore verify the following items before you continue – otherwise you will not be able to finish the conversion. Use GParted in case you have not enough space before the first or after the last partition.

  • 250MB space in front of first partition
    Typically Windows 8 creates a 350MB System Partition upon installation. This space can be reclaimed for a 100MB EFI partiton and a new 100MB Windows System partition.
  • 1-2MB behind last partiton (for the GPT backup)
  • UEFI bootable Ubuntu USB drive.
    You can use the startup disk creator on ubuntu with an Ubuntu 14.04+ ISO.
  • UEFI bootable Windows USB drive.
    You can use the Microsoft Media Creation tool for Windows 10 to get one.

to test that the sticks are indeed UEFI compatible, try booting them with CSM Mode disabled in your BIOS.

Convert the drive to GPT

UEFI requires a GUID Partition Table (GPT), so first we need to convert from MBR to GPT.

After this step you will not be able to boot your system any more. So make sure you have the Ubuntu USB drive ready.

We will use gdisk to perform the conversion as following:

sudo gdisk /dev/sdX
Command (? for help): w

where sdX is your system drive (e.g. sda)

Convert Windows to UEFI

Now boot your Windows USB drive and enter the command prompt as described in this Microsoft Technet article at step 6.

Continue with the following steps from the Article. Note that we have skipped steps 1-4 as we used Ubuntu to convert the disk to GPT.

We have now created a EFI partition, a new EFI compatible Windows System Partition and we have installed the Windows Bootloader to the EFI partition. Your Windows installation should now start again.
At this point you could also perform an upgrade to Windows 10, as the upgrade would erase grub from the EFI partition anyway.

Next we are going to install grub to the EFI partition and make it manage the boot.

Enter a Ubuntu chroot

As we can not directly boot our Ubuntu installation, we will instead boot from the Ubuntu USB drive and the switch to the installed Ubuntu.
To do the switch we have to setup and enter a chroot as following

sudo mount /dev/sdXY /mnt 
sudo mount /dev/sdX1 /mnt/boot/efi 
sudo mount -o bind /dev /mnt/dev
sudo mount -o bind /sys /mnt/sys
sudo mount -t proc /proc /mnt/proc
sudo cp /proc/mounts /mnt/etc/mtab
sudo cp /etc/resolv.conf /mnt/etc/resolv.conf
sudo chroot /mnt

where sdXY is the partition where your Ubuntu system is installed (e.g. sda5)

Convert Ubuntu to UEFI

Inside your Ubuntu Installation we have to replace grub for BIOS (aka grub-pc) with grub for UEFI (aka grub-efi) as:

sudo apt-get --reinstall install grub-common grub-efi-amd64 os-prober

this would be enough to get the system booting again, however we also aim for secure boot so we also need to install the following:

sudo apt-get install shim-signed grub-efi-amd64-signed linux-signed-generic

This installs signatures for grub and the kernel which are used to verify the integrity of these at boot. Furthermore we install shim, which is a passthrough bootloader that translates from the Microsoft signatures on you mainboard to the signatures by Canonical used to sign grub and the kernel (see this for details).

Next we finally install grub to the EFI partition by:

sudo grub-install --uefi-secure-boot /dev/sdX
sudo update-grub

where sdX is again your system drive (e.g. sda).

Now you can enable secure boot in your BIOS and benefit. Note that some BIOS implementations additionaly require you to select the trusted signatures. Look out for an option called “Install Default Secure Boot keys” or similar to select the Microsoft signatures.

State of the xpad Xbox Controller Driver

Since my last post regarding the Xbox 360 Wireless Controller on Ubuntu, I have spent quite some time digging through different version of the xpad driver and their issues.

The following issues are those I encountered with xpad upstream at the time I wrote the first post. Some of them are fixed by now,  while for others the fixes are pending – but lets start from the beginning..

However if all you want is a driver where the mentioned bugs are fixed

Continue reading State of the xpad Xbox Controller Driver

IcyBox IB-RD3620SU3: Impressions & Silence Mod

The IcyBox is a good  RAID case with USB3.0 support – however the stock fan is quite loud as it causes some vibrations.

The only bummer about it is the used JMB391 RAID chipset, which does not support RAID operation with drives larger than 8 TB.

Linux hint: if you want to read the SMART attributes of the drives (in single mode), use

sudo smartctl -d jmb39x,<strong>N</strong> -a /dev/sd<strong>X</strong>

Where N can be either 0 or 1, meaning drive in first or second bay.

Silencing the IcyBox

Next we will replace the stock fan with a Noiseblocker PR-1 BlackSilentPro Fan which is not only silent but also has a better cooling performance.

In order to perform the depicted steps you will need the following tools

  • soldering iron
  • shrink-on tube
  • diagonal cutter

Note however that as the height of the Noiseblocker is 25mm instead of the 10mm of the stock fan it will stand out from the case.

Updating Crucial MX100 Firmware with Ubuntu

There has been a Firmware update for the Crucial MX100 to MU02. In case you are running Ubuntu there is an easy way to perform the update without using a CD or USB Stick.

As the firmware comes in form of an iso image containing Tiny Core Linux, we can instruct grub2 to directly boot from it. Here is how:

  1. append the following to /etc/grub.d/40_custom:
    menuentry "MX100 FW Update" {
     set isofile="/home/<USERNAME>/Downloads/MX100_MU02_BOOTABLE_ALL_CAP.iso"
     # assuming your home is on /dev/sda3 ATTENTION: change this so it matches your setup
     loopback loop (hd0,msdos3)$isofile
     linux (loop)/boot/vmlinuz libata.allow_tpm=1 quiet base loglevel=3 waitusb=10 superuser rssd-fw-update rssd-fwdir=/opt/firmware rssd-model=MX100
     initrd (loop)/boot/core.gz
    }

    read this for details of the file format.

  2. run sudo update-grub
  3. reboot and select “MX100 FW Update”
  4. Now you can delete the menuentry created in step1

Note that this actually much “cleaner” than using windows where you have to download 150MB of the Crucial Store Executive Software which actually is a local webserver written in Java (urgh!). But all it can do is display some SMART monitoring information and automatically perform the above steps on windows.

Header Image CC-by MiNe

OpenGL Matrices – the missing bits

While generally the available documentation on how the OpenGL matrices work is quite good, there are some missing bits. Although not necessary for your everyday rendering, they give one some insight on how rasterization in general and OpenGL in special works.

W coordinate after perspective divide

After conversion to normalized device coordinates(ndc) by applying a matrix like

\begin{bmatrix}A & 0 & B & 0\\ 0 & C & D & 0\\ 0 & 0 & E & F\\ 0& 0 & -1 & 0\end{bmatrix} \begin{pmatrix} x \\ y \\ z \\ w \end{pmatrix}

one might think that projection is applied on each vertex looks like

\vec{v}_{ndc} = \frac{1}{w} \begin{pmatrix} x \\ y \\ z \\ w \end{pmatrix} = \begin{pmatrix} \tfrac{x}{w} \\ \tfrac{y}{w} \\ \tfrac{z}{w} \\ 1 \end{pmatrix}

however it actually looks like

\vec{v}_{ndc} = \begin{pmatrix} \tfrac{x}{w} \\ \tfrac{y}{w} \\ \tfrac{z}{w} \\ \tfrac{1}{w} \end{pmatrix}

the w coordinate is not divided by itself, but is inverted instead. This is done because the interpolation between vertices still needs to take place and for perspective correct interpolation one needs the camera space depth z = -w_{cam}.

\begin{aligned} \vec{v}_{\alpha} &= \frac{(1-\alpha) \tfrac{\vec{v}_0}{-z_0} + \alpha \tfrac{\vec{v}_1}{-z_1}}{(1 - \alpha)\tfrac{1}{-z_0} + \alpha \tfrac{1}{-z_1}} \\[1.5em] &= \frac{(1-\alpha)\vec{v}_0 w_{0_{ndc}} + \alpha\vec{v}_1 w_{1_{ndc}}}{(1-\alpha) w_{0_{ndc}} + \alpha w_{1_{ndc}}} \end{aligned}

instead of dividing by -z we can multiply with w_{ndc} as multiplication is faster than division.

Note that for brevity the given formula assumes a scanline based rasterizer as it interpolates only between two vertices. The general approach is to use barycentric coordinates to interpolate between all three vertices simultaneously.

Row major or column major

Even though even Wikipedia says OpenGL is column major, it is actually storage agnostic. However by default it interprets your 16 element array as:

\begin{bmatrix}m_0 & m_4 & m_8 & m_{12}\\ m_1 & m_5& m_9 & m_{13}\\ m_2 & m_6 & m_{10} & m_{14}\\ m_3 & m_7 & m_{11} & m_{15}\end{bmatrix}

Yet most OpenGL functions dealing with matrices offer a transpose parameter which you can use to specify the used order. For a comparison of storage orders see the Eigen documentation.

Notably however, GLSL matrices do neither follow C nor mathematical notation; the mat2x4 M type has 2 columns and 4 rows and thus M \in \mathbb{R}^{4 \times 2} mathematically.
Consequently though – albeit breaking with the C notation – M[0] will return the first column (vec4).

Now, if you use the transpose parameter mentioned before, prepare to think hard about the data you are actually getting in the Shader.

Using the XBox Controller with Ubuntu (the modern way)

If you want to get your Xbox One/ Xbox 360 running on ubuntu you basically have the choice between the in-kernel xpad driver and the userspace xboxdrv driver.

Most of the guides recommend using xboxdrv as xpad has been stagnating. However using xboxdrv has some disadvantages; as it runs as a daemon in userspace you have to manually take care of starting/ stopping it and giving your user access to the virtual devices it creates.
Xpad on the other hand just works as any other linux driver directly inside the kernel which is more  efficient and hassle free.

Fortunately while pushing SteamOS Valve has updated the xpad driver bringing it on par with xboxdrv:

  • they added support for Xbox One Controller
  • they fixed the communication protocol – no more blinking controller light

Update July 22, 2015

Unfortunately there are still several issues with the SteamOS driver. This follow-up post discusses them and the solutions in detail.

The bottom line is that I updated the official linux driver with chunks found in the SteamOS driver, as well as in several patches floating around the internet. Code and install instructions are available at Github.

How to draw a line interpolating 2 colors with opencv

The built-in opencv line() drawing function allows to draw a variety of lines. Unfortunately it does not allow drawing a gradient line interpolating the colors at its start and end.

However implementing this on our own is quite easy:

using namespace cv;

void line2(Mat& img, const Point& start, const Point& end, 
                     const Scalar& c1,   const Scalar& c2) {
    LineIterator iter(img, start, end, LINE_8);

    for (int i = 0; i < iter.count; i++, iter++) {
       double alpha = double(i) / iter.count;
       // note: using img.at<T>(iter.pos()) is faster, but 
       // then you have to deal with mat type and channel number yourself
       img(Rect(iter.pos(), Size(1, 1))) = c1 * (1.0 - alpha) + c2 * alpha;
    }
}

Introducing Sensors Unity

Sensors-Unity is a new lm-sensors GUI for the Unity Desktop. It allows monitoring the output of the sensors CLI utility while integrating with the Unity desktop. This means there is no GPU/ HDD support and no plotting.
If you need those you are probably better suited with psensor. However if you just need a overview of the sensor readings and if you appreciate a clean UI you should give it a shot.

It is written in Python3 / GTK3 and uses sensors.py. You can contribute code or help translating via launchpad.

Overview

In contrast to other applications the interface is designed around being a application. Instead of getting another indicator in the top-right, you get an icon in the launcher:

The user interface
The user interface

The idea is that you do not need the sensor information all the time. Instead you launch the app when you do. If you want to passively monitor some value you can minimize the app while selecting the value to display in the launcher icon.

To get the data libsensors is used which means that you need to get lm-sensors running before you will see anything.

However once the sensors command line utility works you will see the same results in Sensors-Unity as it shares the configuration in /etc/sensors3.conf.

Configuration

Unfortunately configuring lm-sensors via /etc/sensors3.conf is quite poorly documented, so lets quickly recap the usage.

  • /etc/sensors3.conf contains the configuration for all sensors known by lm-sensors
  • however every mainboard can use each chip in a slightly different way
  • therefore you can override /etc/sensors3.conf by placing your specific configuration in /etc/sensors.d/ (see this for details)
  • you can find a list of these board specific configurations in the lm-sensors repository
  • to disable a sensor use the ignore statement
    #ignore everything from this chip
    chip "acpitz-virtual-0"
       ignore temp1
       ignore temp2 
    
  • to change the label use the label statement
    chip "coretemp-*"
       label temp1 "CPU Package"
    

Sensors-Unity Specific Configuration

Sensors-Unity allows using the Pango Markup Language for sensor labels. For instance if you want “VAXG” instead of “CPU Graphics” to be displayed, you would write:

label in4 "V<sub>AXG</sub>"

In order not to interfere with other utilities and to allow per-user configuration of the labels/ sensors Sensors-Unity first tries to read ~/.config/sensors3.conf before continuing with the lm-sensors config lookup described above.

introducing sensors.py

sensors.py is a new python wrapper for libsensors of the lm-sensors project. libsensors is what you want to use to programmatically read the sensor values of your PC with Linux instead of parsing the output of the sensors utility.

sensors.py is not the first wrapper – there are two alternatives, confusingly both named PySensors.

PySensors (ctypes) follows a similar approach to sensors.py by using ctypes. However instead of exposing the C API it tries to be a object-oriented(OO) abstraction, which unfortunately lacks many features and makes the mapping to the underlying API hard. Furthermore it does not support Python3.

PySensors (extension module)  does not use ctypes and thus is more efficient, but if you write a python script probably compiling a extension module is worse than losing some performance when reading the values.
Additionally there is python3 support and also some OO abstraction. The latter is somewhere in between the C API and proper OO: sensors_get_label(chip_name, feature) is ChipName.get_label(feature) instead of feature.get_label().

So what makes sensors.py immediately different is that it does not try to do any OO abstraction but instead gives you access to the raw C API. It only adds minor pythonification: you dont need to mess with pointers, errors are converted to exceptions and strings are correctly converted from/ to utf-8 for you.

However working with the C API directly is tiresome at times – therefore there is also an optional iterator API, which is best shown by a demo:

import sensors

sensors.init()

for chip in sensors.ChipIterator("coretemp-*"):
    print(sensors.chip_snprintf_name(chip)+" ("+sensors.get_adapter_name(chip.bus)+")")
    
    for feature in sensors.FeatureIterator(chip):
        sfi = sensors.SubFeatureIterator(chip, feature)
        vals = [sensors.get_value(chip, sf.number) for sf in sfi]
        label = sensors.get_label(chip, feature)
        
        print("\t"+label+": "+str(vals))

sensors.cleanup()

result:

coretemp-isa-0000 (ISA adapter)
 Physical id 0: [38.0, 80.0, 100.0, 0.0]
 Core 0: [37.0, 80.0, 100.0, 0.0]
 Core 1: [35.0, 80.0, 100.0, 0.0]
 Core 2: [38.0, 80.0, 100.0, 0.0]
 Core 3: [36.0, 80.0, 100.0, 0.0]

for a more sophisticated example see the example.py in the repository.

Replacing your desktop laptop with a ITX workstation

If you use your laptop as a desktop replacement, you will at some point get an external display and a mouse/ keyboard for more convenient usage.
At this point the laptop becomes only a small case of non-upgradable components.

Now you could as well replace your laptop by a real case of comparable size.  This will make your PC not only easily upgradable, but allow higher-end components while being more silent at the same time.

Continue reading Replacing your desktop laptop with a ITX workstation