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.