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

My reading seems to indicate that this happens if you upgrade from Ubuntu 10.10 which itself had been upgraded from Ubuntu 10.04, and grub was never reinstalled.

I think it is completely ridiculous that this bug made it all the way to the Ubuntu 11.04 final release — leaving the system unbootable after an upgrade is a disaster.

The easiest way to fix it is to boot from the Ubuntu 11.04 alternate install CD.  Choose the option to “Repair a broken system.”  Go through the prompts and choose which disk has your root file system.

After this, you may have the option to just reinstall grub — if so, do it, and reboot, and your system should be fine.

If that’s not an option, choose to start a recovery shell using your root filesystem and then run the commands

grub-install /dev/sda
update-grub

(possibly adjusting for where your root disk is).  Then reboot and the machine should boot.

If it still doesn’t, go back to the recovery shell and see if your /boot directory is empty (aside from the “grub” directory).  This happened to me on a machine that was set up with LVM.  The /boot folder is actually stored on a different partition and you have to mount it before grub can set itself up right.  Here’s the commands…

rm -Rf /boot/*
mount /dev/sda1 /boot
grub-install /dev/sda
update-grub

Of course, these may need to be adjusted depending on which disk needs grub and which partition contains /boot.  You can use the GUI partition editor on the Live CD to check.

Now, hopefully your machine can boot up.  What a mess.  :-\

Update: May 12, 2011

dzsi posts another way to recover from this situation in the comments below.  This method does not require booting from a CD.

Note that in the commands that follow, “X”, “Y”, and “Z” should be replaced with numbers/letters that represent your boot disk.

At the grub prompt, issue these commands:

set root=(hdX,Y)
linux /vmlinuz root=/dev/sdZ ro
initrd /initrd.img
boot

Your machine should boot up.  Start a terminal and issue these commands:

sudo grub-install /dev/sdZ
sudo update-grub

This should fix grub so that you do not have any boot trouble anymore

Unable to restart Named: dnsmng failed: dnsmng failed: dnsmng: Service /etc/init.d/bind9 failed to restart

(What a great error message.)

Whoops. Turns out there’s a problem with the default Plesk configuration of the DNS server BIND (run it in a chrooted environment) and Ubuntu’s configuration (run it with AppArmor, explicitly configuring which files it is allowed to open). You have to give BIND permission to open the files in its chroot environment. The solution to this problem is to edit the file /etc/apparmor.d/usr.sbin.named and add these lines before the closing brace at the end of the file:

/var/named/run-root/etc/* rw,
/var/named/run-root/var/* rw,
/var/named/run-root/dev/* rw,

Then, reboot the machine and you should be good to go.

The problem: You’ve enabled automatic security update installation, and yet, security updates are not being automatically installed.

First possible solution: This one is easy. Check the file /etc/cron.daily/apt and make sure that it is marked executable. Permissions on this file should look like rwxr-xr-x (755). This file somehow lost its executability when I upgraded from one Ubuntu release to the next, which broke the daily update check and thus no automatic security update installation.

In the more recent occurrence of this problem for me, the daily update check was obviously happening. I would connect to the server via SSH and see something like…

Welcome to the Ubuntu Server!
* Documentation: http://www.ubuntu.com/server/doc

5 packages can be updated.
5 updates are security updates.

So, the daily update check was happening, but the automatic update installation was not. What could cause this?

Well, it turns out that the script that does the update installation will only proceed to that point if the check for updates was successful (no errors at all). This leads us to…

Second possible solution: Run a sudo aptitude update or sudo apt-get update and see if there are any errors. If there are, address them, and hopefully that will resolve the problem. In my case, I had a third-party repository that had become inaccessible, so although the main Ubuntu repositories were updating fine, this error still prevented automatic security update installation.

If you want to know how to set up automatic security updates, there are (at least) three possible ways:

• When first installing the system, you will be given the option to enable automatic security updates.
• Follow the directions on this page in the Ubuntu Wiki. I recommend the apt.conf.d method (which is what will be set up for you using either of the other options presented here), but, the cron method may help you get around other similar issues that prevent automatic updates from working.
• You can set it up using the GUI method like you would with a desktop version of Ubuntu. First, install Synaptic (sudo aptitude install synaptic). Then, make sure that you are connected to your server via SSH with X11 forwarding (by adding the -Y parameter to ssh when you connect). Then, run Synaptic on the server as root (just type “sudo synaptic” at the terminal) and the Synaptic window should appear on your desktop. Then, select “Settings -> Repositories” from the menu, click on the “Updates” tab, and configure automatic updates as you see fit.

Update: November 12, 2010

There is a bug in Ubuntu 10.10 that seems to only affect 32-bit installations but prevents automatic security update installation.  See here for details.  A fix is already available upstream in Debian; hopefully it will be pushed on to Ubuntu users soon.

SQLException: Communications link failure
The last packet sent successfully to the server was 0 milliseconds ago. The driver has not received any packets from the server.
SQLState: 08S01
VendorError: 0

After searching for a while and going through some solutions that didn’t work for me, I found the answer here.  I’m re-posting it because that answer is posted in Spanish. 

All you have to do is open /etc/init.d/tomcat6 in your favorite text editor (as root), find the line that looks like TOMCAT6_SECURITY=yes, and change it to TOMCAT6_SECURITY=no.  Then, restart the Tomcat server (sudo service tomcat6 restart).  Ta da!!  MySQL connections are now working.

Now, there’s probably a better way to do this that doesn’t involve completely turning off “TOMCAT6_SECURITY,” but this seems fine for a small test project which is what I’m working on (it will eventually be deployed on the JBoss server).  I’ll be sure to update this post if I find it… or if you know anything, leave a note in the comments below.

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.