Eucalyptus runs images without ramdisk with a default ramdisk

Bug #525989 reported by Dustin Kirkland  on 2010-02-22
12
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Eucalyptus
Fix Released
Undecided
chris grzegorczyk
cloud-utils (Ubuntu)
Medium
Scott Moser
Lucid
Medium
Scott Moser
eucalyptus (Ubuntu)
Medium
Dustin Kirkland 
Lucid
Medium
Dustin Kirkland 

Bug Description

Binary package hint: cloud-utils

$ TIMESTAMP=$(date +%Y%m%d%H%M%S)
$ BUCKET_IMAGE="i-$TIMESTAMP"
$ uec-publish-tarball ./lucid-server-uec-amd64
lucid-server-uec-amd64.img lucid-server-uec-amd64.tar.gz lucid-server-uec-amd64-vmlinuz-virtual
ubuntu@aussie:~$ uec-publish-tarball ./lucid-server-uec-amd64.tar.gz $BUCKET_IMAGE
Mon Feb 22 13:47:25 CST 2010: ====== extracting image ======
Warning: no ramdisk found, assuming '--ramdisk none'
kernel : lucid-server-uec-amd64-vmlinuz-virtual
ramdisk: none
image : lucid-server-uec-amd64.img
Mon Feb 22 13:47:34 CST 2010: ====== bundle/upload kernel ======
Mon Feb 22 13:47:44 CST 2010: ====== done ======
emi="emi-C78B14AA"; eri="none"; eki="eki-073719A9";
cleaning up /tmp/uec-publish-tarball.jU1PKD

Looks like image should work right?

$ euca-run-instances emi-C78B14AA -k mykey -t c1.medium
RESERVATION r-3D1E080B admin admin-default
INSTANCE i-4A070989 emi-C78B14AA 0.0.0.0 0.0.0.0 pending mykey 2010-02-22T20:14:49.288Z eki-073719A9 eri-092119A6

$ euca-describe-instances | grep i-4A070989

INSTANCE i-4A070989 emi-C78B14AA 10.1.1.106 172.19.1.8 shutting-down mykey 0 c1.medium
2010-02-22T20:14:49.288Z cluster1 eki-073719A9 eri-092119A6
...
INSTANCE i-4A070989 emi-C78B14AA 172.19.1.8 172.19.1.8 terminated mykey 0 c1.medium
2010-02-22T20:14:49.288Z cluster1 eki-073719A9 eri-092119A6

Dustin Kirkland  (kirkland) wrote :

Attaching output of

$ grep i-4A070989 /var/log/eucalyptus/*log > /tmp/i-4A070989.log

Dustin Kirkland  (kirkland) wrote :
Download full text (3.5 KiB)

Note that the following steps worked just fine, from https://help.ubuntu.com/community/UEC/BundlingImages:

ubuntu@aussie:~$ TIMESTAMP=$(date +%Y%m%d%H%M%S)
ubuntu@aussie:~$ RELEASE=lucid
ubuntu@aussie:~$ ARCH=amd64 # Or this might be i386
ubuntu@aussie:~$ [ $ARCH = "amd64" ] && IARCH=x86_64 || IARCH=i386
ubuntu@aussie:~$ UEC_IMG=$RELEASE-server-uec-$ARCH
ubuntu@aussie:~$ URL=http://uec-images.ubuntu.com/$RELEASE/current/
ubuntu@aussie:~$ [ ! -e $UEC_IMG.tar.gz ] && wget $URL/$UEC_IMG.tar.gz # This may take a bit, depending on your connectivity
ubuntu@aussie:~$ [ ! -e $UEC_IMG.img ] && tar -S -xzf $UEC_IMG.tar.gz
ubuntu@aussie:~$ BUCKET_KERNEL="k-$TIMESTAMP"
ubuntu@aussie:~$ UEC_KERNEL=$UEC_IMG-vmlinuz-virtual
ubuntu@aussie:~$ euca-bundle-image -i $UEC_KERNEL -r $IARCH --kernel true
x86_64
Checking image
Tarring image
Encrypting image
Splitting image...
Part: lucid-server-uec-amd64-vmlinuz-virtual.part.0
Generating manifest /tmp/lucid-server-uec-amd64-vmlinuz-virtual.manifest.xml
ubuntu@aussie:~$ euca-upload-bundle -b $BUCKET_KERNEL -m /tmp/$UEC_KERNEL.manifest.xml
Checking bucket: k-20100222135250
Creating bucket: k-20100222135250
Uploading manifest file
Uploading part: lucid-server-uec-amd64-vmlinuz-virtual.part.0
Uploaded image as k-20100222135250/lucid-server-uec-amd64-vmlinuz-virtual.manifest.xml
ubuntu@aussie:~$ EKI=$(euca-register $BUCKET_KERNEL/$UEC_KERNEL.manifest.xml | grep "^IMAGE" | awk '{print $2}') && echo $EKI
eki-07D419B5
ubuntu@aussie:~$ ls -alF $UEC_KERNEL
-rw-r--r-- 1 ubuntu ubuntu 4182784 2010-02-21 20:03 lucid-server-uec-amd64-vmlinuz-virtual
ubuntu@aussie:~$ BUCKET_IMAGE="i-$TIMESTAMP"
ubuntu@aussie:~$ UEC_IMG=$RELEASE-server-uec-$ARCH
ubuntu@aussie:~$ euca-bundle-image -i $UEC_IMG.img -r $IARCH --kernel $EKI
x86_64
Checking image
Tarring image
Encrypting image
Splitting image...
Part: lucid-server-uec-amd64.img.part.0
Part: lucid-server-uec-amd64.img.part.1
Part: lucid-server-uec-amd64.img.part.2
Part: lucid-server-uec-amd64.img.part.3
Part: lucid-server-uec-amd64.img.part.4
Part: lucid-server-uec-amd64.img.part.5
Part: lucid-server-uec-amd64.img.part.6
Part: lucid-server-uec-amd64.img.part.7
Part: lucid-server-uec-amd64.img.part.8
Part: lucid-server-uec-amd64.img.part.9
Part: lucid-server-uec-amd64.img.part.10
Part: lucid-server-uec-amd64.img.part.11
Part: lucid-server-uec-amd64.img.part.12
Part: lucid-server-uec-amd64.img.part.13
Part: lucid-server-uec-amd64.img.part.14
Part: lucid-server-uec-amd64.img.part.15
Part: lucid-server-uec-amd64.img.part.16
Part: lucid-server-uec-amd64.img.part.17
Part: lucid-server-uec-amd64.img.part.18
Part: lucid-server-uec-amd64.img.part.19
Generating manifest /tmp/lucid-server-uec-amd64.img.manifest.xml
EMI=$(euca-register $BUCKET_IMAGE/$UEC_IMG.img.manifest.xml | grep "^IMAGE" | awk '{print $2}') && echo $EMI
emi-C73F14A0

ubuntu@aussie:~$ euca-run-instances emi-C73F14A0 -k mykey -t c1.medium
RESERVATION r-30FF056D admin admin-default
INSTANCE i-3F8E0754 emi-C73F14A0 0.0.0.0 0.0.0.0 pending mykey 2010-02-22T20:20:14.956Z eki-07D419B5 eri-092119A6

ubuntu@aussie:~$ euca-describe-instances | grep i-3F8E0754
INSTANCE i-3F8E0754 e...

Read more...

Scott Moser (smoser) wrote :

@Dustin,
is this a dupe of bug 522292

make sure you have current cloud-utils

Thierry Carrez (ttx) wrote :

I can confirm this issue with cloud-utils 0.5-0ubuntu1

The image registered through uec-register-tarball boots OK but hangs on metadata retrieval.
Looking at the eucalyptus side of things, we see that eucalyptus fails to serve "ramdisk-id".

It seems that the way uec-register-tarball registers ramdisks fails in UEC (makes it believe there is a ramdisk, or something).

Thierry Carrez (ttx) on 2010-02-23
Changed in cloud-utils (Ubuntu):
importance: Undecided → High
status: New → Confirmed
Scott Moser (smoser) on 2010-02-23
Changed in cloud-utils (Ubuntu):
importance: High → Medium
assignee: nobody → Scott Moser (smoser)
Scott Moser (smoser) wrote :

Ok. So I was looking into this more, suspecting that uec-publish-tarball was in fact, buggy.

However, it looks like the bug is in Eucalyptus is buggy in its use of images that are registered without a ramdisk.

If you register image A with a ramdisk, and then register image B without a ramdisk, and start instance B, then it will be booted with the ramdisk registered with image A.

Scott Moser (smoser) wrote :

I've opened a track against Eucalpytus based on what Dustin and I found out today.

As far as I can tell, there is no problem with uec-publish-tarball. The reason it appeared to be buggy is that it would correctly register a ramdisk-less image. The boot of that image would hang in boto's attempt to crawl the metadata service (bug 526805).

Then, the user would register an image with a ramdisk, and the default ramdisk would get set (see https://${cloud_controller}:8443/#conf -> Configuration - > Default Ramdisk ). When an image was subsequently booted, it would get the default ramdisk and boot fine. However, it would have booted with errors like those seen in bug 525994 if the default ramdisk was for a kernel other than the current one.

Thierry Carrez (ttx) on 2010-02-24
summary: - uec-publish-tarball yields unrunnable emi
+ Eucalyptus runs images without ramdisk with a default ramdisk
Changed in cloud-utils (Ubuntu Lucid):
status: Confirmed → Invalid
Changed in eucalyptus (Ubuntu Lucid):
milestone: none → ubuntu-10.04-beta-1
importance: Undecided → High
status: New → Confirmed
Changed in eucalyptus:
status: New → Confirmed
assignee: nobody → chris grzegorczyk (chris-grze)
Thierry Carrez (ttx) on 2010-02-26
Changed in eucalyptus (Ubuntu Lucid):
importance: High → Medium
Thierry Carrez (ttx) on 2010-03-04
Changed in eucalyptus (Ubuntu Lucid):
assignee: nobody → Dustin Kirkland (kirkland)
Dustin Kirkland  (kirkland) wrote :

Chris, any progress here?

This is causing a few problems here right now...

Changed in eucalyptus:
status: Confirmed → In Progress
chris grzegorczyk (chris-grze) wrote :

------------------------------------------------------------
revno: 1204
committer: decker <decker@personal-army>
branch nick: 1.6.2
timestamp: Fri 2010-03-05 01:05:00 -0800
message:
  fix LP: #525989
------------------------------------------------------------

Changed in eucalyptus:
status: In Progress → Fix Committed
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package eucalyptus - 1.6.2-0ubuntu10

---------------
eucalyptus (1.6.2-0ubuntu10) lucid; urgency=low

  * Cherry-pick merge from upstream 1.6.2 from revision 1199 to 1206,
    affecting:
    clc/modules/cluster-manager/src/main/java/edu/ucsb/eucalyptus/cloud/cluster/ConsoleOutputCallback.java,
    clc/modules/cluster-manager/src/main/java/edu/ucsb/eucalyptus/cloud/cluster/VmInstance.java,
    clc/modules/image-manager/src/main/java/edu/ucsb/eucalyptus/cloud/ws/ImageManager.java,
    clc/modules/image-manager/src/main/java/edu/ucsb/eucalyptus/cloud/ws/VolumeManager.java,
    clc/modules/storage-controller/src/main/java/edu/ucsb/eucalyptus/storage/LVM2Manager.java,
    tools/euca_conf.in
  * This merge is expected to fix:
    - LP: #526506 - fix volume attach to /dev/sda
    - LP: #525989 - improve handling of non-ramdisk images
    - LP: #531536 - handle get-console-output better
 -- Dustin Kirkland <email address hidden> Fri, 05 Mar 2010 09:30:29 -0600

Changed in eucalyptus (Ubuntu Lucid):
status: Confirmed → Fix Released
Changed in eucalyptus:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers