As far as I know, you need the Linux 3.0 kernel or later to boot via UEFI, which means you’ll need to be using at least Ubuntu 11.10. All of the current 64-bit Ubuntu (11.10) ISO images seem to boot fine via UEFI, so I booted the desktop disc as a “live CD” for many of these operations.

If you have a standard Ubuntu installation, your disk has just two partitions: one for the file system and one for swap space. In my case, these were /dev/sda1 (ext4) and /dev/sda5 (swap). The disk itself is partitioned using the MBR method.

To switch to UEFI, you’ll have to convert the disk’s partition table from MBR to GPT. This can be done non-destructively using gdisk. You can install it from the “Universe” repository in Ubuntu (here’s the package page), if you’ve booted from the Ubuntu Lice CD, you’ll have to enable this repository. Once you launch gdisk from the terminal, you tell it which disk you’re interested in (/dev/sda in my case) and it will proceed with the conversion from MBR to GPT automatically — you’ll just need to tell it to write changes and quit. GPT actually stores two copies of the partition table on the disk, and gdisk will want to put one at the front and one at the end. For me, it complained that there was no room after the last partition on my disk to store the second partition table, so I had to open GParted and shrink my swap partition a little.

After the conversion to GPT, you’ll notice that there are some small gaps between your partitions. The reason for this is explained in more detail here, but, you can use GParted to move and resize the partitions to your liking after the conversion is done.

Now, UEFI systems need a special boot partition to hold the UEFI boot loader for your OS, called the EFI system partition, or ESP. (It can actually hold several different boot loaders, making multi-booting considerably more simple than before.) Create a 20 MB FAT16 partition at the start of the disk, and use the GParted flag management to enable the “boot” flag. I don’t think that this new partition necessarily has to be the first one on the disk, but I’m just copying the partition structure that you get from installing Ubuntu on a UEFI system from scratch. Make sure you use the “MiB” alignment option when messing with the partitions to keep them aligned properly if you have an SSD, “advanced format” 4K-sector drive, or RAID setup.

After the conversion to GPT, I had two partitions on the disk: /dev/sda1 (ext4) and /dev/sda2 (swap). When I added the FAT16 partition at the front, it was labeled /dev/sda3 even though it was the first partition on the disk.

Now, the conversion to GPT is done and the ESP has been set up. All that’s left is to reinstall grub so that it can boot your machine. First, install the grub-efi package. This will remove the grub-pc package, and allow us to install grub without having it freak out because your disk is not partitioned with MBR.

The following commands did it for me… you may have to adjust them if your partitions are labeled the same as mine.

sudo mount /dev/sda1 /mnt # Mount the root filesystem in /mnt
sudo mkdir /mnt/boot/efi # Create a directory to mount the ESP in
sudo mount /dev/sda3 /mnt/boot/efi # Mount the ESP
sudo grub-install --root-directory=/mnt /dev/sda # Run the grub install

When you’re done, you should be able to check the ESP (in /mnt/boot/efi) to see that the boot loader has been placed there — EFI/ubuntu/grubx64.efi.

Then, reboot and it boots! Depending on your motherboard’s UEFI implementation, you may have to point it to the Ubuntu boot loader the first time (EFI/ubuntu/grubx64.efi). Also, the first time I booted after the conversion, some errors popped up on the screen but the system still came up properly. Subsequent boots did not have any errors, so I’m not quite sure what that was about.

Be sure to install the grub-efi package on your main system too, so that if an update comes along that requires updating grub, it works properly.  Also, I actually ended up deleting and re-creating the swap partition during this process, so its UUID changed.  You may want to check your /etc/fstab file and make sure the UUIDs still match up with your partitions.

Resources:

• http://www.rodsbooks.com/gdisk/ — the gdisk page has a lot of useful information about GPT/UEFI
• http://www.thinkwiki.org/wiki/UEFI_Firmware — a wiki page that describes the process of installing grub for booting via UEFI
• https://gitorious.org/tianocore_uefi_duet_builds/pages/Windows_x64_BIOS_to_UEFI — a page which discusses a similar migration for a Windows system, which has some additional useful information

In fact, you can even mount a Windows share on Linux pretty easily using Samba, and use Samba to create shares that the Windows machines can access.

Now, a cool thing about SFTP over SSH is that it typically works even if the machines aren’t on the same LAN.  You can access files on a machine across the Internet, and still mount the share so that applications can access the files as if they were local.  This doesn’t always work with SMB, as lots of ISPs block the ports required, and even if you can get a connection over the Internet, performance is usually poor.

Wouldn’t it be cool if you could mount a remote SFTP server as a drive letter in Windows?  That’s what I was looking for.  I’ve looked around for applications that provide this functionality in the past, but never found one that worked reliably and on 64-bit Windows.  However, the other day, I came across ExpanDrive, which seems to fit the bill.

Not only does this nifty app allow you to map a remote SFTP share to a drive letter, but it handles reconnecting after sleep/hibernate and changing locations very well.  Couldn’t be happier.  Setting it up is really easy, you just will out this form with information about the server and which drive letter you would like to use:

…and then, your files are immediately available under “My Computer.”

The only bad thing is, the application will set you back $40.  There is a trial version though, to let you see if it meets your needs.  Licenses are sold on a per-user basis, so you only have to buy one to use it on all of your machines.

Let me know if you know of any applications that do as good a job for less (or no) money!

I recently replaced the machine that powers this very web site with a better one.  This was my first migration since switching to Ubuntu Server last winter.  I essentially took the hard drive out of the old machine and plopped it in the new one, booted it up, and hoped for the best.  Since Linux is not as picky as Windows about being moved to a new set of hardware, I figured it would work out fine.

Sure enough, Ubuntu booted right up on the new machine without so much as a complaint.  However, network connectivity was gone.  The old machine was using a PCI Ethernet card, while the new machine had an on-board controller that I hoped to use.  Anyway, I took the PCI card from the old machine and put it in the new machine, and then the network connectivity was back.

Why wouldn’t Ubuntu just start using the on-board controller, though?

Well, it turns out Ubuntu Server, in its default configuration, remembers which MAC address goes with which Ethernet device.  (This as opposed to the default configuration on the desktop version, where NetworkManager handles this dynamically.)  This information is stored in /etc/udev/rules.d/70-persistent-net.rules, and looks something like this:

# This file was automatically generated by the /lib/udev/write_net_rules
# program run by the persistent-net-generator.rules rules file.
#
# You can modify it, as long as you keep each rule on a single line.

# PCI device 0x8086:0x1229 (e100)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="xx:xx:xx:xx:xx:xx", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"

# PCI device 0x14e4:0x4401 (b44)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="xx:xx:xx:xx:xx:xx", ATTR{type}=="1", KERNEL=="eth*", NAME="eth1"

Here, my old Ethernet card (e100) and my new card (b44) are listed as eth0 and eth1.  In /etc/network/interfaces, I only had a configuration for eth0.  Thus, no network connectivity when that card was not present.

The solution is simply to modify /etc/udev/rules.d/70-persistent-net.rules so that the card you want is eth0, or to add an appropriate configuration for eth1 in /etc/network/interfaces.  Of course, the entry in the rules file for the adapter that is no longer present should be commented out or erased. Anyway, after making these changes and bouncing the Ethernet kernel modules (or just rebooting the machine), things should work how you like.

I don’t think that this was caused by the kernel update (I even booted up the old kernel to make sure), but some other update that came along recently is probably to blame, and the problem didn’t show itself until I had to log out and log back in.

I don’t use a fancy theme, just the regular default Ubuntu theme.  In this situation, the window borders were still themed properly (although now an ugly blue color, which you can’t see in this screen shot), but the icon set was the default GNOME set no matter which set I chose in the appearence preferences, and most of the controls weren’t themed either (see the bottom-left and top-right of the screen shot).

I thought that maybe something had gone bad in my profile, but I created a new account and it also had the problem, so something had apparently broken system-wide.  This is what makes me suspect that a recent software update is to blame, because I haven’t been poking around in any system-wide stuff on this machine in a while.

I didn’t realize that using the FreeNX server was part of the problem at first, but I finally found some other people who have the same issue this evening, and one of them mentioned this bug report, which mentions another bug report, which has the solution to the problem.  (It doesn’t just affect FreeNX either, some people have the same problem with VNC.)  It turns out that gnome-settings-daemon is crashing, and without it running, the theme is messed up (among other things).  To get it running again, you have to disable its keyboard plug-in.  (I’m not yet sure what you lose by disabling this plug-in, but the keyboard still works even without gnome-settings-daemon running, so what’s there to lose…).

Here’s the solution.

• Run gconf-editor
• Navigate to /apps/gnome_settings_daemon/plugins/keyboard
• Uncheck the “active” box on the right
• Log out and log back in (or manually start gnome-settings-daemon)

There you have it.  This will tie us over until the issue is actually fixed in gnome-settings-daemon.  Maybe, if you are experiencing this issue, you didn’t have to search around for as long as I did to find the solution.

Update: August 5, 2009

There is a new bug report on this issue.

Also, a user reported that the fix above did not work.  I suggest also disabling the mouse plug-in for gnome-settings-daemon (by following the steps above, but going to /apps/gnome_settings_daemon/plugins/mouse instead), since some of the comments in the first gnome-settings-daemon bug report indicated that this was necessary for them to fix the problem.  If that doesn’t help, then something else is causing gnome-settings-daemon to crash… or if it is not crashing, you must have a completely different issue.

Update: September 23, 2009

Reportedly, you can fix this problem by reverting libxklavier to version 3.9-0ubuntu1.