Installing Voyage on new ALIX system

Back around 2005 I was still new to Linux. I had settled into running Debian on my desktop and I needed a new project. At the time I had a crappy DLink router / access point that would get “confused” quite consistently and had to be reset. After a roommate of mine moved out and left behind an old dell Pentium III I decided to replace the DLink. I scrapped together an extra Ethernet card and a Netgear 802.11b PCI card and started messing around. Surprisingly enough, I turned an old PIII desktop into a router / wireless access point.

I can’t remember how I ran across PCEngines but their WRAP single board computer seemed like a fun and significantly more efficient replacement for my PIII access point. Installing Debian on a CF card using debootstrap was pretty straight forward. My wrap system has been routing my network traffic for 3+ years now and has required minimal / no up-keep (except for fixing my own iptables mistakes). There’s even an article on the HowTo Forge now that you can follow step-by-step.

I was always concerned however that the number of disk writes of a general purpose Linux system (pretty much everything in /var) would eventually wear out the CF card. I suppose after 3 years of operation I can say this may not be as big an issue as I first thought. Still, after purchasing another board from PC Engines I decided to install Voyage, a Debian based distro aimed at CF based embedded systems like the ALIX2d3 I’m setting up to be a VPN end point:

alix2d3 single board computer

Installing Voyage is well documented so I won’t repeat it here. You can check out their site for the details. My general impression of Voyage so far is that it’s a bit out of date and that installing Debian directly is likely a better option. The current stable release of Voyage (version 5.2) is still based on Etch so the version of racoon is pretty old … oh yeah and I couldn’t it to boot with Grub but Lilo worked fine.

It’s not all bad though. Voyage has a really cool set-up for minimizing the number of disk writes: they symlink files that need to be writable to a tmpfs. Everything else is mounted read only. It’s also less than half the size of a minimal Debian install which in some circumstances may be important but since 2GB CF cards can be found for less than $20 this is a non-issue.

So after getting Voyage 5.2 up and running I’m going back to a minimal Lenny install using the Voyage kernel like I did on my older WRAP system … pretty much just like in the howto forge article. Maybe I’ll get fancy and mount directories under /var as a tmpfs to minimize disk writes, or even enable SELinux.

ThinkPad x61s UltraBay docking script

UPDATE: I’ve updated this script with a much better design because SELinux wouldn’t let me muck around with X’s tmp files.

Over a year ago I decided to pick up a new ThinkPad, this time the ultra portable x61s. My desktop was aging and I needed mobility more than anything else. I had always intended to get the X6 UltraBay so I could set it up on my desk but I never seemed to get around to it (probably on account of the phobia I developed while trying to get RedHat 9 to suspend and resume on my old T40).

Tonight, after getting my new (well new to me) UltraBay from ebay in the mail I took on setting up a script to run when docking and undocking the laptop. First off, I’m impressed with how well Linux works with the docking station “out of the box”. Even without udev rules to handle the dock/undock event the CD-RW/DVD combo drive hot plugs perfectly (I’m running a vanilla 2.6.31 kernel on Debian Lenny).

The udev rules and docking scripts for this set-up are well documented out there on the web but there were some details I had to assemble from a few different places. This post is mostly to collect the details in one place. If it’s useful to someone else out there even better.

First lets define what we’re trying to do: I’ve hooked up an external monitor to the UltraBase and I want to distribute my desktop across the external monitor and the LVDS display on the laptop when it’s docked. When it’s undocked the laptop should return to using only the LVDS display. We can script all that using a little bit of control logic and some very basic xrandr commands.

Let’s run through getting xrandr working first, then worry about when and how the script should be run. ThinkWiki has some great info for using xrandr to configure an external monitor. But when I ran some of these commands manually, nothing happened?

Turns out that when I first installed Debian on this laptop there wasn’t an external monitor attached (big surprise) so when X was configured it generated a configuration file that couldn’t handle the external monitor. This means xrandr could query properties from the connected monitor just fine, but any attempt to change the configuration did nothing. The command gave a successful status code but nothing happened.

The suggested fix is to attach the second monitor and reconfigure X. On Debian we’d expect this to be done through dpkg:

dpkg-reconfigure xserver-xorg

Which does nothing. Turns out you can tell X to generate a config file directly which does the trick this time:

sudo X -configure

I know nothing about X configuration files so I can’t say why this works but it does because now when we send X commands through xrandr it responds.

Start small by just turning on the external display:

xrandr --output LVDS --auto --output VGA --auto

Your displays may be named a bit differently which you can check using the query option (-q). The external monitor turned on but the screens overlapped in a funny way … progress.

The effect I want is to have my desktop extend across both screens so they’re side by side. xrandr does this without any hassle:

xrandr --output LVDS --mode 1024x768 --output VGA --mode 1024x768 --left-of LVDS

The command above makes the layout pretty obvious: both screens are 1024 by 768 and the VGA screen is positioned to the left of the built in LVDS. Some people want their external screen to have a higher resolution but it’s easy to change the configuration so I’m going for symmetry to start off. That and the larger the screens get the more RAM the video card borrows from the rest of the system.

This is the command we want to run when the laptop is docked, now the command when it’s undocked:

xrandr --output VGA --off

The two commands can be combined into a script which we can pass a parameter, maybe a 1 when the system is being docked, a 0 when it’s undocked. Throw in a case statement and then we can test it:

case $1 in
        echo "undock" | logger -t $0
        xrandr --output VGA --off
        echo "dock" | logger -t $0
        xrandr --output LVDS --mode 1024x768 --output VGA --mode 1024x768 --left-of LVDS
        echo "unexpected input" | logger -t $0
        exit 1
exit 0

Make this file executable and put it in /etc/thinkpad, call it

Now to get the system to run the script for us when the laptop is docked and undocked. Debian Lenny uses udev so this is as simple as adding the following in a file in /etc/udev/rules.d/

KERNEL=="dock.0", ATTR{docked}=="1", RUN+="/etc/thinkpad/ 1"
KERNEL=="dock.0", ATTR{docked}=="0", RUN+="/etc/thinkpad/ 0"

I named this file 55-thinkpad-local.rules based on someone’s reported success on the linux thinkpad mailing list. The order in which udev rules are run, why the order is important and how to write them is still a mystery to me and will remain that way for now.

Now we put the two together. The log messages that are sent to the syslog should be verified to be sure the script is running right because when the laptop is docked/undocked … the screen layout won’t change! Great right? We can get the error message by redirecting the output of the xrandr commands to syslog too like so:

xrandr --output LVDS --mode 1024x768 --output VGA --mode 1024x768 --left-of LVDS 2>&1 | logger -t $0

The error message tells us that the script “Can’t open display”. Wait, root (the script is run as roor) doesn’t have permission to open the display? This turns out to be some X magic that’s explained on the ThinkWiki Fn-F7 page. The important part is way down at the end of the script where root enumerates the X sessions and then one by one exports the server identifiers and the Xauthority cookie. After this root can change the display all it wants. We’ve gotta include this in the original script and while we’re at it throw in some extra stuff to make it pretty. The final script is here. Works pretty good for me, but YMMV.

Winter Project: Raleigh

Two weeks ago I took a few hours to start in on my “winter project”. In Syracuse it’s always good to have a project lined up for the winter months, when the passing of days can sometimes only be measured by the shift from a dark gray to a lighter shade and back (not like we’ve had much snow so far though).

In a previous post I put up some pictures of my BMX but I’m getting pretty old (one ankle surgery is enough) and as much as I love that bike I need something I can ride without being tempted to do tricks that inevitably cause swelling … I told you I’m getting old. Enter the winter project:

Raleigh Before

That’s right. A Raleigh road bike probably from back in the 80’s. I’m completely guessing at the age of the bike but I decided it’s gotta be pretty old when I tore off the tires I found it had cloth rim strips!

cloth rim-stip dating a bike is much like carbon dating a fossil, just not as accurate

It’s actually a pretty big frame. Standing over it I’m just clear of the top tube so it’s about 3 times the size of my BMX. It’s gona take some getting used to once it’s ridable … but let’s not get ahead of ourselves. I’ve still gotta clean close to 20 years of basement-induced corrosion off of the steel. It’s in pretty rough shape. From the amount of crap on the headset / neck / handlebars you get a feeling for how bad it is.

Neck Left
Neck Right

They almost look fuzzy in the photos with all of the crap that’s on them. There’s still a few spots that look really nice though. This is what’s gona get me through the job:

Headset Stamp

That’s pretty sharp. So what follows here are some “before” photos. I’ll post “after” photos as I progress through the clean up effort. I’ve already cleaned up one wheel so I’ll post photos once I’ve finished the second one. Brakes, derailers and anything with cables or bearings are a bit scary though.

Ok on to the pictures: