Setting Up Kubuntu on a Lenovo Y50 - Data Immortality Edition

I am the lucky owner of a brand new Lenovo Y50. It’s a screaming fast machine, with a gorgeous screen (despite what naysayers complain about – mostly the yellows and the refresh rate). It’s meant for gamers, but a developer like me can like it, too. It’s just beautiful, and relatively lightweight, and did I mention it’s screaming fast?

But the big question was: How Do I Set It Up Most Efficiently?

“Most efficiently” in this context means: least time, best setup moving forward. I wanted to recreate my development desktop onto the laptop, which meant not just installing the OS and the software, but to also move configuration files and data.

It’s a problem I have been grappling with for a while: where should stuff live to be “immortal?” Where should it live to be easy to access? And where should it live not to be a burden?

Cloning the Drive

The first thing you need to do before** you install Kubuntu is to take a snapshot of the drive**. It’s a 256GB SSD, so you don’t need a whole lot of space to store it. Any backup drive will do. In particular, I have my famous RAID5 array, consisting of 3 WD external 3.0 drive, that I just love, love, love.

Before you can even think about installing something, you have to go to the BIOS and change the boot settings. To do that, you press on the teeny button to the left of the Power button. That gets you into the BIOS menu, where you simply turn off UEFI booting and change the boot order to start with external drives. You can change that back later if you like, once installation is complete. (I don’t know if Kubuntu Trusty is UEFI compliant – don’t really care.)

At first, I ran the Kubuntu live CD. On it, I upgraded, then installed Clonezilla. Whatever joker is responsible for the clonezilla package forgot tons of stuff, like parallel ZIP2 compression, and if you select the corresponding options, the cloning process just dies. Even worse, even after you have all the requirements installed, the version of Clonezilla available on Trusty uses a command line option that the underlying partition cloner does not understand in the Trusty version.

So I had to download and run the Clonezilla Live CD. Sigh. At least it worked like a charm. After specifying all that I needed, I had a clone of the disk on my backup drives.

Installing Kubuntu

I have a thumb drive with YUMI on it. The current Linux version doesn’t really work – it doesn’t create the boot menu and leaves you with a shell at boot time where you have to figure out what weird name invokes which distro. But after a bit of hand editing, I had kubuntu configured as the default boot. (I tried Linux Mint, but it somehow always fails to install towards the end of the process.)

I am really good at installing Kubuntu by now. You tell the installer to “Try out Kubuntu.” Then you land in a gorgeously enormous screen (on the Y50) where all fonts and icons are microscopic. That is annoying, but I suppose if I had a 50″ screen the sizes would be appropriate. Fortunately, there is an easy way to get your stuff visible (sort of): hit Alt+F2 and type ‘systemsettings’ in the little box that shows up (you will probably not be able to see it).

What you get is the System Settings dialog. There you go to the second icon from the left in the first row. It’s a teeny white box on top of an identical teeny white box (someone shoot give the KDE icon designers a stern lecture). That will change the application to something with a bunch of icons on the left. You pick the fourth one from the top, the one that looks like two teeny letters T on top of each other. There, you go to the row of buttons to the right and click on the bottom one, slightly wider than the others (it says, “Adjust All Fonts”, but you can’t read that). A dialog pops up, and there you click on the minuscule check box to the top right. Select the edit box below (it is now editable) and enter anything from 16 to 20. Hit Enter. Find the little button that says Apply to the bottom right. Hooray!

If you want to set up WiFi before starting the installer, that’s up to you. I did, but it required figuring out which one of the half dozen system tray icons was responsible for networks (made worse by the fact that KDE icon designers picked very similar ideas for the network and volume indicators). I didn’t try starting the installer and seeing whether it allows you to specify network parameters.

Then you click on the top left icon, which is still too tiny to be visible. Turns out that’s the installer, that now starts up with readable fonts. Go through it as you normally would, and BAM! you have your Kubuntu installation.

Of course, once you reboot, you have to change the monitor settings again. Follow the steps above. Also, you want to resize your bottom panel, because otherwise it’s just painful.

Installing Software from Repositories

What you should do next is make sure that your computer has all the required software. That’s a bit of a pain, since there is no single installer for everything. But apt-get does the majority of the trick. To transfer all the packages you already downloaded on a different machine, you make that machine spit out the list of packages installed on it. That is surprisingly easy:

apt-mark showmanual

Gives you a list of packages. You can feed that list to apt-get and it will just install everything you need. So the process is:

1. Go to the master machine and type apt-mark showmanual
2. Save the output to a file and email it to yourself
3. Go to the new (slave) machine and retrieve the email and copy the list
4. Run sudo apt-get install < name-of-the-list

If you have ssh access to the master from the slave, you can do that more easily by simply typing:

ssh <a href="mailto:user@master">user@master</a> apt-mark showmanual | xargs sudo apt-get install

This gets you all the software installed on the other machine installed on this one. It will take a while to finish, so you may want to think about that white chocolate mocha you were jonesing for. It’s a good time to get it.

If this fails spectacularly because of missing packages, then you have either:

• Additional repositories turned on or PPAs
• Installed software manually from a .deb file

In the former case, copy the directory /etc/apt/sources.list.d and the file /etc/apt/sources.list to your new machine. Run sudo apt-get update. Redo the step(s) above. All will be happy.

In the latter case, you have to find the .deb files you originally used and copy them over to the new machine. There, you have to reinstall them, which can be quite the pain. You may remember how you did it originally, most likely with something like:

• sudo dpkg -i mypackagename-weirdstuff.deb
• lots of complaints
• sudo apt-get install -f

The last item uses apt-get to ensure all the dependencies of mypackagename are satisfied. If apt-get doesn’t know what to do with that, it will uninstall mypackagename, so be cautious. Also, see below if you don’t know where you installed the packages from.

Installing Other Software

As lovely as apt-get is, sadly you can’t rely on it for everything. In particular, there are several other environments that have their own installers. Some are command line (like Ruby, or Python). Some are graphical (like Eclipse or Netbeans).

To get all that software installed, you’ll have to follow the same processes you followed when you started out (and over time). For those that have a command line, you may be in good luck: every time you use sudo, the command is recorded in /var/log/auth.log*. So if you go to the master and grep for the command, you’ll get a list of installations.

I’ll give you an example: I created software to display wave graphs from NOAA data (for surfing – I am not just a geek!). I used Python for that, because it has this amazing scientific stuff support. Now, most of the Python packages are available in apt form (so they would have transferred with showmanual). A few of them, though, are not offered in the standard repos yet. Instead, you have to install the tool “pip” (I assume something like “Package Installer for Python”).

When I grep for “pip” (the word, -w), I get three lines:

/usr/bin/apt-get install python-pip
/usr/bin/pip install ephem pytides
/usr/bin/pip install pytz

(There is stuff before that, but we care about this stuff only.) The first line installs the python-pip package using apt-get (so you got it with showmanual). The other two lines tell you what you need to do to install ephem, pytides, and pytz.

The other command line installers will mostly do the same thing. The exception are installers that don’t need root privileges, but that should be relatively rare.

The graphical installers come with GUIs (obviously) and are common with application plugins like in Eclipse, but also in common KDE applications. The latter has the Get Hot New Stuff (ghns) dialog that is absolutely awesome, but whose activity is not tracked anywhere as far as I can tell.

The upside, though, is that if you don’t need root privileges, chances are the hot new stuff is stored in your HOME directory, and we’ll get to that in a minute.

Another type of software is that which you compiled and made yourself. That’s not covered anywhere. Again, if you needed root privileges to install, you’ll find a trace of it in your auth log. For instance, a traditional package requires a sequence of: ./configure; make; sudo make install. While the configure and make steps are invisible to auth.log, the sudo make install is captured. To make your life just a tiny bit easier, you also get the location from which the make install was launched, which tells you what software that was.

Here is a simple example: I wanted to know how the current Qt port of Freeciv was doing, so I githubbed (cloned the github repo) into my home directory and configured/made/installed. The trace of it I can see is:

Nov  1 17:23:01 belulin sudo:    marco : TTY=pts/2 ; PWD=/home/marco/dev/github/freeciv-trunk ; USER=root ; COMMAND=/usr/bin/make install

Now, I am an orderly person, so you can easily see that I started the make install from the dev directory; there in the github directory (renamed to ‘external’ now because there is all sorts of stuff out there), and inside there in freeciv-trunk.

Even if I decided to get rid of that directory, I would still have a clue what was in there. So make install can be very helpful in getting software copied over. (Note that you won’t know the details of the compilation, since those usually don’t require root privileges. But armed with the source code and build in your home directory, repeating make install will give you the software configured just right. Or at least just as you had it.)

Dealing With Your Home Directory

The temptation is to simply move over (as in copy) the home directory wholesale. But since you are setting up a new machine, might as well be a little more disciplined about it.

Turns out my data (and probably yours) comes in different varieties:

• Data I need infrequently, like the ISOs of a distribution or the installer package of NetBeans
• Data I need frequently, on all my machines
• Data I need frequently, on some of my machines but not all
• Data that changes frequently – like configuration files – that I want syncronized
• Data that changes frequently – like my source code – for which I want old copies with the new ones

All the data mentioned here, it goes without saying, needs to be reliably backed up somewhere. Some of it (the ones I need frequently, mostly) need to be available all the time, which means when I am outside the home office. Some of it, though, doesn’t. Everything I download from the web (including .deb files for apt-get) I don’t need to have locally. It’s perfectly fine if it’s on a remote machine at home. I access them using SSH – with the security piece much less interesting than the reliability one.

I find that combining an external synchronization service with a local service is the best way to deal with frequently changing data. I use Dropbox externally and Owncloud internally. Both are configured to synchronize unencrypted and encrypted data – they just live in separate folders. So one of my folders may live on Dropbox or Owncloud, encrypted or unencrypted. I make that all happen with creative use of symbolic links. For instance, my personal photos live on Dropbox, while my surfing videos are on Owncloud. I access them both from the Media folder on my desktop.

I deal with configuration files the same way. Here, Owncloud wins because I don’t really care about changes in configuration while I am outside the home network – I will synchronize all changes once I am back. So I simply moved the .kde folder to one of my Owncloud folders, created a symbolic link into the home folder, and everyone is happy.

When dealing with these symbolic links, you have to remember to move them. Fortunately, find (the UNIX command) can tell you about all symbolic links and you can just use its output to recreate them on the new machine. The easiest way to do that is to use sshfs: you mount the remote home directory locally and simply copy the links over. since they are symbolic, they will point to files on the new machine, even though they are copied from the old one.

Source code and other data whose history I want recorded (like my writing projects, or web sites) live in a source code control system that doesn’t require separate synchronization. I created a separate project, SVNFS, that allows me to ensure all files that are stored in folders under version control are correctly versioned. Also, a script (autosvn) merges changes to the repository as a cron job.