Debian on Amazon EC2: Booting issues

Recently I've been playing around with PyPy and its new support for C extensions. I've been wanting to jump into it more, but outside of my desktop at work, I don't really have a suitable environment for hacking on stuff, especially for non-work related stuff. My linux box at home is a MythTV DVR; probably not the best place to do PyPy "translations". Clearly I need another dev box.

For a while I've been meaning to start playing around with Amazon EC2, so I figured this might be a good opportunity, plus I just found out recently they have a free service tier for the first year. Unfortunately, the default Amazon images are Fedora, and I'm more of a Debian guy, so I wanted to install a Debian machine image. Being the paranoid sort, I don't really want to install somebody else's machine image; plus it's more fun to do it myself!

I set up a normal 64-bit Linux AMI, mounted a second "target" EBS volume, and ran the ec2ubuntu script to build an AMI. (I had to make a couple of changes and run a few things by hand to get the script to work.) It downloads Debootstrap, and installs Debian to a target directory/volume, using chroot as necessary. When I was done setting up the image, I created a snapshot (using the management console), ran ec2-register to create an AMI, and launched it using the management console. The ec2-register command was:

ec2-register -a x86_64 -b /dev/sda1=<snapshot-id>:2:false -n 'Debian-testing' -d 'Debian testing 2011-05-22' --kernel <hd0 pvgrub aki id>

The biggest challenge was to get the AMI to actually boot. Many of the guides out there pre-date Amazon's use of PV-GRUB. Previously, in order to boot an EC2 image, you had to use one of Amazon's pre-made Kernels, and you had to have their kernel modules installed on your image. Now you can have Amazon boot your own custom kernel image using PV-GRUB, and in fact this is how Amazon's pre-made Linux AMIs work. Troubleshooting and debugging the boot process is particularly frustrating; all you get is a dump of the console log (visible in the AWS Management Console). In the end for your image to boot, you need a few things: grub, the correct Amazon kernel ID, and a working /boot/grub/menu.lst.

By default, Debian comes with GRUB 2. I'm not sure if this works with EC2. I installed the grub-legacy package instead, as this matched the version of PV-GRUB I saw on the console. It's possible you don't even need a version of grub installed, as long as you have a working menu.lst.

The Amazon kernel IDs are listed in the Amazon EC2 Developers Guide, but it's pretty misleading, or flat out wrong. You need to use an "hd0" PV-GRUB AKI if the root device contains your /boot/grub/menu.lst directly and and an "hd00" PV-GRUB AKI if the root device is partitioned and your menu.lst is on the first partition. So, even though I'm using an EBS-backed instance, I needed an "hd0" AKI, because my root EBS volume is not partitioned. In us-west-1, for a 64-bit OS I used AKI "aki-9ba0f1de".

Setting up the /boot/grub/menu.lst correctly was the hardest part for me. The biggest issue is that grub (or the OS?) sees the "root device" as /dev/xvda1 instead of /dev/sda1, so the "kernel" line of the menu.lst needs to say /dev/xvda1 instead of /dev/sda1.  (The console output when this was incorrect was very misleading; I was getting errors like "Gave up waiting for root device" and "Alert! /dev/sda1 does not exist.") I'm not sure why it did not occur to me sooner that I could use the Amazon Linux AMI's menu.lst as an example, but this realization proved to be helpful. Anyways, my full menu.lst is:

default 0
timeout 1

title EC2
        root (hd0)
        kernel /boot/vmlinuz-2.6.38-2-amd64 root=/dev/xvda1
        initrd /boot/initrd.img-2.6.38-2-amd64

After correcting my menu.lst, everything booted just fine. I was able to ssh in, as root. The init.d scripts added by the ec2ubuntu script copied over the correct SSH key, so logging in was easy.

I'm now the proud "owner" of a dev machine running Debian "in the cloud". My next step is to configure it, but that will have to wait for later.

Memorial Day 2011: Which Ski Resorts will be Open?

I've been compiling a list of ski resorts that are going to be open for Memorial Day (May 28–30, 2011), since I'm hoping to get one last weekend of skiing in this season. I've also been trying to keep track of which lifts, and how much terrain will be open, since I know some resorts like to open token amounts of terrain in order to lure unsuspecting victims visitors. I'll try to keep this up to date as best I can, but some resorts (Whistler Blackcomb) like to change their plans frequently.

Arapahoe Basin, Summit County, CO
Open Daily (8:30–4:00):
All lifts, subject to conditions.

Crystal Mountain, WA
Open Saturday – Monday (8:00–3:00):
Green Valley, Mt Rainier Gondola.

Donner Ski Ranch, Lake Tahoe Area, CA
Open Saturday – Monday (8:30–2:00):
No info on which lifts.

Keystone, Summit County, CO
Open Friday – Monday (10:30–2:30):
No info on which lifts; it might just be a park?

Kirkwood, Lake Tahoe Area, CA
Open Saturday & Sunday (8:00–2:00):
Lifts 10 & 11.

Mammoth Mountain, Eastern Sierras, CA
Open Daily (8:30–4:00):
Chairs 1, 2, 3, 4, 5, 6, 10, 11, 23, G1 and G2

Mt Bachelor, Central OR
Open Daily until Sunday May 29 (9:00–2:00):
Pine Marten Express, Skyline Express, Summit Express.

Snowbird, Salt Lake City Area, UT
Open Friday – Monday (9:00–3:00):
Tram (summer schedule), Mineral Basin Express, Little Cloud.

Squaw Valley, Lake Tahoe Area, CA
Open Saturday – Monday (9:00–2:00):
Cable Car, KT-22, Headwall, Shirley Lake, Links, Bailey's Beach.

Timberline Lodge, Northern OR
Open Daily (9:00 - 2:30):
Best 3 lifts, based on conditions (until May 31; only two lifts after that, all summer).

Whistler Blackcomb, Whistler, BC
Open Daily until Monday May 30 (10:00–4:00):
Blackcomb mountain only: Excalibur Gondola, Solar Coaster Express, Excelerator Express, Wizard Express (maybe, Saturday - Sunday only), Catskinner (Saturday-Sunday only), Jersey Cream Express, Crystal, Glacier Express.

About this blog...

Over the years, I've realized that the internet is a small place, and I've occasionally tried to find information that simply does not exist on the internet. Usually this works as follows:

• Come across an obscure problem or question that I want solved or answered.
• Search for variations of the same really vague keywords on the internet for several hours
• Realize that what I'm looking for is not on the internet.
• Dig deeper and figure out the answer or solution for myself.
• Come to the questionable conclusion that I'm the only one in the entire world that knows some factoid.
• Think existentially about the limitations of human knowledge and how small the world is.

I've finally decided to add another step: share what I've learned with the internet. With any luck, maybe search engines will index something useful here. Certainly that's one of the goals of this blog. (Probably the only one I've come up with so far.)

I expect that posts here will include lots of random topics. Most of them will be nerdy. There might be occasional posts about skiing, living in the Bay Area, and who knows what else.