WUBI or dual boot?

Installing Ubuntu, the hard way

 

The reasons it took me so long to get a dual boot installation to run on my new HP Elitebook 8760w were threefold. For one, our computer helpdesk guy did not want to install linux next to the corporate Windows 7 solution. This scared me into thinking that this was "forbidden", so my first thought was about staying inside Windows instead. That did not last too long, though, because I have never been comfortable with code development on Windows, unless it is Java, Groovy or SQL or similar. I have been test-running a MacBook Pro since a couple of months. Nice, sleek and fast as well (it has an Pentium I7, 16 Gb RAM and a 500 Gb solid state disk), but everything is packed behind flashy graphics and package management is weird. Nothing beats linux as a serious code development environment. And, by the way, this all comes for free as in "free beer"... It's a no brainer, really!

Going WUBI

So, the choice was linux, and my favourite version is Ubuntu. I know SuSE, CentOS, Fedora and Debian versions as well, but have worked mostly with Ubuntu (and Knoppix for special repair jobs). Still hesitating about the dual boot option, I came across WUBI which installs Ubuntu inside Windows. As usual, I did not read the instructions to the end, and happily installed Ubuntu 12.04. This is actually a great way to test linux on a Windows box. You get a pseudo-dual boot start-up, where you can choose between Ubuntu and Windows. However, there is no specific ext4 partition or swap space, for instance. It's not like a Virtual Machine either, which is good, because you would not be able to install the graphics driver you need for the GPU development. Everything seemed to work fine (WiFi, network, etc.) and since I just got used to the MacBook, I even liked the new interface of 12.04 (why not implement useful ideas from those who replicate, and then close up, your code base?). WUBI has some limitations, though, for instance, it can use maximum 30 Gb of disk space, inside the Windows file system.

I managed to install CUDA 5 using the "all in one" installer (669 Mb!) from the CUDA developer zone which took a long time.  I think this is due to the disk space allocation, which probably requires some Windows intervention. After the installation, which includes the development driver, I noticed that the touchpad no longer worked.

I went on to get the OpenCV code and tried to build with CUDA and Java support enabled. This is a fairly long process as well, and occasionally locks the machine with Ubuntu going "grey" several times. After a particularly long period of non-response of the system, I panicked! This is never a good idea during installs! Still, after Ctrl-Alt-F1 and sudo reboot now the grub menu came back up, but Ubuntu did not. Back in Windows, I understood from the web reports that the WUBI installation was damaged, and that the best way out was to remove the C:\ubuntu directory. Removal did not work, however, as the files in the directory were corrupted and Windows suggested to run chkdsk, which required a reboot. This took several hours, staring at the 3 stages of chkdsk, which goes through 100s of thousands of segments, security IDs, etc. After another restart and C:\ubuntu removal, and another reboot, the grub menu was gone, and Windows started normally as it did before the WUBI experiment.

Dual boot, alas!

Dual boot was now the only option left. I decided for a USB install. This went amazingly well and was dead-simple, as I did not opt for a sophisticated disk partitioning. Windows was "shrunk" in the process, but was working well, after it got used to it's reduced status on the box. Back to linux, I decided to install CUDA 4.2 instead, because I thought the CUDA 5 "all-in-one"  installation had something to do with the WUBI crash. Also, CUDA 4.2 comes as separate installs for the CUDA toolkit, the driver and the SDK. I first installed the driver, during which I was prompted for the DKMS option (chose yes, if you want to make sure the driver is included during a kernel update). This apparently went well, although I lost the touchpad functionality again after reboot. The update manager suggested some 250 Mb of upgrades, which included a kernel update. After yet another reboot, the screen went in VGA mode (it can do the full-HD 1920 by 1080 resolution if the driver works correctly) and the NVIDIA driver was no longer found. I guess DKMS did not work properly. Re-installing the 4.2 driver did not work either, and I was left in a terminal session of the "recovery mode" version.

At this stage, I needed a plan... I would do things in the right order and read up on the specific installation steps. I re-installed Ubuntu from the USB stick. This went fine and fast, as the process found the previous version and overwrote files without needing to reformat the ext4 partition. I read installing CUDA 5 on Ubuntu 12.04 and followed it to the letter. This time, I ran the CUDA 5 installer in one go. Only the SDK complained about some missing dependency (libglut), but re-installed after that was resolved. Curiously, though, the driver installation never prompted for anything, not even for the DKMS option. After testing the compiled CUDA code samples, I ran the system upgrade (same as previously). This time, I was expecting that the driver would not integrate with the kernel upgrade. But that was resolved by re-installing the driver only. We have to do this regularly on the workstations, which run Ubuntu 10.04, so I knew the issue. I just wish that Ubuntu kernel upgrades were less frequent.

Also this time, the touchpad stopped working but a simple re-install of the Synaptics driver resolved that issue.

Conclusions

In hindsight, I think a WUBI installation would have worked, after all. The 30 Gb limit may have been more of a hurdle, though, with the long term goal to process large satellite image data sets with GPUs. The Ubuntu partition is 150 Gb, so that limit is less problematic for now.

In the end, everything worked fine, or was, at least, under control. I was now able to run all the other installations (JDK, Groovy, Ant, the UbuntuGis suite (QGIS, GDAL, etc.), Skype) and the other essentials. I was stupid enough to do this in the previous installs before I ran into the (falsely perceived) CUDA install problems. In fact, I was so happy, that I decided to start this blog. If anyone ever arrives at this point, here's some simple rules on installations:

RTFM: obvious enough for many, but Mr. Expert usually thinks this is not for him. Still, reading the f#@king manual before you do anything in this context makes a lot of sense. The good news is that most of the essential material is one or two pages, usually with parse-able statements that guides you through the steps in the right order. Make sure the documentation is specific to the hardware/software components of your system (i.e. look for "Install CUDA 5 on a Quantum 3000M on Ubuntu 12.04" instructions, not "Install CUDA on Ubuntu").

Figure out the right order: do the most tricky things at the start of the process and make sure to test each step. This may require more frequent reboots, but it saves you lots of time when things go wrong. Run the installation of the least critical components only when the essentials run correctly.

Don't panick and persevere: Open Source is an experience, not a shrink-wrapped auto-run installation from a CD. Don't get discouraged by the occasional glitch. Someone, somewhere has likely run into the same problem, and squeezed out a solution on some forum. If the problems are discussed in old exchanges, you can be sure a solution was found.
Even on today's fast processor-based systems, compilations and installs may take considerable time. For instance, while GPUs are extremely fast in executing (well-designed) code, compiling that code is a serious computational effort (on a CPU). Software packages increase in size and complexity with every upgrade and release. Give your box the time to complete these complex tasks. Don't panick, don't hit that Ctrl-C or Ctrl-Alt-F1 combination, and don't "simulate" that power failure. If you screw up the process, you loose more time than the few minutes you could have waited.
Completing a complex install successfully is a very rewarding experience, especially if you build it from source (and repair a bug in the process...). It should make you pause and think about the excellence of open source software which is based on the collective efforts of so many people who solved issues before us and were kind enough to share their ideas with so many of us.