.manifest.xml file is creted by ec2-ami-tools while bundling appliance to AMI. This can happen only when your previous build failed somehow. This should help:
rm -rf build/appliances/fedora/13/cirras/ec2-plugin
And then re-run the command.
Please paste relevant log entries (more == better) from log/boxgrinder.log. So I can track this down. Thanks!
Ok, there was a previous failure because I did not have a ~/.boxgrinder/plugins/s3 defined. Just removing the
build/appliances/fedora/13/cirras/ec2-plugin directory did not seem to clear the issue, so I did a full rebuild and still saw the problem. I sent you the log/boxgrinder.log for review.
One more thing – after the build fails now, do the step I proposed in my first post and then install ec2-ami-tools and re-run the command. It should be fine after that.
I'll release fix for this in a few days.
It seems like I have the tools installed?
[starksm@fedora13 BoxGrinder]$ ec2-bundle-image --help
-c, --cert PATH The path to the user's PEM encoded RSA public key certificate file.
-k, --privatekey PATH The path to the user's PEM encoded RSA private key file.
-u, --user USER The user's EC2 user ID (Note: AWS account number, NOT Access Key ID).
-i, --image PATH The path to the file system image to bundle.
-h, --help Display this help message and exit.
--version Display the version and copyright notice and then exit.
--manual Display the user manual and exit.
--batch Run in batch mode. No interactive prompts.
--debug Display debug messages.
-d, --destination PATH The directory to create the bundle in. Defaults to '/tmp'.
--ec2cert PATH The path to the EC2 X509 public key certificate bundled into the AMI.
Defaults to '/etc/ec2/amitools/cert-ec2.pem'.
-r, --arch ARCHITECTURE Specify target architecture. One of ["i386", "x86_64"]
--productcodes PRODUCT_CODES Default product codes attached to the image at registration time.
Comma separated list of product codes.
--kernel ID Id of the default kernel to launch the AMI with.
--ramdisk ID Id of the default ramdisk to launch the AMI with.
-B, --block-device-mapping MAPS Default block-device-mapping scheme to launch the AMI with. This scheme
defines how block devices may be exposed to an EC2 instance of this AMI
if the instance-type of the instance is entitled to the specified device.
The scheme is a comma-separated list of key=value pairs, where each key
is a "virtual-name" and each value, the corresponding native device name
desired. Possible virtual-names are:
- "ami": denotes the root file system device, as seen by the instance.
- "root": denotes the root file system device, as seen by the kernel.
- "swap": denotes the swap device, if present.
- "ephemeralN": denotes Nth ephemeral store; N is a non-negative integer.
Note that the contents of the AMI form the root file system. Samples of
-p, --prefix PREFIX The filename prefix for bundled AMI files. Defaults to image name.
[starksm@fedora13 BoxGrinder]$ gem list | grep ec2
I have version 1.3 installed.
[starksm@fedora13 BoxGrinder]$ rpm -qif /usr/local/bin/ec2-bundle-image
Name : ec2-ami-tools Relocations: (not relocatable)
Version : 1.3 Vendor: Amazon Execution Service 53887.53773
Release : 53773 Build Date: Sat 03 Jul 2010 11:03:59 PM PDT
Install Date: Tue 10 Aug 2010 06:01:29 PM PDT Build Host: ip-10-212-151-63.ec2.internal
Group : Development/Languages Source RPM: ec2-ami-tools-1.3-53773.src.rpm
Size : 673409 License: Amazon Software License
Signature : (none)
Packager : 20081021-dublin:manual:i386
Summary : Tools for creating, bundling and uploading AMIs.
Tools for creating, bundling and uploading AMIs.
Hm, OK. Please make sure every paths you can see in line starting with "D, [2010-08-20T23:39:16.286253 #27458] DEBUG" in log/boxgrinder.log is there. Especially key lcoations, because this is the main issue here.
Ok, so ths issue is that sudo sets the root user path to a minimal value, and the ec2-tools are not installed in the secure path:
[starksm@fedora13 BoxGrinder]$ sudo which ec2-bundle-image [sudo] password for starksm: which: no ec2-bundle-image in (/sbin:/bin:/usr/sbin:/usr/bin)
The line from the boxgrinder.log is:
D, [2010-08-20T23:39:16.286253 #27458] DEBUG -- : Executing command: 'ec2-bundle-image -i build/appliances/i386/fedora/13/cirras/ec2-plugin/cirras.ec2 --kernel aki-407d9529 -c /home/starksm/Dev/Amazon/sstark@redhat/cert-5V25IJ62FX7ULB2ZYDNLVGFWUEJTLR3U.pem -k /home/starksm/Dev/Amazon/sstark@redhat/pk-5V25IJ62FX7ULB2ZYDNLVGFWUEJTLR3U.pem -u * -r i386 -d build/appliances/i386/fedora/13/cirras/s3-plugin/ami' D, [2010-08-20T23:39:16.293008 #27458] DEBUG -- : /usr/lib/ruby/1.8/open3.rb:67:in `exec': No such file or directory - ec2-bundle-image -i build/appliances/i386/fedora/13/cirras/ec2-plugin/cirras.ec2 --kernel aki-407d9529 -c /home/starksm/Dev/Amazon/sstark@redhat/cert-5V25IJ62FX7ULB2ZYDNLVGFWUEJTLR3U.pem -k /home/starksm/Dev/Amazon/sstark@redhat/pk-5V25IJ62FX7ULB2ZYDNLVGFWUEJTLR3U.pem -u * -r i386 -d build/appliances/i386/fedora/13/cirras/s3-plugin/ami (Errno::ENOENT)
I can get around it by passing in my PATH:
[starksm@fedora13 BoxGrinder]$ sudo PATH="$PATH" which ec2-bundle-image /usr/local/bin/ec2-bundle-image
I have been able to delete the s3-plugin directory and move past the creation of the ami file to the point of uploading the ami.