I followed the attachd file (karmic steps...) on a fresh install of Eucalyptus and it recreates the problem. That seems to me to rule out the "ramdiskless" scapegoat.
$ euca-describe-images
IMAGE eki-68691AF0 karmic-20100127/karmic-server-uec-amd64-vmlinuz-virtual.manifest.xml admin available public x86_64 kernel
IMAGE emi-193B15E5 karmic-20100127/karmic-server-uec-amd64.img.manifest.xml
admin available public x86_64 machine eki-68691AF0 eri-45D21A75
IMAGE emi-248C19B8 karmic-20100127-d-upstart/karmic-server-uec-amd64.img.manifest.xml admin available public x86_64 machine eki-68691AF0 eri-45D21A75
IMAGE eri-45D21A75 karmic-20100127/karmic-server-uec-amd64-initrd-virtual.manifest.xml admin available public x86_64 ramdisk
I followed the attachd file (karmic steps...) on a fresh install of Eucalyptus and it recreates the problem. That seems to me to rule out the "ramdiskless" scapegoat.
$ euca-describe- images 20100127/ karmic- server- uec-amd64- vmlinuz- virtual. manifest. xml admin available public x86_64 kernel 20100127/ karmic- server- uec-amd64. img.manifest. xml 20100127- d-upstart/ karmic- server- uec-amd64. img.manifest. xml admin available public x86_64 machine eki-68691AF0 eri-45D21A75 20100127/ karmic- server- uec-amd64- initrd- virtual. manifest. xml admin available public x86_64 ramdisk
IMAGE eki-68691AF0 karmic-
IMAGE emi-193B15E5 karmic-
admin available public x86_64 machine eki-68691AF0 eri-45D21A75
IMAGE emi-248C19B8 karmic-
IMAGE eri-45D21A75 karmic-
$ euca-describe- instances 05T16:28: 57.807Z cluster1 eki-68691AF0 eri-45D21A75
RESERVATION r-557808CA admin default
INSTANCE i-41400767 emi-248C19B8 10.1.1.100 172.19.1.2 pending mykey 0 c1.medium 2010-03-
$ date --utc
Fri Mar 5 16:35:47 UTC 2010
Its been "pending" for 7 minutes at the moment.