Spooked by a corrupt initrd image

Halloween is approaching. It is apt I have a scary tale to tell.

I left my laptop on in the sun, on a surface with poor conductivity. As I opened it, I glimpsed it complaining of heat exhaustion before it powered off. (That’s happened to me before, too!) I let it cool off, but on booting Ubuntu, a terrifying message was all that appeared on the screen:

Error 16: Inconsistent filesystem structure

Uh oh. Did I lose everything? What haven’t I backed up lately? Indeed, what have I backed up lately?

I searched online for the error message, and took heart when others reported no data loss in various forums. Running fsck was suggested, though in at least one case they resorted to reinstalling the OS. No way I’m doing that!

My first instinct was to dust off my USB DVD writer and burn a Ubuntu rescue CD. This turned out to be unnecessary, but at least I was reassured when I used it to mount the Linux partition and found my files intact. Firing up fsck had no effect: I was still defeated by the same error message.

Playing with the GRUB command-line (by pressing “c” instead of selecting an kernel to boot) showed that the initrd image was corrupted, as selecting the newest image with the “initrd” command triggered the same error message.

The solution was easy. Boot up an older kernel, then download a fresh copy of the initrd image by running:

$ sudo apt-get install --reinstall linux-image-2.6.32-25-generic

Chinese Input

Google Translate supplies a clumsy but straightforward means for entering Chinese characters with a US keyboard, especially for those learning the language. Simply type the English meaning, and copy the result. You can check the character is indeed the one you want by clicking on "Show romanization", or on the speaker icon to hear a synthesized reading.

However, sometimes I have a particular character in mind. A short-term solution is to use an online rendition of a traditional dictionary ordered by radical and stroke count, or a pinyin dictionary. Additional speed and convenience requires investment; one must learn one of the many fascinating methods for entering Chinese characters on a computer.

I’ve read that the Wubizixing input method is fastest, though as one might expect, it requires the most investment. Proficiency demands much practice with a suitably annotated keyboard.

For now, I’ve opted for the Wubihua method, which mimics how humans write characters. It may be slower, but it can be learned quickly. Also it applies when sending Chinese text messages on mobile phones.

I supplement Wubihua with a pinyin method, as I’m practically illiterate in Chinese.

Chinese input in Linux

To setup Chinese input methods in Ubuntu, I installed the scim and scim-pinyin packages, then modified my .xsession as follows. I prepended:

export XMODIFIERS="@im=SCIM"
export GTK_IM_MODULE="xim"

and appended:

scim -d

after which pressing Ctrl+Space toggles Chinese input.

"Stroke 5" is Wubihua mode. Stroke types are mapped to 5 keys along the bottom row. From right to left:

/: | (vertical; top-to-bottom)

.: \ (downwards left-to-right)

,: / (downwards right-to-left)

m: - (horizontal; left-to-right)

n: other stroke types, e.g: 乙

Perhaps one can remember this as follows: 乙 looks like a rotated N. A lowercase M takes more horizontal space than most letters, so it corresponds to the horizontal stroke. On the next two keys, the less-than and greater-than signs point left and right, so they correspond to the left and right downward strokes. Lastly, the stem of the question mark suggests a vertical stroke.

Although the pinyin method is found in the Simplified menu (智能拼音; "smart pinyin"), it also offers Traditional characters. I originally learned zhuyin (aka bopomofo), a more traditional pronounciation-based method for producing Traditional characters, but it is ill-suited for a US keyboard. Fortunately converting from zhuyin to pinyin is trivial.

Chinese to English

In a pinch, I’ll use Google Translate to learn Chinese phrases. However, browser plugins are much handier; see the Chrome Zhongwen extension and the Firefox Perapera-kun add-on.

Nginx and FastCGI

One perk I miss from my first days of grad school was my office computer with a permanent IP address. I could run all sorts of servers. (Later, the environment became harsher because unlike me, many of us ran Windows, but like me, they did not know how to do so securely. The IT team restricted most ports as the first line of defence, though you could ask for exceptions. Hopefully they didn’t tighten control further after I graduated.)

Wanting to be cool, I experimented with PHP when it started becoming popular. Until then, I had only dabbled with CGI programs in compiled languages. PHP was intoxicating. A Common Gateway drug, so to speak. In those Web 1.0 days, dynamic webpages were so easy and fun to make with PHP that I overdosed.

Years later I finally admitted to myself that my content was static apart from a few needless gimmicks, and this was unlikely to change. Using PHP was only increasing the CPU load. It didn’t matter because I received few hits, but it offended me as a computer scientist. I sobered up and returned to vanilla HTML.

I’ve been thinking how I might write a web application today, and I realized I’ve come full circle. I’ve lost my taste for LAMP stacks at a time when they are more widespread than ever, and once again espouse compiled languages.

Nginx

Firstly, I’ve moved on from Apache, which was once my favourite web server. I used to watch Netcraft's market share graphs so I could cheer on Apache against commercial products. But one day, I noticed a newcomer on the graphs. A strange jumble of letters: "nginx". I couldn’t resist looking it up.

Nginx shows how powerful pure unadulterated C can be in the right hands. Written by Igor Sysoev, this webserver runs on numerous platforms, hardly using any memory even as it handles thousands of requests at light speed. Nginx has somehow dodged Jeff Darcy’s Four Horsemen of Poor Performance.

Nginx cannot do CGI, but it can do FastCGI, which is a plus. Instead of spawning a new process for every request, FastCGI spawns a long-lived program once, which communicates with the webserver when necessary, possibly over a network. Of course, this program can run threads of its own if desired.

An advantage of LAMP stacks was that scripts could run without requiring a new process or thread. FastCGI puts all languages on the same footing. In fact, FastCGI is more flexible: for example, you can restart FastCGI programs independently of webservers. Perhaps this is why some run PHP via FastCGI.

Compiled languages

I prefer a compiled language to a scripting language like PHP because I crave speed and scalability. Also, one feature of PHP is useless to me: I discovered I lack the discipline to mix code with HTML. At first I found it was convenient, but eventually my webpages became hard to maintain. I now insist on strict separation between languages: my CSS, JavaScript, HTML, and whatever else ideally reside in distinct files.

Also, now that JavaScript is ubiquitous, it seems best to push as much work as possible to the client side: the FastCGI should do the minimum possible and supply its results (perhaps in JSON) to JavaScript which then plays with the data using the client’s CPU. This diminishes the need for a language designed to mingle with HTML.

Running a web application with a scripting language purportedly allows rapid prototyping, but it seems the only drawback to a compiled language is a compilation step and a FastCGI program restart. This is negligible provided your language has a fast compiler (like C and Go). Besides, I bet much of the development cycle involves presentation tweaks, that is, edits to CSS, HTML, and JavaScript: not the compiled language.

The L and M of LAMP

I’d still run my servers on Linux. I’ve had good results with it so far. As for MySQL, I cannot say, having never experimented much with databases. Its reputation seems solid enough.

How-to

On the latest Ubuntu, you’ll need to install the packages nginx, spawn-fcgi, libfcgi-dev. Then edit the nginx configuration file in /etc/nginx/sites-available/default. In the server clause, add something like:

location = /test {
  fastcgi_pass 127.0.0.1:9000;
  fastcgi_param QUERY_STRING $query_string;
}

The file /etc/nginx/fastcgi_params contains other parameters you might want to pass. Restart nginx, by running for example:

$ sudo /etc/init.d/nginx restart

Visiting http://localhost/test should result in a 502 error because no FastCGI program is running yet.

Let’s fix this. In C, I recommend using fcgiapp.h and not fcgi_stdio.h; it’s not much more trouble, and you avoid conflicts with the standard stdio library.

#include <fcgiapp.h>

int main() {
  FCGX_Stream *in, *out, *err;
  FCGX_ParamArray envp;
  while (FCGX_Accept(&in, &out, &err, &envp) >= 0) {
    char *q = FCGX_GetParam("QUERY_STRING", envp);
    FCGX_FPrintF(out, "Content-type: text/plain\r\n\r\n");
    if (!q) {
      FCGX_FPrintF(out,
          "no query string: check web server configuration\n");
    }
    FCGX_FPrintF(out, "Query: '%s'\n", q);
  }
  return 0;
}

Compile your code:

$ gcc a.c -lfcgi

Then spawn the binary on your machine on port 9000:

$ spawn-fcgi -a 127.0.0.1 -p 9000 -n -- a.out

Test it by visiting http://localhost/test?example.

In a real application, you might want to run the binary as a daemon, and place the process ID in a temporary file for easy access:

$ spawn-fcgi -a 127.0.0.1 -p 9000 -P /tmp/pid -- a.out

I had planned to continue this post by writing about embedding HTML files in C, and fetching data with JavaScript but it’s too long as it is. Some other time maybe.

G1 Miscellany

What fortuitous timing! Intending to start from a clean slate, I performed a factory reset on my G1 recently. I had forgotten that, unlike the Developer Edition of the G1, even an unlocked standard issue G1 requires a SIM card with a data plan for the initial setup.

I was going to wait until I could borrow a suitable SIM from a friend for a few seconds (as after registration, I'm happy to use just WiFi for my G1 net needs for the time being), but I just heard about a new jailbreak for all G1s. It works by flashing the G1 back to RC29 where the old jailbreak can be exploited. Once done, one can register the G1 via WiFi, without a data plan or even a SIM.

Some Linux-specific notes. The G1 is touchy about the SD card for the RC29 image. The time it worked for me, I had reformatted it with "mkfs -t vfat /dev/foo", and used uppercase exclusively for the filename. To get the "adb" tool from the Android SDK working, I had to create an appropriate /etc configuration file.

I only needed two of the incantations. On the G1, I enabled adb via:
<enter>setprop persist.service.adb.enable 1<enter>

and once in the adb shell, I opened the Settings menu before registration:
$ am start -a android.intent.action.MAIN -n com.android.settings/.Settings

From here it was trivial to setup WiFi and sign in.

Some unrelated tips. When typing, Alt + Delete clears the whole line. RemoteDroid turns the G1 into a wireless keyboard and mouse; a fun application to show off.

I remain easily amused by the digital compass. The Orienteer app is often the first app I demonstrate. Also, the Sky Map app is perfect for those interested in picking out constellations in the night sky, but not interested enough to actually memorize them and figure out when and where they can be seen.

Restoring GRUB after reinstalling XP

For me, a common system setup is dual-boot Windows and Linux, and a common problem is an overwritten MBR (Master Boot Record) after reinstalling Windows XP, making it impossible to boot to Linux. Most sites recommend using a Linux install or rescue CD to fix this, but I prefer to install the GRUB bootloader on the Windows partition, and then use GRUB to boot into Linux to repair the boot record:

1. Download the latest zip file from GRUB for DOS and extract the file grldr to C:\
2. Run cmd and type:
   cd \
   attrib +r +s +h boot.ini
   edit boot.ini
   
3. Append the line
   c:\grldr="GRUB"
   to the operating systems section, which is usually last. Save and quit.
4. Type
   attrib -r -s -h boot.ini
5. Reboot and select GRUB from the boot menu.
6. From the grub prompt we can repair the system:
   find /boot/grub/stage1
   root (hdX, Y)
   setup (hd0)
   reboot

Take care with boot.ini as invalidating this file can render the system unbootable. In this case you must boot by another method, e.g. network, USB, CD or floppy.

Thinkpad X61 Wireless and Ubuntu

At last I have resolved a long-standing gripe with Ubuntu on my ThinkPad X61.

Months ago, soon after installing Gutsy Gibbon, I found that my wireless card initially worked well. But a few minutes later, my connection was dead, and I could only restore it by unloading the iwl4965 driver, reloading it, and reconnecting to my access point. Unfortunately, after an indeterminite amount of time the problem would reoccur.

I experimented a little and discovered that by instructing my wireless router to accept anything only 802.11g, the problem vanished. When away from home and using other wireless networks, occasionally my connection would spuriously disconnect. Fortunately, the wireless networks I usually frequent somehow never cause this bug to manifest.

Yesterday my wireless connection was unbearably flaky, and several times, even reloading the driver proved fruitless. I finally decided to look for a proper solution.

Typing dmesg revealed that every time the connection dropped, a message similar to the following would be logged:

[  154.652000] wlan0: No ProbeResp from current AP 04:11:46:fe:24:b0 - assume out of range

Googling for "iwl4965 no proberesp" shows that many others have had the same trouble. Some pages were unanswered bug reports, and others contained discussion where the consensus was to reload the kernel module as a workaround. Happily, before long I stumbled across a FAQ for the ThinkPad T61 that describes a permanent fix, which I'll repeat:

1. Download the latest iwlwifi microcode
2. Replace /lib/firmware/2.6.22-14-generic/iwlwifi-4965-1.ucode.
3. Reload iwl4965 module

The new microcode banished my wireless woes, and the dreaded "No ProbeResp" no longer appears in the logs.

Now I'm left with one remaining significant complaint: the graphics driver. My i965 mostly behaves but there are minor annoyances involving compiz, and major ones involving Wine. I'll leave this for another time.

xrandr

In the old days, to get the external VGA output working on my laptop in X, or even switch resolutions, I'd have to edit an overly complex configuration file and restart X. Nowadays, I use the X Resize and Rotate Extension via xrandr, which is considerably more convenient. I like to control displays through the command-line interface. I find typing the full command cumbersome, so I use this simple script instead:

#!/bin/bash
case "$1" in
  left)
    xrandr --output VGA --auto --left-of LVDS
    ;;
  right)
    xrandr --output VGA --auto --right-of LVDS
    ;;
  up)
    xrandr --output VGA --auto --above LVDS
    ;;
  down)
    xrandr --output VGA --auto --below LVDS
    ;;
  big)
    xrandr --output VGA --mode 1600x1200 --above LVDS
    ;;
  off)
    xrandr --output VGA --off
    ;;
  *)
    xrandr --output VGA --auto --same-as LVDS
    ;;
esac

Thinkpad X61 Volume Buttons

I tried in vain to get the brightness adjustment keys to work, but at least the volume up and down buttons were easy to handle. They trigger bona fide X key events, so I added a couple of lines to .xbindkeys:

"amixer -c 0 set PCM 1dB+"
  XF86AudioRaiseVolume

"amixer -c 0 set PCM 1dB-"
  XF86AudioLowerVolume

Linux on a Thinkpad X61

My X31 which I repaired a while ago died again. This time I think the system board is gone, as there are no signs of life. Nothing I do, even plugging in a power cord (and I tried several), will make any of the LEDs light up. It is functionally equivalent to a brick.

I decided to purchase a Thinkpad X61 instead of a replacement system board. I chose to stick with the Thinkpad X series for several reasons. For starters, Thinkpads endure. Well, apart from my X31, though it still outlived other brands I've tried. I even have an old Thinkpad 240 that's still running strong.

Another reason is that I want a good balance of small footprint and performance. I went through a phase long ago where I thought the biggest baddest laptop that money could buy was the right choice, but after trying it once, I discovered clunkiness destroys half the appeal of a laptop, and furthermore, a cheap desktop with accessories will give a much better computing experience.

But most importantly, Thinkpads have a good track record with Linux support. Nonetheless, I did a few quick Google searches to confirm that this was the case for the X61. Happily there are many results.

My X61 arrived last month, and with Vista installed by default. Vista is astoundingly bad. Not only is it slow, but every few actions, everything grinds to a halt until I handle some dialog box about giving permission to some process or other.

I suppose some effort was put into making the interface look slicker, but there is also plenty of extraneous rubbish that serve only as visual distractions and annoyances. Perhaps Microsoft is not entirely to blame, as some of the pop-ups are plastered with the Lenovo logo.

In any case, my new system was unusable. I had to escape from Vista. It had been a long time since I had last installed Linux, as once setup correctly, there's rarely a reason to reinstall. I spent some time learning about the latest installation methods.

Network Installation

There's no need to prepare a floppy, CD or any other kind of removable media. Visit http://www.goodbye-microsoft.com/ from any version of Windows, including Vista, and you can have Debian up and running within minutes.

Note UNetbootin is a similar program for Ubuntu, but Vista support is still in the works.

There was one small hiccup. The Debian-installer loader ran fine, but a reboot brought be back to Vista (taking forever to load of course). After further research I discovered that I had to mess with the BCDEDIT program to set a nonzero delay so I could actually select Debian from the Vista boot menu.

Then deja vu. I was reminded of the first time I tried installed a Linux desktop: back then, it must have taken me a day to get sound working, and another for the network.

The wireless didn't work. Neither did the sound. The "vesa" graphics driver performed badly: switching back to text mode resulted in a blank screen. This system is too new for Debian.

I had read success stories using the development version of Ubuntu ("Gutsy Gibbon"), and a few unsuccessful attempts at getting the wireless working I figured I'd switch.

I tried to do so with UNetbootin (run from Debian) but I must have screwed something up because I was left with an unbootable system: the Grub bootloader had taken over the master boot record, and was somehow configured badly. To salvage the situation, I used a PXE network boot, and from a menu option I installed Gutsy.

The wireless network card (Intel 4965) worked out of the box, as did the "intel" video driver for X windows. Back when I first tried this, and before Gutsy was officially released, sound didn't work and I had to download and compile the development version of ALSA's "hda_intel" driver to rectify this. But the latest version works out of the box.

Various buttons such as the brightness and volume controls have no effect, but if I were so inclined, I could fix this by scripting commands with the aid of the ibm-acpi package.

Mission Accomplished

My laptop is now usable. Not only that, but it is orders of magnitude faster and smoother than any other system I use. I have more to say, but rather than delay this post yet again, I'll save the material for future articles.

Automating Automounting

Newer, friendlier Linux distributions such as Ubuntu must surely make it easy to use CDs, CompactFlash and SD card readers, USB drives, external hard disks and so on. But I'm old-fashioned, and like to do things the hard way, that is, edit /etc/fstab and run mount and umount manually so various devices end up at places I like in my directory.

The problem is hot-pluggable devices get assigned different names in the /dev directory all the time. So I followed the first part of this guide that assigns the same name (that you choose) to the same device every time. Once this is done, you can modify /etc/fstab in the usual way.

While there, you might want to use the "noatime" mount option, or at least "relatime". See this Slashdot article.

ALSA and MIDI

I switched to the ALSA driver from the OSS driver for my Creative Sound Blaster Live! card long ago, but I'm still not used to how MIDI is done. I'll record the relevant commands this time, so I won't have to look them up yet again.

Lately, I've had to manually load the snd_seq kernel module.

Programs I wrote that look at /dev/midi00 should now look at /dev/snd/midiC0D0. The behaviour of this device file differs too: I had to change my code so that it could handle a read() call that returned less than the requested number of bytes.

To play MIDI files on my digital piano, I run pmidi -p 16:0 foo.mid.

To send MIDI events to fluidsynth from my digital piano, I run fluidsynth 2> /dev/null (to get rid of spurious warnings), load a soundfont, then run aconnect 16:0 128:0.

Nvidia GeForce 3 Cards on Debian

For a long time I used the Debian nvidia driver packages, but GeForce 3 Ti 200 cards are now considered legacy cards, and not supported by the 97xx and newer series. After a recent upgrade, I had to remove my Debian nvidia packages and

1. Download the 96xx series Nvidia Linux drivers.
2. Run the install script as root.
3. Since I use the xorg X server, I had to move files around:
   mv /usr/X11R6/lib/lib* /usr/lib/xorg/modules/
mv /usr/X11R6/lib/modules/drivers/* /usr/lib/xorg/modules/drivers/
mv /usr/X11R6/lib/modules/extensions/* /usr/lib/xorg/modules/extensions/
   

Virtual Hosting

I finally added the following to Apache's srm.conf

NameVirtualHost *

<VirtualHost *>
ServerName wingchun.stanford.edu
DocumentRoot /var/www/wingchun
</VirtualHost>

<VirtualHost *>
ServerName rooster.stanford.edu
DocumentRoot /var/www
</VirtualHost>

so now rooster.stanford.edu and wingchun.stanford.edu look like different sites. However, for reasons I don't understand yet, in order to get SSL working on my whole site, I had to add an extra DocumentRoot directive to the VirtualHost _default_:443 section needed by mod_ssl.

I reinstalled the mod_dav Apache module, this time to play with some calendar and bookmark applications. I used to have it running a long time ago (see Netcraft's history of this site).

Recently I've been exploring a frequently-changing list of interesting bookmarks, containing (among other things) links to ephemerally popular pages like how to turn your hamster into a fighting machine.