I have an EC2 instance running the Ubuntu 12.04 32bit AMI (available in the first page the Classic wizard for launching a new instance). The root device is an EBS volume. I then follow these steps:

  • Stop the server
  • Right click on volume from Volumes tab -> Create Snapshot
  • Right click on said snapshot from Snapshots tab -> Create Image from this Snapshot
  • From AMI tab, I right click on the newly created AMI and select "Launch Instance"

During the 3rd step of the wizard, I notice this line for "Storage Device Configuration"

Root    /dev/sda1   snap-xxxxxx 8GiB    standard    true

This seems to indicate to me it is using the snapshot as the root volume for the new instance (it is, in fact, the only volume).

I then launch the instance. However, it fails the "status checks" during the "initialization" step. If I right click the instance and "Get System Log", this is the tail of the log:

Using IPI No-Shortcut mode
XENBUS: Timeout connecting to devices!
md: Autodetecting RAID arrays.
md: autorun ...
md: ... autorun DONE.

EXT3-fs: sda1: couldn't mount because of unsupported optional features (240).
EXT2-fs: sda1: couldn't mount because of unsupported optional features (244).
Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(8,1)

What am I doing wrong here? My concern is 2 fold:

  • If I can not boot from a snapshot, this makes the snapshot utility much less useful
  • If I can't create an AMI from a Snapshot for creating a new instance, this not only reduces the usefulness of snapshots but makes we wonder how I can "duplicate" instances easily.
  • 1
    Guessing you had an EXT4 filesystem on the original instance. The procedure looks right, however it is possible that your kernels (AKIs) do not match. Check the AKI used by the original instance, and compare it to that of the new instance. If they don't match, explicitly specify the AKI at launch time.
    – cyberx86
    Nov 12, 2012 at 22:09
  • 1
    @cyberx86 That was exactly it, thank you. Drop that in as an answer and I'll mark it correct. I must say, having a drop down box full of aki-xxxxxxx with no descriptions is not very intuitive. It gives no context of what that information is used for and why it is important, and so I always used "default"
    – Matt
    Nov 12, 2012 at 22:17

3 Answers 3


The errors you got suggest that your file system is more recent than that supported by the kernel (most likely an ext4 on a kernel that only supports ext2/3). Some AMIs depend on a non-standard AKI (Amazon Kernel Image) to provide certain features.

In this case, the procedure you have followed seems correct, therefore, when combined with the error you received, there is a good chance that the AKIs do not match. Check the AKI used by the original instance, and compare it to that of the new instance. If they don't match, explicitly specify the AKI at launch time. (You can also manually create the AMI and in doing so, specify the AKI at that time so that it need to be specified at launch).

As an aside, a better AMI design will use PV-GRUB as a bootloader to load a kernel from the AMI itself (instead of requiring a specific external AKI), which simplifies the process of keeping the kernel up to date. The AWS documentation on user provided kernels is worth reading if you want to implement this in your AMI.


Because you mentioned Ubuntu specifically, this tool may be helpful to you:

I had the same thing happen, and choosing the correct AKI for the OS version and architecture using the tool above worked like a charm.


I came across similar problem, and it turns out, AWS EC2 defaults differ for launching instance vs. creating an AMI: hardware virtualization (HVM) is the default choice in first case, but paravirtual (PV) is the default for image creation.

I stumbled upon this when tried to move EC2 instance between availability zones by snapshotting its EBS volume and creating a new AMI, and this discrepancy in settings (which I did not pay attention too) wasted an hour for me.

So, tl;dr: just choose HVM when launching from a customized AMI and your instance should boot fine.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .