EC2 instance status check failed

Question

I am trying to backup 20GB mongoDB data from a running EC2 instance. I create a snapshot of EBS volumes. Create an AMI base on the snapshot and launch the AMI instance.

But the instance launch fails due to the status checks

System log:

Linux version 2.6.16-xenU ([email protected]) (gcc version 4.0.1 20050727 (Red Hat 4.0.1-5)) #14 SMP Mon May 28 03:41:48 SAST 2007

BIOS-provided physical RAM map:

 Xen: 0000000000000000 - 0000000023530000 (usable)

0MB HIGHMEM available.

565MB LOWMEM available.

NX (Execute Disable) protection: active

Built 1 zonelists

Kernel command line: root=/dev/sda1 ro console=hvc0 4

Enabling fast FPU save and restore... done.

Enabling unmasked SIMD FPU exception support... done.

Initializing CPU#0

PID hash table entries: 4096 (order: 12, 65536 bytes)

Xen reported: 1799.999 MHz processor.

Console: colour dummy device 80x25

Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)

Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)

Software IO TLB disabled

vmalloc area: e4000000-ff5fe000, maxmem 379fe000

Memory: 559744k/578752k available (1974k kernel code, 10400k reserved, 628k data, 156k init, 0k highmem)

Checking if this processor honours the WP bit even in supervisor mode... Ok.

Calibrating delay using timer specific routine.. 3613.44 BogoMIPS (lpj=18067215)

Mount-cache hash table entries: 512

CPU: L1 I cache: 32K, L1 D cache: 32K

CPU: L2 cache: 256K

CPU: L3 cache: 20480K

Checking 'hlt' instruction... OK.

Brought up 1 CPUs

migration_cost=0

Grant table initialized

NET: Registered protocol family 16

Brought up 1 CPUs

xen_mem: Initialising balloon driver.

VFS: Disk quotas dquot_6.5.1

Dquot-cache hash table entries: 1024 (order 0, 4096 bytes)

Initializing Cryptographic API

io scheduler noop registered

io scheduler anticipatory registered (default)

io scheduler deadline registered

io scheduler cfq registered

i8042.c: No controller found.

RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize

Xen virtual console successfully installed as tty1

Event-channel device installed.

netfront: Initialising virtual ethernet driver.

mice: PS/2 mouse device common for all mice

md: md driver 0.90.3 MAX_MD_DEVS=256, MD_SB_DISKS=27

md: bitmap version 4.39

NET: Registered protocol family 2

Registering block device major 8

netfront: device eth0 has copying receive path.

IP route cache hash table entries: 32768 (order: 5, 131072 bytes)

TCP established hash table entries: 131072 (order: 8, 1048576 bytes)

TCP bind hash table entries: 65536 (order: 7, 524288 bytes)

TCP: Hash tables configured (established 131072 bind 65536)

TCP reno registered

TCP bic registered

NET: Registered protocol family 1

NET: Registered protocol family 17

NET: Registered protocol family 15

Using IPI No-Shortcut mode

XENBUS: Device with no driver: device/console/0

md: Autodetecting RAID arrays.

md: autorun ...

md: ... autorun DONE.

end_request: I/O error, dev sda1, sector 2

EXT3-fs: unable to read superblock

Unable to handle kernel NULL pointer dereference at virtual address 00000024

 printing eip:

c0256ebd

0047a000 -> *pde = 00000000:24480067

00480000 -> *pme = 00000000:00000000

Oops: 0000 [#1]

SMP 

Modules linked in:

CPU:    0

EIP:    0061:[<c0256ebd>]    Not tainted VLI

EFLAGS: 00010097   (2.6.16-xenU #14) 

EIP is at blkif_int+0x11d/0x270

eax: 00000000   ebx: 00000001   ecx: e2c5f0ac   edx: 00000000

esi: 08010100   edi: 00000000   ebp: c038deb0   esp: c038de78

ds: 007b   es: 007b   ss: e021

Process swapper (pid: 0, threadinfo=c038c000 task=c0339400)

Stack: <0>c0352360 00000001 00000000 e2ae407c 00000000 e2c5f0ac 00000001 00000002 

       00000000 c34adc7c 00000001 e2aa75c0 00000000 00000000 c038ded8 c013f64f 

       00000105 e2ae4000 c038df40 c038df40 00000105 00008280 c0381680 00000105 

Call Trace:

 [<c010592d>] show_stack_log_lvl+0xcd/0x120

 [<c0105b2b>] show_registers+0x1ab/0x240

 [<c0105e31>] die+0x111/0x240

 [<c0113157>] do_page_fault+0x707/0xc32

 [<c0105307>] error_code+0x2b/0x30

 [<c013f64f>] handle_IRQ_event+0x3f/0xd0

 [<c013f76e>] __do_IRQ+0x8e/0xf0

 [<c0106f0d>] do_IRQ+0x1d/0x30

 [<c024c111>] evtchn_do_upcall+0xa1/0xe0

 [<c0105349>] hypervisor_callback+0x3d/0x48

 [<c01039ef>] xen_idle+0x2f/0x60

 [<c0103a92>] cpu_idle+0x72/0xc0

 [<c0102035>] rest_init+0x35/0x40

 [<c038e56a>] start_kernel+0x2ea/0x3a0

 [<c010006f>] 0xc010006f

Code: 89 82 84 00 00 00 8b 55 0c 89 b2 fc 13 00 00 8b 4d dc 0f bf 51 0a 0f b6 41 08 66 85 d2 0f 94 c3 3c 01 0f 87 38 ff ff ff 8b 55 d8 <8b> 42 24 89 5c 24 04 89 14 24 89 44 24 08 e8 60 f3 fb ff 85 c0 

 <0>Kernel panic - not syncing: Fatal exception in interrupt

Answer 1

Amazon EBS-backed Linux AMIs are possible but cannot succeed all the time. You can easily create a snapshot of an EBS volume which is the root volume of the instance which has MongoDB in it.

After taking the snapshot, you would have created an AMI with that and try to launch an instance; but manually creating an AMI is not advised by AWS. That is the reason, they have a dedicated service called Create Image which can create an AMI which doesn't fail.

Try taking a direct AMI of the EC2 instance which is running MongoDB in it. Then try to launch an instance with that AMI, and it will be perfect without any errors.

Check this document which teaches you to Create an AMI for a EC2 Instance.