Upcoming EBS and S3 AMI changes

In light of some discussions we've been having internally, and with various community members, it has been proposed that as of our next BoxGrinder release, we shall no longer build images with ephemeral devices[1] pre-attached (for EBS), or pre-mounted in any fashion[2] by default (for EBS or S3)[3].

Instead we will emit a message at build-time about device attachment and mounting, advising users to install a script such as cloud-init to auto-mount ephemeral devices, as well as a pointer to a boxgrinder.org resource page explaining how best to bake in an appropriate cloud configuration file (more on that soon).

Those that want device mappings baked into their image will continue to be able to do so by defining their desired mappings via configuration. Note that block storage mappings (including ephemeral, or otherwise), can be configured or reconfigured at runtime instead of, or in addition to, build time.

Providing block device mappings

For EBS AMIs no ephemeral devices are attached by default, whereas with S3 AMIs there is a default layout (although you can modify it as you see fit).

At run-time

All of the standard methods of providing (or modifying) a block device mapping at run-time still apply. For example:

ec2-run-instances ami-12345678 -b /dev/xvdb=ephemeral0

At build time

You can speculatively map devices that may not be present in every instance size at build time.

# -d ami or -d ebs
boxgrinder-build my.appl -p ec2 -d ebs --delivery-config \ 

Why the changes?

The reasons for this change are multitudinous, but the foremost are:

  • Ephemeral device mappings vary according to instance size: We cannot make any easy assumptions about which ephemeral disks will be present, as it varies depending on which instance size is selected, and is subject to arbitrary change by Amazon. For instance, recent problems with BoxGrinder S3 AMIs on m1.small instances were caused by BoxGrinder assuming a particular ephemeral device would be present; an assumption that fell over when AWS introduced a new device mapping layout[4].

  • We do not want to maintain a script that maps and mounts which devices are provided by which instance sizes, as it will duplicate existing well-established efforts (e.g. cloud-init), in addition to being difficult to maintain, inferior in functionality, and surprising to the user.

  • Confusion: Ephemeral device mappings do not show on Amazon API queries, or their web UI (!!). Users do not realise a device is attached until they attempt to attach their own device at the same location (e.g. /dev/xvdb is an ephemeral device mapping, but it does not show in the web UI; if the user attempts to attach a device at xvdb it will fail).

  • Inconsistency: BoxGrinder can build a few different OSes, and some of the best cloud initialisation projects are not necessarily available on all of the OSes default repositories. We would rather not force disparate solutions onto our users, as consistency is one of our primary goals.

Therefore we concluded that rather than a prescriptive or inconsistent solution, we shall provide extremely simple default behaviour, and enable the user to choose an approach that is optimal for them.


If you have any objections, comments or suggestions, leave them in the comments, or send them to via any of our community channels.

[1] Ephemeral disks are transient/instance storage devices that are available 'free' with most instance sizes. The overall capacity included, and the number of devices the space is subdivided into varies by instance size. For example, a m1.large instance has 2x420GiB instance storage.

[2] There is an important distinction between attaching and mounting devices on AWS. Attaching is akin to physically plugging a disk into a machine. Mounting is the usual process of making a device available to the machine's file system.

[3] For the sake of clarity, it is worth noting that S3 Backed AMIs always have a pre-defined set of ephemeral device mappings provided by EC2, but with EBS by default there are none.

[4] In this particular case we were expecting /dev/xvdb to exist, but for m1.small the ephemeral device we wanted was mapped to /dev/xvda2.

BoxGrinder Build 0.6.0 released!

I'm really happy to announce availability of BoxGrinder Build 0.6.0! This is major release fixing many bugs. More, we added some great feature I'm describing below and added some usability improvements too! So, let's dive into new BoxGrinder!

EBS AMI support

As I mentioned in earlier post – we added support for building EBS-based AMI's on Amazon Web Services. The process is really easy – you just need bear in mind that you must execute the build on EC2 (we need to mount ESB volume) and instance on which you want to build the EBS AMI is in the same region as you choose for the AMI. But don't worry: BoxGrinder will remind you about this if something is wrong :)

For more info about EBS plugin please refer to EBS plugin page on our wiki or as directly on our forums.

Cross-arch building is now supported

From now you can build 32 bit appliances on 64 hosts. This is supported for all OSes. If you have problems with it, please file a new ticket in our tracking system. To build 32 bit appliances on 64 bit host you need to use setarch command, for example:

setarch i386 boxgrinder-build jeos.appl

That's all!

Many bug fixes and usability improvements

We fixed (with great help from our community!) many bugs. Full (well, almost) list of fixed bugs you can find here. Let's have a look at the improvements:

Meta appliance has now bigger disk

We released a new version of meta appliance and yes it has a 10 GB root partition now! This means you don't have to create and mount a new disk to build appliances. Still, if you want to build AMI's – you need to have more free space. We encourage you to use meta appliance AMI to build AMI's: you get two things "for free":

  • a big /mnt partition where you can build the AMI
  • lighting fast upload to S3.

Automatic Boxgrinder Build installation on meta appliance boot

In meta appliance version 1.1+ we install on boot latest BoxGrinder Build. When the boot process finishes – you're ready to build your appliances! Of course boot process will be slower – meta appliance for slowest EC2 instance can boot 8 minutes. If you cannot log in to meta appliance, please see our FAQ.

Plugin design improvements

It's now easier to write plugins. We unified the interaction between BasePlugin class and your plugin. Take a look at BGBUILD-26. If you're a plugin developer – don't miss our plugin tutorial!

If you have any problems, please report it directly in our issue tracker or on our forums! We appreciate your feedback! You can talk to us on IRC: irc.freenode.net, channel #boxgrinder.


EBS AMI support for BoxGrinder

There is one issue in BoxGrinder JIRA we have been asked since long time. This is BGBUILD-3: support for EBS-type AMI's. Yesterday I commited initial support for this. What does it mean for you? Simple – you can now build appliances using BoxGrinder and then deliver them as EBS AMI's to Amazon Web Services.

It's here!

This was implemented as a new delivery plugin. Be aware that currently only Fedora 13 is supported – we'll expand support for other platform in the near future.

The plugin is not yet released, it'll be released along with BoxGrinder Build 0.6.0 in the next weeks. If you want try it now – please download nightly artifacts from our CI. Make sure you install also new version of boxgrinder-core and boxgrinder-build (also from CI) because the EBS plugin forced to make some changes in the core. To do this please download all required gems, put them in a directory and install them using this command:

gem install *.gem

How to use it?

It's just another delivery plugin. The only thing which is different is that you must execute the build on an EC2 instance. This is really important. The reason is because we need to mount an EBS volume to the instance and we can do this only on EC2. But don't be afraid – we have meta appliance you can run on EC2 and use it to build your appliances.

boxgrinder-build you_definition.appl -p ec2 -d ebs    

Of course make sure you created valid configuration file for this plugin as described here before you start.

I need help!

If you find bugs in that plugin, please report them in our issue tracker. You can always ask us for help on our forums or on ournew IRC channel: #boxgrinder@ freenode.net.