[ubuntu-cloud] deboostrapped lucid image from maverick fails on ec2 (with and without AKI/custom kernel)
smoser at ubuntu.com
Mon Nov 22 12:22:53 GMT 2010
On Sun, 21 Nov 2010, Spike Spiegel wrote:
> Hey there,
> On Sat, Nov 20, 2010 at 1:10 AM, Scott Moser <smoser at ubuntu.com> wrote:
> > Well, see https://wiki.ubuntu.com/UEC/Images/Publishing everything is
> > there, if not, ask. We build these in fully revision controlled system
> > daily.
> I started by taking a look at already built images at
> http://uec-images.ubuntu.com/server/$release/current/ and have the
> following questions:
> * the lucid i386 tar comes with -virtual kernel installed and in the
> tar there's also a -virtual vmlinuz. my understanding was that lucid's
> kernel did not use the pv-ops enabled kernel but installed the -ec2
> one and if I wanted to use pv_grub I had to use your repo. what am I
All images (karmic and forward) have a normal ubuntu kernel package
installed inside. Lucid has both -virtual and '-ec2', but the '-virtual'
will not boot as a pv-ops kernel. The -virtual kernel is present to make
the images "just work" on UEC (where kvm is the hypervisor).
On Lucid, in EC2, you will need to use the -ec2 kernel.
On Maverick, we were able to drop the -ec2 kernel, and remove the
necessity for carrying a massive patch set. As such, maverick images on
ec2 boot -virtual kernel.
Again, there pv-grub is almost entirely not related to pv-ops kernels.
You can use pv-grub to boot -virtual kernel, or -ec2 kernel.
> * if it's not using pv_grub and therefore its own kernel, why having
> installed kernels in the first place? especially two of them, -ec2 and
> -virtual. should I be able to purge both and still have a functional
> AMI? I'm trying to build the smallest possible image so reclaiming
> that space would greatly help.
Kernels are installed in the image because Ubuntu delivers files in
packages, and kernel packages have a 'vmlinuz' file. It makes more sense
to "waste" the space taken by the kernel inside the image in order to make
Ubuntu documentation regarding kernels consistent with the EC2 images.
Ie, if you want to build modules for our ec2 kernel, you can 'apt-get
install linux-headers'. The fact that the packages are consistent
makes things simpler. I'll admit that it can be confusing.
The alternative would have been to change the kernel packages of '-ec2' to
not contain a vmlinuz. It turns out that this would have made the
utilization of pv-grub more difficult (as when it was announced, we would
not have had vmlinuz files inside the image for -ec2 kernels).
> * do I need to upload/register that kernel? Isn't there a standard AKI
> that I can use for all lucid images? likewise, isn't there a pv-grub
> kernel I can use without having to register a new one for each new
There is no "standard AKI" because there is no "standard kernel".
Throughout the life of a release, there are kernel updates to fix security
issues. Prior to pv-grub, the only way we could deliver such things was
by uploading kernels to EC2, and producing new AKIs.
In Lucid, there will be multiple AKIs as a result. In Maverick, which
uses pv-grub, we will continue to use the same set of 4 pv-grub unless
amazon serviced pv-grub, and we had to change.
> * build-ec2-image (should I be using it?) has a part scheme with 1GB
> swap, but I don't see that in the lucid fstab, is that normal?
the 'cat_partfile' from build-ec2-image is overwritten by many of the
configs in the conf/ directory. For older images (karmic maybe), the
/etc/fstab was less dynamic. For newer (lucid and forward) the non-root
/etc/fstab entries are written by cloud-init/cloudconfig on first boot.
The reason for that is to accommodate different disk layouts, as one size
does not fit all.
> * lucid-server-uec-i386.tar.gz doesn't seem to come with a floppy.img,
> is there a reason for it? should/can I rebuild it myself easily if I
> wanted to boot it under kvm?
I added the floppy images, and "easy" kvm boot support through them with
10.10. In addition to the floppy image, there were changes inside the
image that had to be made to make that "just work". So, you wont easily
boot a 10.04 image inside kvm. If you want, what I was doing during that
development is available at
> that's all. in the meantime I'm gonna try to get one of those images,
> strip it out of stuff and then rebundle it and see what happens if I
> pick an amazon AKI.
This "should work" providing you dont rip out packages important to boot,
and you select the right kernel.
- use pv-grub kernels if you have a /boot/grub/menu.lst file
- use ubuntu provided AKIs otherwise. For ubuntu kernels, pick the aki
that is the latest version in an 'ubuntu-kernels' bucket
(ubuntu-kernels-us, ubuntu-kernels-us-west-1 ... )
More information about the Ubuntu-cloud