Launchpad Entry: server-lucid-cloud-krd
Created: 2009-11-28
Contributors: Scott Moser
Packages affected: kernel
Summary
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.
Rationale
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.
Assumptions
Design
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.
Implementation
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
Status
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
Notes
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/images.us-east-1.txt 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/images.us-east-1.txt 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