website of some guy named ranger harke

I recently had occasion to convert an Amazon EC2 AMI image into a VMWare virtual machine, for local testing. Much of the process can be learned online, and I may go into details about it later, since the information is scattered, but there was one particular step that stumped me for quite some time, that I would like to document for the future.

I was able to quite successfully unbundle the AMI, and ‘dd’ it into a partition inside a fresh VMWare VM. It could be mounted and played with, but would not boot, because it lacked a kernel. You see, Xen (which Amazon relies upon), unlike VMWare, does not emulate the full x86 boot process (at least in its standard configuration)- rather, the Xen host itself provides a paravirtualized kernel which is used to boot the Linux operating system stored within the image. Therefore, you will find most EC2 AMIs lack a kernel, since it is provided by the host (though they do contain a matching set of modules).

The solution to this seemed simple- mount the disk, chroot into it, then apt-get install a kernel package (the AMI was based on Ubuntu). However, apparently apt-get is.. a pretty elaborate system, and apparently relies on some things that would not normally be inside the chroot jail.

Specifically, it was trying very hard to work with pts’es, and complaining loudly (and subsequently segfaulting!) because /dev/pts was not valid within the jail. There are about a million pages on the internet that attempt to address this problem by doing something like:

mount -t devpts devpts /mnt/dev/pts

However, no amount of beating on this command with a stick would make it work for me. I tried also mounting /proc and /sys within the chroot, to no avail. I also tried to bring up udev within the jail, which appeared to work, except that it didn’t. It was really very unhappy with all of the techniques I was trying to get a valid /dev/pts tree (even though many of them appeared to work cosmetically).

Finally I stumbled across a working solution:

mount -o bind /proc /mnt/proc
mount -o bind /sys /mnt/sys
mount -o bind /dev /mnt/dev
mount -o bind /dev/pts /mnt/dev/pts

Aha! Instead of putzing around trying to get another copy of /dev/pts mounted, just use the bind option of mount to remount part of the filesystem in a second place. A clever hack, and it worked.

So, then I had a working copy of apt-get in the jail, and I could get on with fixing the other million things that go wrong when you convert an EC2 AMI to VMWare.