Thursday, December 5, 2013

New blog has RSS now

Amazingly, there are people reading this blog, and some have actually requested an RSS feed of the new blog, Proof By Example.  That's now done, via the I-can't-believe-it's-still-alive Feedburner service.  Direct link to the feed.

Wednesday, December 4, 2013

New programming-related blog

I've started a new blog for programming and computer stuff.  Just wanted to leave a pointer since this blog is pretty desolate these days.

Tuesday, April 30, 2013

DevHouse Waterloo

After many years, the DevHouse Waterloo web page has moved from the old domain.  The old page is apparently inaccessible for edits, so it'll linger.  This quick post is mostly to help teach Google where the new DevHouse Waterloo page is.  Hopefully the hugely powerful PageRank of my site will help.

Monday, March 26, 2012

Friday, February 10, 2012

Ubuntu Lucid 10.04 at EC2: cloudimg-rootfs does not exist

I've been having a seemingly intermittent problem where I can't boot a custom AMI built from one of Ubuntu's default AMIs.

My process:

  • Start with stock 10.04 LTS, instance-store, 64-bit, us-east-1 image: ami-35de095c
  • Fire it up: works
  • Install a bunch of stuff I need: no prob
  • Create a new AMI for next time with ec2-bundle-vol: "works"
  • Upload it, register it
  • Launch a new instance with this new custom AMI: box fails to come up!

The error message, available from get server log in the AWS Console, is this:

Gave up waiting for root device.  Common problems:
 - Boot args (cat /proc/cmdline)
   - Check rootdelay= (did the system wait long enough?)
   - Check root= (did the system wait for the right device?)
 - Missing modules (cat /proc/modules; ls /dev)
ALERT! /dev/disk/by-label/cloudimg-rootfs does not exist. Dropping to a shell!

Some Googling turned up a similar error for EBS instances using the XFS filesystem, but I was using ext3 and instance-store, so it didn't really apply.

The issue appeared to be that /dev/disk/by-label/cloudimg-rootfs is expected, but not present. What does this really mean? Took some help from a friend for me to realize that the filesystem name is stored on the physical (or virutal...) hard drive. When a new machine is imaged, it obviously won't have "cloudimg-rootfs" as it's filesystem name automatically. Apparently the AMI I was creating was not capturing the filesystem name. Found some evidence supporting this theory. I think the upshot is my version of ec2-ami-tools is missing the patch that records the filesystem name. I have 1.3.49953-0ubuntu1~lucid1 (update: This is an old backport which is probably the source of the issues), which by version number suggests it should have the patch, but I guess it does not (different versions listed here).

To deal with all this I just decided to not rely on LABEL=foo for referring to drives, and instead just use the good old direct notation /dev/sda1 (or whatever).

So the fix is: edit /etc/fstab, /boot/grub/menu.lst, and /boot/grub/grub.cfg and replace uses of LABEL=cloudimg-rootfs with /dev/sda1. This is less robust, but has the side-effect of actually working.

Work-around process:

  • Start with stock 10.04 LTS, instance-store, 64-bit, us-east-1 image: ami-35de095c
  • Fire it up: works
  • edit /etc/fstab, /boot/grub/menu.lst, and /boot/grub/grub.cfg as above
  • Install a bunch of stuff I need: no prob
  • Create a new AMI for next time with ec2-bundle-vol: "works"
  • Upload it, register it
  • Launch a new instance with this new custom AMI: boots!

I'll update this if I get to the bottom of the ec2-ami-tools version numbers.

Update: Looks like 1.3-45758-0ubuntu1.1 is the correct version of ec2-bundle-vol to avoid all this nonsense. Haven't tested yet.

Sunday, August 7, 2011

Image Manipulation in Ubuntu with ImageMagick Tools

Can't believe I haven't come across convert and mogrify before now. Much time could have been saved in the past.

I used Ubuntu 10.04 Lucid for this, but I doubt it matters much as long as you have a recent Linux distribution.

sudo apt-get install imagemagick

Example: resize an image to fit in a 100x100 pixel box, and place it in the centre of a 100x100 pixel box:

convert foo.png -resize '100x100' \
  -background transparent \
  -gravity center \
  -extent '100x100' \

Lots more good documentation here.

Tuesday, August 2, 2011

Ubuntu Remote Desktop


I recently had the need to get reliable remote access to the desktop of an Ubuntu 10.04 install. There are many ways to enable remote access to your X11 desktop in Ubuntu, each with different trade-offs. Here are three (all VNC-based) that I recently looked into:

  • Built-in - System > Preferences > Remote Desktop. Easy, but only works if you're already logged in locally. i.e. after a system restart you can't connect remotely until you login locally again. Common work-around for that: use auto-login (yuck).
  • Xvnc - Create a new X display only viewable via VNC. i.e. the remote user has its own desktop unrelated to what is seen on the monitor if a local user logs in.
  • x11vnc - Serve up what is being shown on the local monitor (i.e. a "real" X display) over VNC. Similar to the built-in solution, but without the "must be logged in" restriction.

My requirements were:

  • Must be able to login remotely after a system restart
  • Must be able to plug in a monitor and see what the remote user sees/last saw (i.e. be able to fix things in the GUI if I break them remotely)

What I Actually Did

Used x11vnc and started right after gdm starts. Here are all the steps:

  1. sudo apt-get install x11vnc
  2. Create a VNC password in a stable location:
    sudo mkdir -p /etc/x11vnc
    x11vnc -storepasswd  /etc/x11vnc/passwd
  3. Add the following to /etc/gdm/Init/Default, right before the exit 0 at the end of the script:
    /usr/bin/x11vnc -safer -allow,192.168.1. -o /var/log/x11vnc.log -xkb -bg -forever -rfbauth /etc/x11vnc/passwd -display :0
  4. Reboot, or just restart gdm (sudo restart gdm).
  5. Should now be able to connect to port 5901 with a VNC client (I used TightVNC).

If things don't work, check /var/log/x11vnc.log -- there's usually a lot of detail in there explaining exactly what is going on.

Clusterfuck Alert

Ubuntu (at least in 10.04) has a crazy issue where X won't start if a monitor is not plugged in when the system restarts. I don't know -- and don't want to know -- why, but there are work-arounds. I'll link to a few below, but the gist of it is to not use the fancy NVidia or ATI drivers, but instead just use the VESA driver. If you're going to have a monitor attached all the time, this is not an issue.