• Launchpad Entry: server-lucid-cloud-krd

  • Created: 2009-11-28

  • Contributors: Scott Moser

  • Packages affected: kernel


The ubuntu cloud images (both for uec and ec2) should not require a ramdisk. The list of hardware that is needed to be supported is very small, and support should exist in the kernel for ramdisk-less boot. Removing use of a ramdisk simplifies things from a maintenance perspective and also speeds up boot.

Release Note

The UEC images running in ec2 and on UEC no longer require a ramdisk for boot. This translates to more free space in the images and faster boots.


For the supported clouds (UEC and EC2) our provided kernels can be made such that no ramdisk is required. In Karmic, we're producing a ramdisk per disk image. That was because the ramdisk has bits of the filesystem that it was created in. Now, we'll not have to have that complexity, the complete set of parts for a AMI will be kernel and filesystem image.

User stories

This is not really a user-centric feature, but:

  • As as UEC administrator, I'm bothered by the need for a ramdisk for my ubuntu images. Without one, I'd not have to use space for the ramdisk and the instances would boot faster.



Design is pretty simple. The builds of UEC images will no longer have ramdisks inside them, and published builds to ec2 will not have ramdisks associated with them.


I think the most correct way to implement this would be to put a configuration option in /etc/kernel-img.conf that said "do not create ramdisks". However, that doesn't seem to be an option there. Instead, the "initrd" setting (see /var/lib/dpkg/info/linux-image-2.6.*.postinst) is per-kernel-package.

The suggested fix, then is to remove the initrd files from /boot in vmbuilder post install script. That way, the 'copy-out-kernels' functionality will not find a ramdisk and will not associate one in the ec2 published builds.

Code Changes

There is likely assumptions of a ramdisk made in different places:

  • scripts that consume a uec image tar file
  • documentation about using a uec image tar file
  • image store usage of uec image file
  • publishing/build scripts

Test/Demo Plan

These changes will be inherently tested by testing of UEC images or EC2 images. They simply wouldn't boot if this was done incorrectly.

The only needed test really is verifying that there is no ramdisk included.

Unresolved issues


  • 2009-12-01: lucid daily UEC images now available on ec2. Neither tarballs or published AMIs have a ramdisk.

    • verified basic boot and ssh functionality of 20091201 build on both ec2 and uec (uec using current karmic -proposed)
  • verified uec-tools/register-uec-tarball at revision 7 functioned

  • verified kernel has support for 'kvm -hda'. kernel booted, found root, but mountall hangs due to no /dev/sda[1,2,3] on 20091201 image with:

    kvm -hda my-disk.img -kernel lucid-uec-i386-vmlinuz-virtual \
      -append "ec2init=0 root=/dev/sda"

BoF agenda and discussion


I verified that system boots fine on lucid using the karmic kernel, with no ramdisk:

  • $ ec2-describe-instances
    INSTANCE i-9fabd8f7  ami-88d331e1         terminated  ec2-keypair 0     m1.small 2009-11-28T19:58:54+0000   us-east-1c  aki-5f15f636         monitoring-disabled
    $ grep ami-88d331e1 /tmp/
    IMAGE   ami-88d331e1    ubuntu-images-testing-us/ubuntu-lucid-daily-i386-server-20091128.2.manifest.xml 099720109477    available       public          i386    machine                 
    $ grep aki-5f15f636.*ubuntu-kernels /tmp/
    IMAGE   aki-5f15f636    ubuntu-kernels-us/ubuntu-karmic-i386-linux-image-2.6.31-302-ec2-v-2.6.31-302.7-kernel.img.manifest.xml  099720109477    available       public          i386    kernel                  


ServerLucidCloudKernelRamdisk (last edited 2009-12-01 19:49:29 by smoser)