Roo – Page 63 – Roo's View

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.

You can run, but you can’t hide from the cloud

Excited about my new Android based phone, I wanted to get it setup with my address book.

Now, one of my criteria for a cell phone is to be able to sync my contact information with a computer. My Nokia 6585 supported irDA and could sync with my thinkpad. When I replaced that phone with the Nokia 5310 I was able to sync over bluetooth. Now I need to figure out how to get the data to and from my G1.

By default, the answer with an Android handset is to use Gmail Contacts. Android is setup to guide you down the path of full Google integration, even asking you to setup the association during the phones initial setup. Initially I wanted to avoid this route as I run my own mail server and prefer to keep my data on servers that I own (its a hobby, I know its the hard path). I figured it couldn’t be that hard to sync the phone to my Ubuntu desktop.

One solution that looked possible was Funabol. I may still play with this, but before I even got to the point of setting up a synchronization server I ran into the problem of moving my address book data from Windows to Linux. The Nokia PC Suite let me store all of my contacts into the Windows Address Book, and iTunes could also sync with this so my contacts were all on my iTouch. It should be a simple thing to take the Windows Address book and move it into Linux right?

There were two problems.

Windows Address book has a death grip on your data and won’t export it into a useful format.
Linux has no reasonable address book story, Evolution seems to be close – but it won’t easily import anything that Windows will export.

The solution turned out to be Google. iTunes will happily sync to Google contacts. Evolution will also sync to Google contacts.
Setting up iTunes with your Google account is straight-forward. You just choose Google Contacts, punch in your credentials and away you go. As my iPod Touch had lots of contact information and my Gmail account had very little, the large scale change was detected – and I was given the choice to over-write or merge (I wanted to merge). Once the data was in Gmail, going into the Settings on the G1 and configuring the Data synchronization for Contact information let the bits flow down to my new phone.

It turns out Google has the best Linux friendly address book, better than any of the stand-alone solutions I looked at. Today the cloud won.

How to: resize a mirrored volume

by lindztrom

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.