Core i3 frugal upgrade

When I was a teenager and into my early 20’s my computer gear was always bleeding edge.  If I had forgone most of the computer gear, I probably could have had a car during university – but having the coolest setup was what it was all about. Once I started work full-time, my work supplied hardware far outpaced what I could justify at home. Somewhere between then and my 30’s I lost the drive to have the coolest stuff and got by with trailing edge gear. Until recently my desktop was a refurbished Celeron 3.06GHz machine that I picked up a couple of years ago for $200.

The issue is that even a horribly dated machine can still run everything you need, just not very fast. Especially given that your average home computing is about surfing the web and maybe some simple file management (let’s ignore the gamer machine which is a totally different story). Having recently upgraded Jenn to a dual core iMac, and also getting a dual-core laptop for work – the celeron was feeling really slow. The straw that broke the camels back was the insanely poor performance of iTunes under VMWare hosting WindowsXP.

Trent had pointed me at techreport.com, specifically the system guide as a good source for reviews and advice. I had initially thought I’d get an AMD based system until the introduction of the lower cost Core i3 early this year. After some extensive online pricing/shopping I settled on a very frugal upgrade plan.

$129.77 Intel Core i3
$114.99 Gigabyte GA-H55M-USB3
$53.77 2GB DDR3 1333MHz (1 stick)
$54.99 Corsair CMPSU-400CX 400W Power Supply
$42.99 Cooler Master Elite 335 Black ATX Mid Tower Case

Total: 396.51 + 51.55 tax

Initially I had planned to re-use the current mid-tower case my celeron system was in, however the front panel plug connectors were not compatible and I didn’t want to start splicing wires to hack things to fit. (Leaving the case intact, gives me a completely functional but slower machine to pass on)

At the top of this post the picture is a close up of the i3 chip installed on the motherboard prior to the installation of the CPU heat sink/fan. If you haven’t built a system from the ground up previously, it may look complicated but its really quite simple. I chose to install the CPU/heat sink prior to installing the motherboard into the case.

Some of my friends teased me for only going with 2GB of RAM, but with my Ubuntu based desktop and my usage (even with VMWare hosting WindowsXP) I rarely use even half of my RAM. I do plan to upgrade to more in the future (6GB or more) but I’m waiting for the price of DDR3 to drop to a reasonable cost. The single 2GB stick was cheaper than some of the 2x1GB options and provides the most flexibility for later upgrades.

The power supply was a bit of a pleasant surprise. It came with cable ties, nylon sleeved cables, and a power cord. This power supply is also 80+ certified which was one of my requirements for a new power supply. The single large fan keeps the noise level to a minimum.

My motherboard selection was based primarily on the techreport.com recommendation.  However, this is one of the few USB3.0 capable motherboards that offers integrated graphics support (when used with i3 or i5 processors).  It has 4 slots of DDR3 memory (up to 16GB), Gigabit ethernet, PCI Express x16, IDE and SATA support as well as external SATA. This is a great foundation for my new system allowing plenty of future expandability.  The only feature I noticed it was missing was SATA3.

Future upgrades will be to add a graphics card, a large SATA drive and of course more RAM. Looking further into the future, I may consider upgrading to an i7 when the prices drop. While this is still a budget system, it has legs and I’m back on the leading edge for a short while.

Ubuntu on Core i3

I wanted to document my upgrade success to an Intel Core i3 based system, this will focus on running Ubuntu on this hardware configuration. The hardware is very simple: Gigabyte GA-H55M-USB3 with Intel Core i3, in general terms I followed the recommendations from techreport.com for their econobox.

I was pleased that after assembly the box booted on the 1st try! Having simply moved my drive over from my previous system, I was running an up to date 32-bit Ubuntu 9.10 system. I started to exercise the box and after about 30mins got my first hang. The hang was a bit odd, the keyboard stopped working (numlock didn’t work) and the graphics froze. I was able to ssh into the box and issue a reboot. The hangs persisted, and seemed more frequent.

It turns out upgrading to Lucid Lynx (Ubuntu 10.04) was the solution to the following bug report. There was a problem with the drive for the on-board graphics which the later versions of the kernel contain updated drivers. It seems that I’ve gone from having trailing edge hardware to bleeding edge hardware. Upgrading was simple – hit ALT-F2 and enter “update-manager -d” (no quotes), the -d flag allows you to upgrade to the latest development release.

The next stumbling block was that suspend and hibernate didn’t seem to work. Fortunately someone in the forums had already solved this problem. The USB3.0 support seems to not quite be suspend friendly, so you can optionally disable it in the BIOS or modify your Lucid configuration as follows – create a script /etc/pm/sleep.d/05_xhci that contains:

#!/bin/sh
# Fix some issues with USB3

case "$1" in
hibernate|suspend)
modprobe -r xhci
;;
thaw|resume)
modprobe xhci
;;
*)
exit
;;
esac

and set the permissions appropriately (chmod 755). Now when the system goes to sleep, it will disable USB support and re-enable on resume (or hibernate).

Now that I had the system going to sleep, I wanted to be able to wake it up. The Gigabyte BIOS provides an option to wake up via PS/2 keyboard by typing in a password. I also wanted to have wake-on-lan (WOL) working, something I’ve posted about previously. The new motherboard needed new magic to enable WOL.

First use lspci to find the address of the ethernet contoller:

$ lspci -tv
+-1c.1-[0000:03]----00.0 Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller

Then match that to the contents of /proc/acpi/wakeup

$ cat /proc/acpi/wakeup
Device S-state Status Sysfs node
PCI0 S5 disabled no-bus:pci0000:00
PEX0 S5 disabled pci:0000:00:1c.0
PEX1 S5 disabled pci:0000:00:1c.1 <- this one!
PEX2 S5 disabled
PEX3 S5 disabled
PEX4 S5 disabled
PEX5 S5 disabled
PEX6 S5 disabled
PEX7 S5 disabled
HUB0 S5 disabled pci:0000:00:1e.0
UAR1 S3 disabled pnp:00:07
USB0 S3 disabled pci:0000:00:1d.0
USB1 S3 disabled pci:0000:00:1d.1
USB2 S3 disabled pci:0000:00:1d.2
USB3 S3 disabled
USB4 S3 disabled pci:0000:00:1a.0
USB5 S3 disabled pci:0000:00:1a.1
USB6 S3 disabled pci:0000:00:1a.2
USBE S3 disabled pci:0000:00:1d.7
USE2 S3 disabled pci:0000:00:1a.7
AZAL S5 disabled pci:0000:00:1b.0

So my new /etc/init.d/wakeonlan file looks like:

#! /bin/sh
### BEGIN INIT INFO
# Provides: wake on lan
# Required-Start: $network
# Required-Stop:
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
# Short-Description: Configures WOL
# Description: Configures Wake-On-Lan
### END INIT INFO
#
ethtool -s eth1 wol g
echo PEX1 > /proc/acpi/wakeup

If you want to understand WOL in more detail, please review my previous post on the topic.

The last thing I needed was to make VMWare Player happy. During its normal detect a new kernel level and re-install itself process, I encountered an error:

Apr 17 12:07:23.497: app-3079280320| Building module vmnet.
Apr 17 12:07:23.497: app-3079280320| Extracting the sources of the vmnet module.
Apr 17 12:07:23.556: app-3079280320| Building module with command: /usr/bin/make -C /tmp/vmware-root/modules/vmnet-only auto-build SUPPORT_SMP=1 HEADER_DIR=/lib/modules/2.6.32-21-generic/build/include CC=/usr/bin/gcc GREP=/usr/bin/make IS_GCC_3=no VMCCVER=4.4.3
Apr 17 12:07:29.384: app-3079280320| Failed to compile module vmnet!

The above is a snippet from the log file and it indicates a problem with the network module. Again, someone else had run into the problem and provided a solution. This worked fine for my VMWware Player version 3.0.0 build-203739.

The system has been stable over the last couple of days, if I run into any serious problem I will revise this post.

How to: resize a mirrored volume

Having recently setup mirrored volumes with a pair of 1TB drives, I could now migrate data off the pair of 250Gb data drives to allow me to combine those two drives into a single volume.  Way back when I purchased these drives I had intended to run a mirrored setup, but at the time decided that having more storage was more important.  I had “cleverly” purchased two 250Gb drives from different manufacturers, in theory to avoid concurrent failures.  It turns out that not all 250Gb drives are made the same.

Following the instructions from my previous posting, all went well up to where I tried to add the 2nd volume to the mirrored set.  If you run into a similar problem you’ll likely see one of the two following errors:

mdadm: add new device failed for /dev/hda1 as 2: No space left on device
mdadm: add new device failed for /dev/hda1 as 2: Invalid argument

I found some good hints on how to diagnose the problem, it turns out you can check the partition sizes manually

$ cat /proc/partitions
major minor  #blocks  name

8    17  244196001 sdb1
8    65  244198552 sde1

Close, but not quite the same.  As it was, I had unluckily chosen /dev/sdb as the 1st drive in the mirrored set.  It turns out that fdisk tells an even more interesting story.

$ sudo fdisk -l /dev/sdb

Disk /dev/sdb: 250.0 GB, 250059350016 bytes
255 heads, 63 sectors/track, 30401 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0x000c0f4f

Device Boot Start End Blocks Id System
/dev/sdb1 1 30401 244196001 83 Linux

$ sudo fdisk -l /dev/sde

Disk /dev/sde: 250.0 GB, 250059350016 bytes
16 heads, 63 sectors/track, 484521 cylinders
Units = cylinders of 1008 * 512 = 516096 bytes
Disk identifier: 0x00000000

Device Boot Start End Blocks Id System
/dev/sde1 1 484521 244198552+ 83 Linux

Yuck, looks messy. At this point I’ve got some of my live data sitting on one half of the mirrored set, and no suitable 2nd drive to act as the mirror.  Somewhat predictably there is a solution that minimizes downtime and avoids copying all of the data to a new location.

First you unmount the volume and run resize2fs on it.  We don’t need to know the correct size, just any size smaller than the 2nd volume – so I used 200Gb.

$ sudo umount /media/data/
$ sudo e2fsck -f /dev/md2
e2fsck 1.40.8 (13-Mar-2008)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
/dev/md2: 1890279/15269888 files (0.2% non-contiguous), 32742192/61049616 blocks
$ sudo resize2fs /dev/md2 200G
resize2fs 1.40.8 (13-Mar-2008)
Resizing the filesystem on /dev/md2 to 52428800 (4k) blocks.
The filesystem on /dev/md2 is now 52428800 blocks long.

Now we need to calculate what the correct size of the mirrored partition should be. I looked at two bits of data: the size the mdadm -D reported for the partition I wanted to resize, and the size that was in /proc/partitions for the same. These differed by 88 blocks, so I used the value 88 as a fudge factor – it may not be required but it worked for me. I then also ensured that I supplied a value that was an even multiple of 64 (blocks).

So starting with 244196001 from /proc/partitions:

(244196001 - 88) / 64 = 3815561.14

Drop the decimal places and multiply by 64 to get the number of blocks.

3815561 * 64 = 244195904

Now we feed this new size into mdadm and specify the –grow flag (which can also be used to shrink if you specify a block size smaller than the current which is what we are doing in this case).  We then re-run resize2fs without a specified size, which will cause it to expand the filesystem to fill the partition.

$ sudo mdadm --grow /dev/md2 --size=244195904
$ sudo resize2fs /dev/md2
resize2fs 1.40.8 (13-Mar-2008)
Resizing the filesystem on /dev/md2 to 61048976 (4k) blocks.
The filesystem on /dev/md2 is now 61048976 blocks long.

Now all that is left is to run a filesystem check, and remount it.

$sudo e2fsck -f /dev/md2
e2fsck 1.40.8 (13-Mar-2008)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
/dev/md2: 1890279/15269888 files (0.2% non-contiguous), 32742192/61048976 blocks
$ sudo mount -a

Now when you attempt to add the 2nd volume, it will be a matching size and the mirror will work.  In the future, I intend to be a little more careful when I plan to setup mirrored drives and pick the smaller volume as the starting point.