Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

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.
share|improve this question
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 '12 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 '12 at 22:17
add comment

2 Answers

up vote 3 down vote accepted

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.

share|improve this answer
add comment

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.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.