Building a New Computer: Installing Software

By mid-2016 I wanted to retire Juno, my computer from early 2010. It had received an upgrade in the form of a larger SSD, but all the photos were still on a hard drive, and the 4 GB of memory wasn't sufficient when I was doing heavy photo editing, leading to interminable delays and annoying clicks as programs were swapped on and off the hard drive. It was time for a new computer.

A previous post covers the December 2016 hardware assembly for the new machine.

This post discusses software installation, and the next will describe my performance tuning efforts. Sneak preview: overclocking an i5-6600k in a small case with a 92mm cooler can be a challenge!

I hadn't installed Linux onto a computer for a few years -- I once had to restore the OS on my old computer after a botched upgrade to Ubuntu 15.10 -- so I stumbled a few times. In the rest of this post I'll run through the issues in roughly chronological order.

First I created a bootable USB stick with XUbuntu 16.10 on it, using the unetbootin utility on my old computer. (16.10 is code for 2016/October.) The first ISO image I downloaded didn't work, so I tried another source; that .iso file was larger and booted.

The BIOS/UEFI interface gave me two choices of how to boot from the one USB stick. My first choice didn't work, of course. The other did.

I followed my old procedure of creating a separate root and home partition, but the installs kept bombing out with errors such as "firmware started installer in UEFI mode but it looks like maybe the OS is already installed in BIOS compatibility mode." To make a long story short, I didn't realize I had to create a bootable UEFI partition. I dsicovered this by abandoning my attempt to do a custom install and accepting the installer's defaults, which worked, and then I could examine what it had done.

I decided I wanted to try running without a swap partition on the SSD, having a generous 32GB of RAM, so I disabled the swap partition. The SSD now has a 0.5 GB EFI system partition, a 915 GB main partition, and a 16 GB unused partition.

I tried to copy my files over to the new machine via FTP from the old machine, but the FTP process kept stumbling over odd file names. I finally used grsync to copy my files from a backup HDD.

There was BIOS/UEFI tweaking to be done. By default turbo mode for the CPU was disabled, for example, and the i7z utility was handy to verify the state of the system. Also, I had to enable memory "overclocking" for the RAM to be run at its rated 2400 speed rather than the default 2133. (Another reason for using a Z series motherboard.)

At a certain point the motherboard stopped recognizing DEL at the "Press DEL to enter BIOS" prompt. Mr. Google revealed that many people were forced to reset their motherboard to restore this, which I wasn't crazy about. I have an old PS/2 keyboard, with which the motherboard did recognize the key, but I preferred the modern USB keyboard. Fortunately the GRUB bootloader has an option for "system setup," which takes you back into the UEFI/BIOS.

I also set up a prettier GRUB splash screen (the Orion Nebula). I ended up changing several settings in /etc/default/grub, including GRUB_TIMEOUT, GRUB_BACKGROUND, and GRUB_GFXMODE. After updating /etc/default/grub it's necessary to sudo update-grub for it to take effect.

I encountered a race condition that prevented Dropbox from connecting at system startup. Mr. Google pointed me to a solution, and I added these lines to my startup shell, which stop and restart Dropbox:

# work-around dropbox/dbus bug 
#
( sleep 2; dropbox stop && dbus-launch dropbox start) &

Several times I needed to register the new computer with a service (Google and Dropbox come to mind.)

Something odd was happening with the audio. The monitor (also new) was connected to the computer via a DisplayPort connection, but there was no audio unless I fussed with the entirely separate "PC  audio" ports, disconnecting and reconnecting them. I eventually discovered that the monitor sensibly was expecting its audio through the DisplayPort cable, but the pulseaudio software on Linux was somehow defaulting to "PC audio" until some external event forced it to reconsider its options. The easiest thing for me to do was to change the monitor settings so that it used the "PC audio" instead.

Eventually I'll write the performance tuning post, discussing overclocking, changing voltages, torture testing, and cooling the CPU. It takes time to collect all that data!

Juno's Final Upgrade

Juno, my desktop computer, started out in early 2010 with a 40 gigabyte (GB) solid state drive (SSD) to hold the operating system, and a 500 GB hard drive to hold everything else. (An SSD is much faster than a regular hard drive.) About 2½ years later, I upgraded Juno to a 128 GB SSD (Samsung 830), putting aside the 40 GB drive (an Intel X25-V). Now the SSD could hold my personal files as well, excepting all the photos and videos, which still resided on the hard drive (Hitachi 2.5" 7200 rpm). This further improved Juno's peppiness. In early 2014 I moved Juno into a new case, just for the purpose of taking up less room on my desk.

Juno is equipped with 4 gigabytes of RAM (main memory). This was plenty starting out six years ago, but now, when I have my email program, web browser, thumbnail viewer, and photo editor running, they don't all fit into memory at the same time. A process called "swapping" takes place; the operating system (Linux in this case) picks something residing in memory that hasn't been active for a while and copies that to the hard drive, freeing up RAM for the program that needs more memory.

Swapping slows everything down. Badly. Click to bring a program to the front, and hear the little hard drive chittering away as it writes stuff out to make room for that program, and fetches the previously swapped-out program. Sometimes it can take 10 seconds.

I decided to experiment with reusing the old 40 GB SSD as the swap drive. In the early days this was discouraged, because it could lead to premature wearing out of the SSD. However, because Juno swaps only during peak loads, and because I anticipate needing only a year of service before building a fresh computer, I decided to go ahead. The alternative, buying more RAM, would have been more expensive and much more work -- disconnecting cables from the motherboard, removing the motherboard, and then removing the heatsink from the motherboard to access the RAM slots. Ugh.

Juno has one available SATA connector on the motherboard which could accomodate the SSD, but the interior of the computer is cramped after the transplant to the new case. I decided to use the external SATA port (eSATA) of the computer, and place the SSD in an enclosure to connect it in a tidy fashion. I chose one from Oyen Digital, which comes with any cable I might conceivably need, and ordered from Amazon.

Here is the opened box. In case you need lots of oomph, a wall-wart AC adapter is also included.

Here the old SSD has been inserted into the tray that pulls out of the adapter's housing.

It didn't work at first. After spending some time trying alternatives, including using a spare 2.5" HDD instead of the SSD, I finally figured out two things. First, the eSATA cable isn't carrying power, so I had to additionally plug in the supplied USB to DC-in cable. Second, although there was stuff on the SSD, an icon for it did not appear on the desktop even when the power issue was resolved. Disk drives and thumb drives plugged into the USB ports result in desktop icons, but the eSATA port apparently does not. Once I figured out that the lack of an icon didn't indicate a problem, everything began to work. Here's a view of the back of the enclosure, with the two cables.

This is how it looks from the front. The little box on top is the enclosure; its blue LED light is a power indicator.

When all goes well and the swapping takes place on the SSD instead of the HDD, a heavy-swapping situation induces a silent, 1 or 2 second lag instead of 10 seconds of disk chatter. That's pleasing. However, after a day I ran into problems.

Inspecting the system log (/var/log/syslog), I could see that sometimes the connection was established at full speed (3.0 Gbps). Just as often, however, Juno would back down to 1.5 Gbps. This wasn't fatal, but it was odd.

Then, while shorter sleeps ("suspend to RAM") appeared to work OK, the overnight sleep was a problem. (Interestingly, the LED indicated that the SSD had power even while the computer was asleep.) The connection to the external SSD would suffer several timeouts, and when the computer finally came up, the Internet connection was down. That should be unrelated, but a consistent coincidence isn't a coincidence, is it? 

I found messages that indicated some kind of SSD corruption; for example, the serial number of the SSD came out wrong -- it looked like a fragment of a pathname. I performed a factory reset with the command "hdparm --yes-i-know-what-i-am-doing --dco-restore /dev/sdc" and then the data from "smartctl --info /dev/sdc" looked sane again. However, I still had the problem the next morning.

It was time for step-by-step testing.

Test #1: turn off and remove the external device. Overnight wakeup is OK.

Test #2: install external device, but don't power it up. Overnight wakeup is OK, as you would expect.

Test #3: power up external SSD, but don't use it for swap or anything else.

At power-on:

Mar  6 14:32:43 juno kernel: [38604.492274] ata4: irq_stat 0x00000040, connection status changed
Mar  6 14:32:43 juno kernel: [38604.492278] ata4: SError: { PHYRdyChg CommWake LinkSeq TrStaTrns DevExch }
Mar  6 14:32:43 juno kernel: [38604.492286] ata4: hard resetting link
Mar  6 14:32:44 juno kernel: [38605.328024] ata4: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
Mar  6 14:32:44 juno kernel: [38605.328241] ata4.00: ATA-7: INTEL SSDSA2M040G2GC, 2CV102M3, max UDMA/13
Mar  6 14:32:44 juno kernel: [38605.328245] ata4.00: 78165360 sectors, multi 1: LBA48 NCQ (depth 31/32)
Mar  6 14:32:44 juno kernel: [38605.328478] ata4.00: configured for UDMA/133
Mar  6 14:32:44 juno kernel: [38605.328506] ata4: EH complete

After overnight sleep: everything was OK!

Test #4: activate the SSD as a swap device, and don't turn it off overnight. (I reduced the size of the swap area from the entire 40 GB to 12 GB, just in case it was too much. Twelve is still 50% larger than the swap area on the hard drive.)

Everything is OK! Hmm. Also, there has been no resetting the link down to 1.5 Gbps from 3.0. Perhaps the factory reset on the SSD followed by turning it off and back on fixed something?!

Test #5: turn off the HDD swap device, "swapoff /dev/sdb1," so that the SSD is the only swap device. Overnight? Still OK!

This will probably be Juno's last upgrade -- six years is a long time in the computer world. The next project will be to build a new one.

Upgrading Juno

Towards the end of 2012 I upgraded my desktop computer, Juno, in several ways. I replaced the original solid-state drive (SSD) with a larger, newer one, I upgraded the BIOS, and I took a two-year leap in the software installed.

SSD swap

Juno was constructed with an Intel X25-V, a value-oriented 40 gigabyte SSD.

This device was large enough to hold the operating system (Linux) and applications, but all my user data was stored separately, on a regular spinning-platter hard drive. SSD drives were and are more expensive than regular hard drives, although now not so much as 3 years ago. Having the operating system and apps on the SSD made Juno fast to boot and fast to launch applications.

My choice to replace it was a Samsung 830, the 128 gigabyte version.

With this size, I could keep not only the operating system and applications on the SSD, but also all my user data except the extensive photograph folder, which remains on the hard drive. The Samsung device, being of a newer generation and not designed as a "value" item (not compromised to reduce cost) is, according to the specs, three times faster reading data and ten times faster writing data than the X25-V.

Fortunately, I also discovered while researching which SSD to purchase that SSDs using the new SandForce controller (interface between the SSD memory and the rest of the computer) did not play well with the I/O chip on my motherboard, the Nvidia MCP79. Many SSDs such as Intel, Corsair, and others now use the SandForce controller.

The MCP79 supports device speeds of 1.5 Gb/sec and 3.0 Gb/sec. (The newer SSDs also support 6.0 Gb/sec.) When the MCP79 negotiates the connection speed with a SandForce controller, they end up using the 1.5 Gb/sec setting instead of 3.0 Gb/sec! The Samsung SSDs use a Samsung controller and have no such problem. This, plus the excellent reviews of the 830, made the choice an easy one.

When I took the faceplate off Juno, it was clear that the dust filter needed to be cleaned again.

A dust vacuum wasn't sufficient; I ended up removing the filter and washing it.

Juno is constructed with the SSD installed in a drive bay underneath the optical (CD/DVD) drive. Thus, the first step was to remove the tray for the drive and disconnect the cables.

Here we see the Intel X25-V still in the drive bay.

Installing the Samsung was just a matter of removing the Intel (4 screws) and sliding in the Samsung, reinserting the 4 screws and reattaching the cables. By then the filter was dry, and I could reassemble Juno.

The upgraded system is certainly snappier than before. I'm pleased with it.

BIOS Upgrade

My motherboard, the Zotac gf9300-i-e, theoretically supported both methods of chatting with bulk storage devices such as hard drives and SSDs. The ATA specification is the much older of the two, and to support advanced features of newer hard drives and of SSDs there is the newer AHCI interface. However, when first building Juno, it became clear that the AHCI option didn't work. In fact, if I enabled AHCI in the motherboard's BIOS (embedded firmware), the computer would no longer see any of the attached devices: no hard drive, no SSD, no CD/DVD drive. Urk! I proceeded in ATA mode, which seemed to work well enough.

After swapping the SSDs I decided to try AHCI mode again. Same result, very disappointing. However, this time I stumbled across a Zotac forum posting mentioning a BIOS upgrade that had come out a few months after I assembled Juno, which solved this problem. There were some technical hurdles to overcome -- this motherboard, unlike some others, won't recognize a BIOS upgrade automatically if a USB stick is plugged in -- but eventually I applied the new BIOS, and voilá, AHCI mode was good! 

Installing XUbuntu 12.10

I had ceased installing newer versions of Ubuntu, sticking with 10.10, because of the controversy over the new default user interface, Unity, and the changes in the GNOME desktop between version 2 and 3. I was happy with my GNOME 2.x desktop, and 10.10 was supported with updates and security patches for 18 months. Then those stopped. After two years on 10.10, Juno's software was showing its age and some new software packages would not install.

I had played around with some other packages on my ancient laptop, primarily LMDE (Linux Mint Debian Edition) with its Cinnamon and Mate desktops. But I wasn't completely pleased with Cinnamon or Mate, which were efforts to maintain a pre-Unity desktop environment. Finally I went with XUbuntu, which is an Ubuntu distribution that also installs a more traditional and lightweight desktop manager, xfce. I have a few quibbles with it, but xfce was my best fit.

Here are some miscellaneous points I noticed:

• The system will now wake up from sleep (suspend to RAM) when I press any key on the keyboard. Previously I had to push the power button. Hurrah!
• xfce can use either xfwm4, the standard xfce desktop compositor, or compiz, a fancier one. (Desktop compositors manage visual issues such as overlapping windows, partially transparent windows, wobbly windows, multiple workspaces, etc.) I finally decided that xfwm4 was more stable; occasionally windows would go black under compiz. I was willing to give up my wobbly windows for reliability.
• Some of the programs I use on a regular basis, such as the GIMP, an open-source Photoshop, were not installed by default. They can still be installed from the Ubuntu repositories, so it's not a large issue.
• LibreOffice, as distributed by Ubuntu, would crash on some of the spreadsheets I had created in the Ubuntu 10.10 environment. I filed a bug report, and it may be fixed in the next release. In the meantime, I installed OpenOffice, which worked just fine. Because of a file name conflict, I had to remove LibreOffice before I could install OpenOffice.
• The xfce desktop has, unfortunately, a mandatory snap-to-grid feature. That is, any icons/documents placed on the desktop are automatically lined up to use the center of one square of an invisible checkerboard dividing the desktop. I wish I could turn it off, as I could in GNOME 2.x. But I don't have very many desktop items anyway, so it's just an annoyance rather than an impedance to my workflow.
• The version of the C++ compiler supplied jumped forward two years as well. One of my programming projects would crash until I changed some global constructor usages that had worked OK with the older compiler.
• The audio/video command-line program ffmpeg is now deprecated, and a couple of the arguments have changed. The new version fails on some of my video projects where the old one did not -- arrgh! However, the program avconv, the immediate descendant of ffmpeg, did work. It leaves me wondering how or why the maintainers managed to break ffmpeg.

Going Forward

This is probably the end of the Juno upgrades. If it were inexpensive, I would increase the memory (RAM) from 4 GB to 8 GB, because sometimes when working on blog entries (many tabs open on the Web browser) and processing photos or videos Juno starts to swap (move some programs to disk to make room for other programs to run). This slows things down. However, this motherboard takes an obsolescent memory, DDR2-800, which is pricey when available. Perhaps next fall or winter I will build my next computer based on the upcoming Haswell generation of Intel CPUs, and I'll put 16 GB of memory in it. That would be enough RAM to allow me to experiment with virtual machines.