Ubuntu 13.10 on the Sony Vaio Pro 13

It’s been a while since I’ve posted something, but figuring out how to install Ubuntu 13.10 using EUFI, Secure Boot and FDE (‘Full Disk Encryption’) took me some time, so I’ll just write it down and hope I’ll save someone else an evening (or two) by putting all the information together.

This post just describes what I did, and involves steps where you can probably screw up your system. Decide for yourself whether this really is what you need, I do not take any responsibility for wrecked systems ; )

Create a backup image of your hard drive

I don’t need all the recovery stuff taking up precious space on my SSD, but I *do* want to be able to revert to ‘factory defaults’ when some hardware error occurs and stubborn helpdesk employees insist on reverting to factory defaults before considering there is a real issue. So, I boot from the Ubuntu liveUSB and make a gzipped disk image which I store over the network on some machine with plenty of disk space:

sudo dd if=/dev/sda | gzip | ssh <user>@<storage-machine> dd of=/path/to/disk/image.gz

My 256G SSD gave me a 39G gzipped image. Not too bad.

Restoring the image would be done this way:

ssh <user>@<storage-machine> dd if=/path/to/disk/image.gz | gzip -d | sudo dd of=/dev/sda

Retrieve your Windows 8 product key

I’m going to remove all current disk contents, but since every now and then I do need Windows for some specific application, I booted Windows 8 one more time, and retrieved the product key using Belarc Advisor ( http://www.belarc.com/free_download.html). This way I can use the key to install a Windows 8 virtual machine with the license that comes with the Vaio.

Update your BIOS

Sony offers BIOS updates through their support website, but those are Windows binaries. If you’re planning to throw out Windows as a native OS, take the opportunity to update your BIOS before throwing out Windows.

Install Ubuntu

Contrary to popular belief, it is *not* required to disable Secure Boot or even switch to Legacy mode to run Ubuntu. Leave both Secure Boot and UEFI enabled, they offer some extra security and functionality.

The installation itself actually works as expected, but since the Sony UEFI firmware is not working properly choose ‘Try Ubuntu before installing’ when you boot from the Ubuntu live usb stick. This gives you the options to fix some stuff before rebooting after a successful installation. From the live Ubuntu, start the installation using the ‘Install Ubuntu’-button in the Unity launcher.

During installation choose the ‘Erase disk and install Ubuntu’ option and enable Full Disk Encryption (which will enable LVM). Let the installer do its thing. Once it’s done don’t reboot the machine, but choose ‘keep trying Ubuntu’. We’re going to work around Sony’s UEFI limitations now.

Convince the Sony firmware to fire up Grub

Mount the EFI partition. If you’ve chosen to let the ubuntu installer take care of everything it’s probably /dev/sda1, if you’ve kept the original it’s probably /dev/sda3. Otherwise do a ‘sudo parted -l’ to figure out what’s the bootable fat32 partition, that’s the one you need.

sudo mount /dev/sda1 /mnt

Now create the path where Sony expects the bootfiles, and copy the ubuntu files over to convince it to really fire up grub:

cd /mnt/EFI
sudo mkdir -p Microsoft/Boot
sudo cp ubuntu/* Microsoft/Boot/*
sudo cp Microsoft/Boot/shimx64.efi Microsoft/Boot/bootmgfw.efi
cd ~
sudo umount /mnt

That should get you into grub.

If you’ve chosen to disable Secure Boot, you probably want to copy grubx64.efi instead of shimx64.efi.

Learn grub to cope with the SSD

Somehow the boot fails when you don’t explicitly tell your kernel not to use NCQ. As NCQ doesn’t make any sense with SSDs (there’s no moving head), we don’t need it and can just disable it. This requires us to mount the encrypted root partition. The following step is only required when you’re using Full Disk Encryption (which you actually *should* do), otherwise just skip to the ‘mount the root partition’ step.

First open your encrypted partition (in my case /dev/sda3, again take a look at the ‘sudo parted -l’ output for yourself), then activate the LVM:

sudo cryptsetup luksOpen /dev/sda3 sda3_crypt
sudo lvchange -ay

Now, mount your root partition:

sudo mount /dev/mapper/ubuntu--vg-root /mnt
sudo gedit /mnt/etc/default/grub

If you didn’t use lvm or disk encryption it’s probably /dev/sda2, instead of /dev/mapper/ubuntu–vg-root.

and change the GRUB_CMDLINE_LINUX_DEFAULT line to:

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash libata.force=noncq"

If your prefer to see your boot log instead of the Ubuntu splash logo, remove the splash keyword while you’re at it.


That should do the trick, reboot your machine, cross you fingers and enjoy your Vaio Pro with Ubuntu!

To get the most of your installation, it is worthwile to install the 3.12 kernel or newer, as it has better support for the pstates in your CPU. In the 3.11 kernel the dynamic scaling will not work. In my case the CPU cores were stuck at 800MHz. Before you start hacking, make sure your Ubuntu is updated and check your kernel version by issuing a `uname -r` command from a terminal. If it’s 3.12 or newer, you’re good. Otherwise get the newest .debs from http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.12-saucy/ and install them using dpkg -i. I my case I did the equivalent of:

sudo dpkg -i linux-headers-3.12.0-031200-generic_3.12.0-031200.201311031935_amd64.deb
sudo dpkg -i linux-headers-3.12.0-031200_3.12.0-031200.201311031935_all.deb
sudo dpkg -i linux-image-3.12.0-031200-generic_3.12.0-031200.201311031935_amd64.deb

One last hint, once you’ve booted, there are some files in /sys/devices/platform/sony-laptop where you can control some setting specific to your laptop. For example, to reduce the fan noise in exchange for a little more heat issue the following command:

echo silent | sudo tee /sys/devices/platform/sony-laptop/thermal_control


This post is a collection of information I found on the web, together with results of trying out stuff myself. Pages that contributed to this post are:
And probably some more that I cannot find anymore.

Debian power management

A small list of the things I did to reduce the power consumption of my debian server.

1. Disable unused hardware.

Disable all the hardware your do not use, disconnect if possible (e.g, optical drives) or disable in your BIOS. Your probably does not need audio, firewire or parallel ports.

2. Make sure your CPU clocks down.

Install powertop and cpufrequtils

apt-get install powertop cpufrequtils

and check your CPU spends it’s time in the low CPU speed state most of the time when idling.

3. Let your disks spin down when idle

Desktop disks use typically about 5 Watts when idling. If you have 5 of them in your RAID5 setup, it saves you 25 Watts (when spun down 12 hrs a day, 110 kWh/year).

Enable disk spin downs by installing laptop-mode-tools

apt-get install laptop-mode-tools

and set your spin down delay in /etc/laptop-mode/laptop-mode.conf:


I choose for a 30 minutes delay before spinning down, because I use desktop disks that can not handle being spun up and down very often.

To make sure my disks are idle more often (reads can be handled from cache), I disabled the access time registration for my RAID array by adding the noatime option in /etc/fstab:

# <file system> <mount point>   <type>  <options>       <dump>  <pass>
/dev/md0        /mnt/data       ext4    defaults,noatime        0       0

PS I wrote this post primarily for myself, but if your have any suggestions or additions, please leave a comment.

Mount /tmp on ram (tmpfs)

As /tmp is cleared every reboot (see FHS), and current systems have quite a lot of RAM, it makes sense to mount /tmp on RAM. Mounting /tmp on RAM has several advantages, e.g.:

  • Security; /tmp is used for storing data like keys and extracted (decrypted) archives. When /tmp is located in RAM, this data is gone after a power down instead of deleted on the next boot.
  • Performance; writing to RAM is way faster than writing to disk.
  • Energy consumption; disks can not spin down when they are used. Applications using /tmp will no longer keep your disk active.

So, how to mount /tmp in RAM? Thanks to tmpfs that’s pretty straight forward! Add this line to your /etc/fstab:
tmpfs /tmp tmpfs nodev,nosuid,mode=1777 0 0

And reboot. Done!

When you are more security focussed (on your server for example), you might also want to add the noexec property to the fstab line. This prevents a lot of scripted attacks from executing malicious code from /tmp. There are however catches to this: apt’s default config also uses /tmp to execute scripts, so you’ll need to give it another tmp directory on which it does have exec rights, /var/tmp for example (use the APT::ExtractTemplates::TempDir directive in apt.conf). Also, nVidia drivers need /tmp to be executable for 3D stuff. (More on this)

Advanced synology mail server

In this post I will describe how I changed the Synology Mailstation config to:

  • Receive mail for multiple domains
  • Create a ‘smart’ regexp catchall
  • Accept relay for authenticated users

Receive mail for multiple domains

Add to the end of your /usr/syno/mailstation/etc/main.cf:

virtual_alias_domains = seconddomain.tld thirddomain.tld
virtual_alias_maps = hash:/usr/syno/mailstation/etc/virtual

Create the file /usr/syno/mailstation/etc/virtual and use this format:

address1@seconddomain.tld	user
address2@thirddomain.tld	user2

After every change you make in the file ‘virtual’, run postmap:

cd /usr/syno/mailstation/etc
../sbin/postmap hash:virtual

Create a ‘smart’ regexp catchall

It can be very convenient to be able to make up email addresses while for example filling in surveys. We’ve got catchall’s for that: whatever doesn’t have a rule gets forwarded to a specific address. Unfortunately spammers seem to have found the advantage of that too: they can spam you at a lot of addresses. To counter this, we can create a catchall for email addresses that have a specific form, for example “mytag_somethinghere@yourdomain.tld”. To do this, we create a regexp virtual alias map. Change your virtual_alias_maps variable in main.cf to

virtual_alias_maps = hash:/usr/syno/mailstation/etc/virtual regexp:/usr/syno/mailstation/etc/virtual-regexp

and create the virtual-regexp file with this content

/^mytag_.+@yourdomain.tld/	user

Of course, you can get as creative as you want, the first part of a line is a regexp and the second part the address to deliver the mail to.

Accept relay for authenticated users

By default, there is no option to make your mail server authenticate users for SMTP. This can be useful when you want to send mail while you’re on-the-go. The authentication can be handled by dovecot, but to do so we need to make it available for Postfix. Alter /usr/syno/mailstation/etc/dovecot.conf such that the “socket listen” section looks like:

  # It's possible to export the authentication interface to other programs:
  socket listen {
    client {
      # The client socket is generally safe to export to everyone. Typical use
      # is to export it to your SMTP server so it can do SMTP AUTH lookups
      # using it.
      path = /var/spool/postfix/private/auth
      mode = 0660
      user = postfix
      group = postfix

Then, add to /usr/syno/mailstation/etc/main.cf (if not there yet):

smtpd_sasl_type = dovecot
smtpd_sasl_path = private/auth
smtpd_recipient_restrictions = permit_mynetworks, permit_sasl_authenticated, rej
smtpd_sender_restrictions = reject_unknown_sender_domain
smtpd_sasl_authenticated_header = yes
smtpd_tls_cert_file = /usr/syno/etc/ssl/ssl.crt/server.crt
smtpd_tls_key_file = /usr/syno/etc/ssl/ssl.key/server.key
smtpd_tls_security_level = may
broken_sasl_auth_clients = yes
smtpd_sasl_auth_enable = yes

And reboot the mailstation with “/usr/syno/etc/rc.d/S89mailserv.sh restart”.

That’s it! You can now authenticate (using TLS) to your SMTP server to send mails when you are located outside your private network. The usernames and passwords are the same as for accessing other Synology services.

Fancy lights in the floor: ProtoDeck


My first post about my thesis project will be on a side track of it: the protoDECK floor at the faculty of architecture. Some creative guys over there (the hyperbody group) are working with the concept of interactive design in architecture. To do so they built protoSPACE 3.0, a prototype room with many interactive components. The floor of this room, the protoDECK, consists of a large number of individually CNC-fabricated tiles of which 189 are equipped with a RGB-led and pressure sensor hooked up to a simple controller. Together with Bogdan Mihoci and Agostino di Figlia, we helped the architecture guys to get the floor to actually do something.

Next up is a short recap of the technical background, for the demo videos just scroll down immediately…

The hardware


one of the protoNODEs

The hardware for the tiles had been designed before we got involved with the project. The nodes are built around an atmega8 controller, and were originally designed to be connected to a common I2C bus. This setup turned out not to work, which is where we came into the picture.

My groups research subject is on the development of distributed and scalable solutions, so we came up with a decentralized approach. To do so, the first step was to remove the common I2C bus and create a mesh network by giving every node a direct link to it’s immediate neighbors. This sounds more straightforward than it turned out to be: because the chip has just a single serial interface available, we had to write our own software serial communication solution that makes use the digital ports of the chip. This hacking combined with a low budget for the wiring and connectors gave us unreliable and slow (~100 bits per second) communication, but at least there was communication.

The software

protoDECK lab setup

Lab test setup

Because of the unreliable and slow communication between nodes, the software needs to be very robust. For the two demos we did, we used a flooding approach, in which every node sends some local values to it’s neighbors. This way, nodes are kept up-to-date on the status of their surroundings and can act accordingly to achieve an effect on the system scale.

The demos

And finally, the demos.

The first demo is the flooding of colors through the network. The tile in the corner is connected with a laptop through a serial interface that updates it´s color variables. From this node on, the information about a new color spreads through the network:

The second demo is an interactive version using the pressure sensor to detect the presence of people and produces ripples around detected persons. This is just the floor, no external devices such as laptops are connected.

What’s next?

As we speak I’m working an a next generation of nodes for under the tiles. The new hardware will be build around the LPC1769 LPCXpresso board, which has a much much much more powerful chip. 32-bit vs 8-bit, 120MHz vs 16MHz, 64K RAM vs 1K. On this new platform, there will be DelftProto VM running the application, featuring online code updates. Next to this wired setup in the floor, I will also work on a wireless version. This should enable designers to much more sophisticated rapid prototyping. For more information on that, take a look at the blog of my colleague, Agostino di Figlia: An Interactive Space: ProtoSpace.

Easy incremental SVN repository backups

On the web you will find many ways to create backups of your Subversion repositories, for example using svnadmin dump or svnadmin hotcopy. What most pages do not mention is the existance of the svn-fast-backup tool. For ubuntu users: it’s inside the subversion-tools package.

The svn-fast-backup tool automatically creates incremental backups of your full repository. Being incremental, you do not need much space for the backups (like with the usage of svnadmin hotcopy). It backups the full repository, including changes to older revision (unlike svnadmin dump --incremental). Finally, restoring is just a cp operation.

All that is left is a simple script that is executed daily (or whatever) by cron to create backups:

# SVN Repository backup script
# Uses svn-fast-backup to create incremental backups of your SVN repositories

SVN_REPOS='repo1 repo2 repo3'; # a list of databases to backup
STORE_DIR='/path/to/backup/directory'; # location where tar files should be stored!
LOGFILE='/path/to/logfile.log' # logfile to write output and errors to
MAX_BACKUPS=64 # number of incremental backups to preserve

echo " - Starting SVN repository backups...";
echo "[`date +"%F %T"`] Starting backup procedure" >> $LOGFILE;

for i in $SVN_REPOS; do
	if [ ! -d $STORE_DIR/$i ]; then
		mkdir -p $STORE_DIR/$i

	echo "  [`date +"%T"`] Starting backup of repo '$i'" >> $LOGFILE

	# Do actual backup
	svn-fast-backup -k $MAX_BACKUPS --force /var/svn-repos/$i $STORE_DIR/$i/ >> $LOGFILE 2>&1

	if [ "$?" -eq "0" ]; then
		echo "   - '$i' backup succeeded.";
		echo "   - !! '$i' backup FAILED !!";

Note: the incremental backups use hard links to preserve space on your file system. So, when you’re going to sync your backups off-site keep in mind you need to preserve the hard links to prevent your off-site backups from blowing up (e.g, use the -H flag with rsync).