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.

Mirrored Drives with Ubuntu

Mirrored drives are also known as a RAID 1 configuration.  It is important to note that running mirrored drives should not be used as a substitute for doing backups.  My motivation for running a RAID 1 is simply that with the drive densities today, I expect these drives to fail.  A terabyte unit is cheap enough that multiplying the cost by two isn’t a big deal, and it gives my data a better chance of surviving a hardware failure.

I purchased two identical drives several months apart – in the hopes of getting units from different batches. I even put them into use staggered by a few months as well.  The intent here was to try to avoid simultaneous failure of the drives due to similarities in manufacture date / usage.  In the end, the environment they are in is probably a bigger factor in leading to failure but what can you do?

Linux has reasonable software raid support.  There is a debate of the merits of software raid vs. hardware raid, as well as which level of raid is most useful.  I leave this as an exercise up to the reader.  The remainder of this posting will be the details of setting up a raid 1 on a live system.  I found two forum postings that talked about this process, the latter being most applicable.

We will start with the assumption that you do have the drive physically installed into your system.  The first step is to partition the disk.  I prefer using cfdisk, but fdisk will work too.  This is always a little scary, but if this is a brand new drive it should not have an existing partition table.  In my scenario I wanted to split the 1TB volume into two partitions, a 300Gb and a 700Gb.

Now let’s use fdisk to dump the results of our partitioning work:

$ sudo fdisk -l /dev/sdd

Disk /dev/sdd: 1000.2 GB, 1000204886016 bytes
255 heads, 63 sectors/track, 121601 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0x00000000

Device Boot         Start         End      Blocks   Id  System
/dev/sdd1               1       36473   292969341   83  Linux
/dev/sdd2           36474      121601   683790660   83  Linux

Next we need to install the RAID tools if you don’t have them already:

$ sudo apt-get install mdadm initramfs-tools

Now recall that we are doing this in a live system, I’ve already got another 1TB volume (/dev/sda) partitioned and full of data I want to keep. So we’re going to create the RAID array in a degraded state, this is the reason for the use of the ‘missing’ option. As I have two partitions I need to run the create command twice, once for each of them.

$ sudo mdadm --create --verbose /dev/md0 --level=mirror --raid-devices=2 missing /dev/sdd1
$ sudo mdadm --create --verbose /dev/md1 --level=mirror --raid-devices=2 missing /dev/sdd2

Now we can take a look at /proc/mdstat to see how things look:

$ cat /proc/mdstat
Personalities : [raid1]
md1 : active raid1 sdd2[1]
683790592 blocks [2/1] [_U]

md0 : active raid1 sdd1[1]
292969216 blocks [2/1] [_U]

unused devices: <none>

Now we format the new volumes. I’m using ext3 filesystems, feel free to choose your favorite.

$ sudo mkfs -t ext3 /dev/md0
$ sudo mkfs -t ext3 /dev/md1

Mount the newly formatted partitions and copy data to it from the existing drive. I used rsync to perform this as it is an easy way to maintain permissions, and as I’m working on a live system I can re-do the rsync later to grab any updated files before I do the actual switch over.

$ sudo mount /dev/md0 /mntpoint
$ sudo rsync -av /source/path /mntpoint

Once the data is moved, and you need to make the new copy of the data on the new degraded mirror volume the live one. Now unmount the original 1TB drive. Assuming things look ok on your system (no lost data) now we partition that drive we just unmounted (double and triple check the device names!) and format those new partitions.

All that is left to do is add the new volume(s) to the array:

$ sudo mdadm /dev/md0 --add /dev/sda1
$ sudo mdadm /dev/md1 --add /dev/sda2

Again we can check /proc/mdstat to see the status of the array. Or use the watch command on the same file to monitor the progress.

$ cat /proc/mdstat
Personalities : [raid1]
md1 : active raid1 sdd2[1]
683790592 blocks [2/1] [_U]

md0 : active raid1 sda1[2] sdd1[1]
292969216 blocks [2/1] [_U]
[>....................] recovery = 0.6% (1829440/292969216) finish=74.2min speed=65337K/sec

unused devices: <none>

That’s all there is to it.  Things get a bit more complex if you are working on your root volume, but in my case I was simply mirroring one of my data volumes.