Lenovo T520 and Déjà Dup
Collabora, the wonderful company that they are, have allowed me a laptop upgrade after a couple of years of working there. The Lenovo X200s that served me so well while travelling back and forth between England and Sweden regularly during my early Collabora Multimedia days was starting to show its age with its Intel Core 2 Duo vPro 1.8GHz CPU.
The new laptop is a Lenovo T520, a 15.6” 1080p, quad core Intel Core i7 2.4GHz (turbo up to 3.5GHz) hyperthreaded sandybridge behemoth. It flies. It’s awesome to work on, even moreso as Collabora got an OCZ Vertex 2E SSD for me a while ago (which had to be replaced via OCZ RMA after 3 months… daily backups are a must if you do anything vaguely important).
The T520 model I have comes with both sandybridge integrated graphics and NVIDIA discrete graphics (NVS 4200M). I used the integrated graphics for some time and it works fine in Fedora 16 and anything else thrown at it, with one exception. There’s a known issue in the driver of tearing when playing back videos despite supposedly being always vsynced.
I had always planned to set up the discrete NVIDIA graphics drivers so I could switch in the BIOS (well, EFI, whatever) as I pleased and as needed. I tried and tried and tried to get the drivers working last night but after installing the akmod-nvidia package in Fedora 16, it would no longer boot, even after switching back to integrated graphics in the BIOS. Weird. I failed after attempting to fix the startup error (“[drm:ironlake_update_pch_refclk] *ERROR* enabling SSC on PCH” was not the real error but was the last thing in dmesg - peculiar as modesetting should have been disabled) and couldn’t find any solutions from anyone else so gave up, reinstalled as I need to work on this machine and commenced trying to restore from backups which I had been making nightly with an external drive and Déjà Dup.
Unfortunately, when trying to conduct a full restoration, Déjà Dup fails citing that there is not enough space at the target path. That is complete crap. It could be that there is not enough space on /tmp, but that feels like some kind of poor design if one can back something up on some machine but not restore it.
Maybe using duplicity directly can do better, it has a —tempdir option! Alas, no. It seems to still hit a no space left error. I had to hack duplicity code a little to use the proper tempdir to be able to do a full restoration. It seems the offending portion of the backup was a large VM image that had been stored as diffs and so took up lots of space with the incremental reconstruction.
