Updated: Yes, I did try Google. Thanks to all those who pointed out world.std.com (alias for TheWorld.com), and clss.net (most recently used in 2005; no active nameservers); sorry I forgot to mention that.

I am considering merging this with GNU Unifont, so that the many missing characters show up looking out-of-place and non-matching instead of completely blank.

Also, see xterm bug 456236, which should be fixed in unstable soon. Or mostly fixed, anyway; it still seems to glitch once in a while but it’s harder to reproduce now.

I have been using the same font for my consoles since before 1997. This is, or at least was, the default Linux console font back when I did all my work on a VT on Linux/PPC: /usr/share/consolefonts/default8x16.psf.gz. When I started using X routinely I missed it quite a lot. Mostly that was because I used BitchX, and BitchX is written for an IBM437 code page set of line drawing characters. So I opened up that console font in xmbdfed and converted it to a PCF file. If you have Debian’s BitchX package installed, you’ve got a copy of this work in /usr/share/fonts/X11/misc/default8x16.pcf.gz.

So I’ve done the same trick again. Here’s the steps I followed:

• Open the PCF font file in FontForge.
• Choose Add Enconding Name… from the Encoding menu.
• Enter IBM437, which is the iconv name for the traditional PC ROM character set.
• Choose Force Encoding and select IBM437.
• Choose Reencode and select ISO 10646 (BMP).
• Choose Generate Fonts… and save it as a BDF file, since PCF wasn’t an option.
• Create a fonts.dir file by running mkfontdir.
• Add the directory to the font path using xset +fp.
• Attempt to start an xterm.

Actually, after all that I was having trouble with the font’s name and eventually getting scary resource errors from X. I opened the font in gbdfed and saved it, which added some attributes and modified the bitmaps. Then I tried again and it worked.

And now, I can use a UTF-8 locale and gcc’s error messages come out with `foo’ (”angled” quotes) instead of display corruption!

The resulting font is uni8×16, if anyone else would like it. I have switched to using it for all my terminals other than the one I run BitchX in; BitchX still needs the IBM437 version in order to display correctly.

Of course, as soon as I finished this Paul Brook informed me that Konsole includes basically the same sort of font. I do not know the origins of KDE’s console8×16, but I do know that it’s a slightly different font (the @ has a smaller center, for example). And I know that I’m mighty annoyed it didn’t get added to my font path correctly when I installed konsole ages ago, since I might otherwise have found it!

HARDWARE ERROR. This is *NOT* a software problem!
Please contact your hardware vendor

Now, that may be true, or it may not be. Certainly the disclaimer is sensible, since machine checks are usually caused by failing components. And it persisted for most of a day every time I tried to boot the machine, but there was quickly a new addition: different scary errors on ata1. And it got rapidly worse. On Friday morning, having let the machine cool and relax overnight, I brought it up on a rescue CD and could get at /boot (a separate partition), but not at /etc (from inside my RAID/LVM setup). I went out and bought a new SATA drive and attempted to recover /boot onto it, but I had waited too long; at this point I could still get at the partition table, but not the contents of /boot.

Some things to note here.

• As far as I know, you still need a separate /boot if your root uses RAID + LVM.
• Therefore your /boot is obviously not backed up by your carefully constructed RAID.
• But that’s fine because all that really mattered was your kernels, and you have them still lying around on your mirrored disk. Right?
• Of course, right. But dynamically generated initrds, while technically awesome, are awkward to recreate from a rescue CD. Especially a 32-bit rescue CD when your root filesystem is all 64-bit.
• It can’t be hard to find a rescue CD with a 64-bit kernel, right? No, not right either. I did eventually find a 50MB Gentoo install CD that worked serviceably well.
• Your laptop has a convenient CD burner, right? No, not right, turns out it doesn’t write CDs after all. Oh well, Windows file sharing plus the wireless plus the Mac Mini in the other room… there you go.
• You didn’t need anything else from /boot, right? Like your carefully constructed voodoo incantation to boot Windows… whoops… hopefully you remember how that worked…

So, after some futzing around I was able to boot the Gentoo rescue CD, partition the new hard drive, mount the remaining disk in degraded mode, reinstall the handy Debian packages of my kernels, have it magically recreate ramdisks, and then reinstall grub. By the way, --no-floppy obviously means something different to grub than it does to me, as most of the reinstalling grub process was still spent waiting for my non-existant fd0 to time out. Then I added the new disk to the array, let it reconstruct for two hours, and rebooted.

Lo and behold… no more machine checks! I am a happy camper. Despite the tribulations above I came out remarkably well, since I seem to have lost nothing but my grub menu.lst file. And now I have rdiff-backup configured to back up /boot onto the array in case I ever need to do this again.

HARDWARE ERROR. This is *NOT* a software problem!
Please contact your hardware vendor
CPU 0 4 northbridge TSC 6eb92ec370b
  Northbridge Watchdog error
       bit57 = processor context corrupt
       bit61 = error uncorrected
  bus error 'generic participation, request timed out
      generic error mem transaction
      generic access, level generic'
STATUS b200000000070f0f MCGSTATUS 4

It’s not even bad RAM or a bad RAM socket, the way most memory errors seem to be; I had two DIMMs in two sockets so I was able to try for both possibilities. Unless it fried both somehow, of course. It seems to boot a little further when left cold for a while, and not as far just after crashing. I am inclined to suspect the motherboard.

I think I’m going to have to write it off as a loss. Which means I need a replacement. I can get by with just my laptop for a little while, but not indefinitely.

Are there any good options for pre-built Linux systems yet? I was somewhat underwhelmed by Dell’s. I usually build from parts, so looking at pre-built systems always has a certain amount of sticker shock. My main concerns are CPU / memory performance (a lot of compiling here), room for at least three hard drives, and reasonably quiet.

Otherwise it’s off to newegg again…

Or I could always buy an equivalent computer to my current one, for a fraction of the original price, at a local consumer electronics megastore! How’s that for a different idea.

If nspluginwrapper works, it will kill two of the reasons I run a 32-bit firefox on my amd64 desktop (flash and the Acrobat plugin). I have firefox working quite nicely using schroot, but there are some inconveniences - like having to mount my sshfs filesystems once outside the chroot where I want them and once inside the chroot so that I can access them in firefox. And having to keep a ton of stuff installed in the chroot, too.

Of course that leaves the one other gaping omission: there’s no official 64-bit Sun Java browser plugins yet. Blackdown had a 64-bit browser plugin, but there were a number of reports of its crashiness. And there was a lot of ambiguity in the web pages I found about whether IBM’s JRE had one or not. So I fought with IBM’s registration today (their database server must’ve been horked this morning…) and downloaded their Jave 5 JRE. Well, it doesn’t. No plugin except for IA32 and PPC32. I’m guessing from the links in the documentation that the guts of their browser plugin still come from Sun. Sun claims that JDK 1.7 will have such a plugin, but no one seems to have seen it yet.

I think the only realistic way this will work out is to try building one from OpenJDK, and that’s more work than I have time for this evening. Back to the chroot for now…

This blog is one of the first services I’ve moved to my new hosting at Slicehost. I don’t have a lot to say about these guys yet, since I haven’t had any trouble. The only downside was catching them at a somewhat turbulent and resource-starved time as they dealt with a wait list for orders, so it took a month for me to get one. They’re working on that problem, though. Towards the end I was checking every two days or so how long it said I’d have to wait. Note to everyone, progress bars that don’t progress are just infuriating. But I happened to check one day during the five minute window between when they sent me confirmation and when my mail client checked for new mail, and poof there it was.

This is virtual hosting - Etch on Xen - thus the “slice” naming. They’re a heavy on automation shop, which fits right in with my style. And there is something so viscerally awesome about entering your credit card number, clicking OK, having their software allocate and create a virtualized disk, bootstrapping Etch onto it, and showing you its IP and root password. It doesn’t get much better than that. So far I’m happy.

I took the opportunity to move to WordPress, away from my old hacked up Blosxom installation. WordPress imported entries easily, although I had to manually fudge the RSS file to prevent it from inserting a log of bogus <br> tags that I didn’t want in the middle of my paragraphs. I probably could have gotten comments imported too, but I didn’t bother - sorry folks, well, it’s not like there were a whole lot of them. The Debian WordPress packages work fine, although the configuration is a bit messy; my biggest complaints were the centralized upload and themes directories so that I had to mess around with symlinks in /usr to get everything going.

Maybe I’ll actually use it more :-) I hacked up the GUIDs a bit by hand, so this shouldn’t flood planet, but here’s hoping.

Next step: migrating email service to the new system. Always a joy.

I use jpico rather than joe, you see. But I started using it a long time ago, probably around when joe 2.8 was current in Debian. And the jpico key bindings keep changing! Which is infuriating, so I keep having to rewrite my keybindings to stay mostly the way I like them.

I like that emacs is such a smart editor. Especially since it defaults to all sorts of nice GNU-ish settings and most of my C is for GNU projects. But when I work on other things, I have to learn how to make it either disable smarts or use appropriate ones, so in self defence I keep learning new things about emacs…

One things I’ve been annoyed at before is the binding for scroll-other-window. You can split a window into two (C-x 2). I often do that while writing a changelog up top of a patch file, whether I’m using joe or emacs at the moment. An advantage of emacs is that you can scroll the window that the cursor isn’t in, paging down through the text you’re describing while keeping the cursor where you’re writing. But it’s bound by default to C-M-v and C-S-M-v (control-meta and control-shift-meta). Hard to hit C-M-v, and impossible to enter C-S-M-v; you can not distinguish Control and Control-Shift in a vt100 terminal (like, say, inside of screen).

Fortunately, you say, it’s also bound to M-next and M-prior (meta-page down and meta-page up)? Well, yes… but… you can’t type that either at a terminal. Normally. I can now though.

Fixing it took two parts. First, I discovered that Meta-next sent the same sequence as plain next, in my xterms. I think I’ve convinced myself this is a bug in xterm. My keymap, which is a pretty standard pc(pc105)+us+altwin(meta_win), has Super_L and Hyper_L bound to modifier 4 along with Meta_L and Meta_R. xterm sees these strange keys and decides that mod4 must be some sort of “other” modifier, in code that looks like it’s for handling num lock. Fortunately, I can work around this easily. I don’t have a Super or Hyper key, so I deleted the bindings by adding this to my .xsession:

  xmodmap -e 'remove mod4 = Super_L'
  xmodmap -e 'remove mod4 = Hyper_L'

UPDATE: This will be fixed in xterm #223, since Thomas Dickey agreed it was a bug.

Next, I discovered that emacs didn’t recognize the sequence produced after that fix. It didn’t recognize C-next or A-next either. So I added this to my .emacs:

  ; Key magic.  Emacs nor terminfo normally have bindings for these.
  ; The meta binding in particular takes a bit of X magic also; see
  ; the xmodmap call in /.xsession.
  (define-key function-key-map "e[6;5~" '[C-next])
  (define-key function-key-map "e[6;9~" '[M-next])
  (define-key function-key-map "e[6;3~" '[A-next])
  (define-key function-key-map "e[5;5~" '[C-prior])
  (define-key function-key-map "e[5;9~" '[M-prior])
  (define-key function-key-map "e[5;3~" '[A-prior])

That really should be conditionalized on the terminal type, but I didn’t want to mess with it any more. And now it works. Woohoo!

Since then, Paul added real PCI support to the ARM qemu. So I expected everything to be much easier. I took Aur�lien Jarno’s excellent writeup and prepared to try again. But since we already had a functional ARM disk image, that was lower priority… I decided to try MIPS. I helped get the MIPS softmmu port working about a year ago, but it hasn’t been receiving a whole lot in the way of care (though there’s a bunch of unreviewed patches for it).

First I discovered that I’d never gotten initrds implemented last time I worked on qemu-system-mips. So I hacked that together. Then I needed a drive; I used root NFS in my last setup, but the whole point of this experiment was to avoid that. So I added the emulated ISA IDE controller. Good news: both of those worked easily! And the d-i session starts up OK, and even writes to the disk OK; partition tables were discovered at next boot. I’ve posted some patches for these.

Bad news: it hangs during formatting the swap partition, consuming endless CPU. It’s definitely doing _something_ in userspace, but I’m not sure what, and it’s hard to find out. I’ve heard other reports of faulty MIPS emulation recently, too. I know how to debug this sort of thing, but it’s really more time-consuming than I can manage now :-(

While waiting for builds in that, I resolved to try reproducing a nasty kernel bug in qemu for x86-64: since I booted into 2.6.19-rc1 all my coredumps have been truncated very short. My normal hardware kernel boots OK, but if I rebuild the kernel with the default config and debug info, it doesn’t:

checking if image is initramfs…it isn’t (bad gzip magic numbers); looks like an initrd
Freeing initrd memory: 5498k freed
*hang*

And the other thing that’s apparently not been getting a lot of love lately is the debugging stub; if I attach GDB, it dies much earlier, so I can’t set a breakpoint at initramfs detection to see what’s going on.

Overall result for the day: Argh!