Thursday, February 3, 2011

New Ubuntu 10.04 LTS images with pv-grub support

Yesterday I announced the availability of updated Ubuntu images on EC2 for 10.04 LTS (Lucid Lynx).

This post is mainly to mirror that one to a possibly wider audience, but also to go into more detail on the key change in these images:

You can now upgrade the kernel inside your 10.04 based EC2 image by running 'apt-get update && apt-get dist-upgrade && reboot!

Now, for a little more detail on that.

Around the time that 10.04 released, or shortly there after, Amazon released a new feature of EC2 as "Use Your Own Kernel with Amazon EC2". What this really meant was that there were now "kernels" on EC2 that were really versions of grub. By selecting this kernel, and providing a /boot/grub/menu.lst inside your image, the instance would be in control of the kernel booted. Previously, the loading of a kernel was done by the xen hypervisor, and could not be changed at all for a instance-store image, and only non-trivially for an EBS-root instance

Yes, you read that right, midway through the year of 2010 you were able to change the kernel that you were running in an EC2 instance with a software update and a reboot.

We took advantage of this support in our 10.10 images, but for many people, only LTS (Long Term Support) releases are interesting. So, to satisfy those people, we've brought the function into our 10.04 images.

If you're using our images, or have rebundled an image starting from them, I *strongly* suggest updating to the 20110201.1 images or anything later. You'll want to do that because

  • You can receive kernel upgrades as normal software upgrades to your running instance.
  • This is by far the most supportable route for upgrade from 10.04 to our next LTS (12.04). If your instance is not using the pv-grub kernel, and you want to upgrade to a newer release, you will have to upgrade, shutdown the instance, modify the associated kernel, and start up the instance. That is both more painful, and will result in larger downtime.

So, in short, grab our new images!


  1. So what if I'm already running a 10.04 instance, does "apt-get dist-upgrade" give me this, or do I need to start with a new image??

  2. Scott, are you on twitter?

    Got a question about future Lucid images for EC2. Are you guys planning to only release pv-grub-enabled Lucid images, or will you be releasing both pv-grub and non-pv-grub versions?


  3. @Berend, please see the blog entry I just posted at [1] about how you can move to pv-grub kernels.

    @Dmitriy, I'm not on twitter at the moment. All future 10.04 images will be published using the pv-grub kernels. However, we will continue to publish akis of the kernels that are used in the image. For example, aki-fc00f095 and aki-601fef09 [2,3] are the i386 and amd64 kernels used in the 20110201.1 images in us-east-1. This may be useful for people using Ubuntu who are not able to move to pv-grub kernels.

    We also will continue to publish kernels in the tarballs on, as those are required for non-UEC installations of Eucalyptus (UEC has support for loading using grub).


  4. Hi Scott, I have an Ubuntu 10.04 LTS instance that is running fine. When I upgrade it to the 12.04 LTS version, it does not boot up again because of a Grub kind of error. My question is, Can a 10.04 LTS AMI be upgraded to an 12.04 LTS directly?. I don’t know if it has something to do with the upgrade error but, my 10.04 LTS is an imported Vmware machine into the EC2.
    Can you tell me if there is a particular consideration to go through this upgrade?

    Best Regards,

  5. Nada,
    I just did a quick test.
    # us-east-1/ebs/ubuntu-lucid-10.04-amd64-server-20131205
    euca-run-instances --key=brickies --instance-type=m1.small ami-d39ab8ba

    And then in that instance I did 'do-release-upgrade' and followed the defaults. The one scary question is regarding /etc/default/grub configuration. I selected "accept package maintainers version". In the end that doesn't even matter.

    If the image you upgraded was *very* old, it might have been booting with 'root=/dev/sda1' rather than root=LABEL=cloudimg-rootfs . That is configured in /boot/grub/menu.lst. The reason that is intereesting is that the kernel changed what it identified paravirt disks as from being 'sdaX' to 'xvdaX'.