[Use the same ARI]

For the ones who don't know: if you are restoring a snapshot of your instance by creating a new AMI from the snapshot and then create a new instance from the AMI, you must use the same Amazon Kernel Image (AKI) as the original instance when you are creating the AMI.

It is not required (as far as I know) to define the Amazon Ramdisk Image (ARI) parameter exactly the same as the original instance, but you must select the same kernel version or you will end up with a beautiful kernel panic.

[Don't let fstab to trick you]Another interesting thing is that if you had an instance with two volumes attached, and you are restoring just one snapshot (lets say, the root partition), the Instance will no load. Maybe you will have ping to your instance. You may not have SSH to it. If you look at the logs you will see something like:

The disk drive for /FOO is not ready yet or not present
Continue to wait; or Press S to skip mounting or M for manual recovery

This is because the /etc/fstab is expecting a device that is not present, and it is not able to mount it. If, for some odd reason you still want to boot from this volume but without attaching the required device, you need to follow this steps:

  1. Detach the volume you want to boot from the instance you had already created.
  2. Create a new micro instance from the scratch (just for being able to modify a file)
  3. Attach and mount the volume that you want to boot on the newly created instance
  4. Edit the /etc/fstab file and add the option nobootwait to all the devices you don't want to mount [1]
  5. Save the file, umount the partition, detach the device from the micro instance and terminate the micro instance (the one created in step 2)
  6. You can now attach the device that contains the root partition to your instance again
  7. Boot normally, and the message should not appear anymore.

[Extra info]

BTW, I want to share with you some extra information I did not know and I've googled:

The AKI or Amazon Kernel Images represents the vmlinuz portion of the kernel. Yep, I didn't remember either what vmlinuz: vmlinuz is a compressed Linux kernel, and is bootable. Is capable of loading the operating system into memory so the computer becomes usable. So, basically I understand that when you are creating an instance from an AMI, it does not give a shit on the kernel that's on the AMI, and uses the one you have selected when you created the AMI. Don't know why, though. It doesn't really make sense to me, because if you have a kernel in your filesystem, why not use it? Don't know. AWS injects the kernel you have selected on the AMI creation processes for some reason, and prevents you to boot a AMI with a kernel installed in the FS if you have not selected exactly the same in the AMI creation process (eg: while recovering a snapshot).

In this post there is some information about PVGrub, and it seems to me that is like a Grub simulator, for being able to load the kernel from the filesystem instead of specifying it on the AMI/instance creation process. Haven't tried though, and don't know how it works.

And this is it. Take care.

[1] http://askubuntu.com/questions/120/how-do-i-avoid-the-s-to-skip-message-on-boot