Can't launch Oneiric x64 instance on Eucalyptus
- by Bruno Reis
EDIT: after many hours, I've found out that the problem has nothing to do with Eucalyptus. It looks like the image is buggy. Very, very buggy. More details in the end. I didn't manage to fix it, and I will file a bug.
EDIT 2: I managed to fix it, it apparently works.
I have a 4-machine cluster running Ubuntu Server Natty (11.04) x64. I've installed "Ubuntu Enterprise Cloud" from the installtion CD (then updated it) on each of these machines. The cloud seems to work fine, I have lots of virtual machines running Natty servers on them.
Now I'd like to run Oneiric in a virtual machine, but somehow I can't.
I downloaded Oneiric's (x64) image from http://cloud-images.ubuntu.com/oneiric/current/, published it (uec-publish-tarball oneiric-server-cloudimg-amd64.tar.gz oneiric-server-cloudimg-amd64) exactly as I did with Natty, then tried to launch an instance (euca-run-instances -n 1 -k my-key -t m1.small -z my-cloud emi-XXXXXXXX) using Oneiric's image, but the instance is not able to boot.
With euca-get-console-output I get the following:
[ 0.461269] VFS: Cannot open root device "sda1" or unknown-block(0,0)
[ 0.462388] Please append a correct "root=" boot option; here are the available partitions:
[ 0.463855] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)
[ 0.465331] Pid: 1, comm: swapper Not tainted 3.0.0-13-generic #22-Ubuntu
[ 0.466526] Call Trace:
[ 0.466989] [<ffffffff815d3ee5>] panic+0x91/0x194
[ 0.467860] [<ffffffff81ad1031>] mount_block_root+0xdc/0x18e
[ 0.468891] [<ffffffff81ad126a>] mount_root+0x54/0x59
[ 0.469829] [<ffffffff81ad13dc>] prepare_namespace+0x16d/0x1a7
[ 0.470883] [<ffffffff81ad0d76>] kernel_init+0x140/0x145
[ 0.471837] [<ffffffff815f38e4>] kernel_thread_helper+0x4/0x10
[ 0.472889] [<ffffffff81ad0c36>] ? start_kernel+0x3df/0x3df
[ 0.473884] [<ffffffff815f38e0>] ? gs_change+0x13/0x13
The filesystem is labeled "cloudimg-rootfs", inside the image both /etc/fstab and /boot/grub/grub.cfg always refer to the image by the label, everything seems to be correct, yet the kernel says it can't find the root file system.
I've spent many hours googling, but nothing came out. I've asked on #ubuntu-server, but nobody knew what to do. I've asked on #eucalyptus but got no answer at all.
Any ideas on why this is happening and how to solve it?
Thanks
EDIT: after many hours, I've found out that the problem has nothing to do with Eucalyptus. It looks like the image is buggy. Very, very buggy.
The first problem is that the Kernel in the image is a -generic kernel, while I suppose it should be a -virtual one. I chrooted into the image, removed the -generic packages, replaced it with the -virtual ones. Then I extracted the new kernel (and replaced the original one (-generic) that came with the tarball) because I need it when I publish and launch an image with Eucalyptus.
The problem described above was solved.
But then, the console started showing this:
mount: mount point ext4 does not exist
If you check the /etc/fstab file in the image, it says:
LABEL=cloudimg-rootfs ext4 defaults 0 1
Damnt, where's my mount point? Note that it is missing /proc as well.
Well, when you think it is over, you will notice that your instance will have no network connectivity. Let's check /etc/network/interface:
# interfaces(5) file used by ifup(8) and ifdown(8)
auto lo
iface lo inet loopback
Oh my! It is missing eth0... here I stopped. I can't take no more. I give up.
Looks like Canonical has just forgotten to properly set up this image. At first, I though: "have I downloaded a server image by mistake?", but no, I double checked. It is really the cloud image, it has even "cloud-init" installed (which is not, by default, on server images). They just forgot to prepare it.
I will file a bug (and reference it here once this is done), and hope they fix it soon!
EDIT 2: it looks like the network configuration was the last thing missing. I decided to test it with the fixes above, and it booted properly! However, I haven't got the slightest idea if the image is now good to go...
