St John Karp

The saga continues! I previously wrote about my laborious experiences compiling a 2.6 kernel for the Cobalt Qube 3 and getting a semi-modern Linux distro running on it. Those steps took me as far as Debian Wheezy, but official support has now ended for that release and the latest Debian won’t run on an i586 processor. So where are we supposed to go from there? Read on, dot dot dot.

Slackware and a 4.17.2 Kernel

Slackware is the only mainstream Linux distro (outside of Gentoo) that still supports the i586 architecture. I exclude Gentoo from that calculation because it’s a source-based distro and compiling all your software on a Qube will be ridiculously time-consuming, though you’re welcome to have at it if you’re that way inclined.

So a-slacking we must go, but will modern Slackware run a 2.6 kernel? Even if it does it would probably stop supporting it in the near future, and besides, there’s all those juicy kernel updates and security improvements that have been made since then. Are we going to miss out on all those? Are we buggery.

It took me a good weekend because I’m no C developer and know precious little about the kernel, but I eventually managed to port the old Cobalt kernel patches to a 4.17.2 kernel. I daresay there are even some improvements because the maintainers of the 2.6.36 patches had disabled the code that handled writing to the LCD panel and had misplaced some of the code for the Cobalt reboot routine. It wasn’t hard to uncomment that code and update it to work with the newer function calls. Again I want to state that I am not a C developer or a kernel expert, so these patches are unofficial, unsupported, and entirely at your own risk. That said they seem to be working pretty well for me and I’ve confirmed the Cobalt drivers do actually do their thing.

Here we go then, here’s how to get your Slackware up and running:

Update: When I wrote this originally it was for the 3.16.56 kernel source. I’ve since updated it for the newer 4.17.2 kernel, but I’m keeping the 3.16.56 patches online in case anyone needs them.

1. Plug your hard drive into a separate desktop and install Slackware 14.2. You can do this by booting from the installation media, or just handling the whole process via VirtualBox as described in my previous post.

2. Grab kernel 4.17.2 (the latest stable release at the time of writing):

   wget https://cdn.kernel.org/pub/linux/kernel/v4.x/linux-4.17.2.tar.xz
   tar xvf linux-4.17.2.tar.xz
   mv linux-4.17.2 /usr/src/linux-4.17.2-cobalt
   cd /usr/src
   ln -s linux-4.17.2-cobalt linux
   cd linux
   

3. Apply my 4.17.2 kernel patches:

   patch -p1 < ~/linux-4.17.2-cobalt.patch
   

4. I figured out a working kernel config through trial and error. Originally the kernel compiled to something like 2.3 MB, which was evidently too big because it just refused to boot. After stripping out some stuff that wasn’t relevant on a Cobalt and compiling a bunch of other things as modules I got it down to 2 MB and that seems to boot just fine on my machine. If it doesn’t boot for you, you may need to slim it down further.

   cp arch/x86/configs/qube3_defconfig .config
   

   I only created a working config for the Qube 3. The previous patch also contained some configs for various Raq machines, but I didn’t port those because I can’t test them. You should be able to use them and run “make oldconfig” to bring them up to speed with this kernel, but you might have to do some work to remove stuff you don’t need.

   Don’t forget to make any edits you need for your own hardware. In my case I compiled CONFIG_SATA_SIL as a module because I use a particular SATA PCI card.

   Update: After porting the Cobalt patches to 4.17.2, the size of the compiled kernel ballooned back up to 2.3 MB. I reduced it again by getting rid of as much as I could, which unfortunately included the RAID drivers. Please review your requirements to figure out what you need and re-enable them in your config, but you may need to take something else out or compile them as modules to keep the size down.

5. Compile and install:

   make
   make modules_install
   make install
   strip vmlinux
   bzip2 -c vmlinux > /boot/vmlinuz-4.17.2-cobalt.bz2
   cd /boot
   ln -s vmlinuz-4.17.2-cobalt.bz2 vmlinux.bz2
   

   When I did this the installation build step automatically put its System.map into the /boot folder, so no need to do it manually as we did in my last post. I also noticed it didn’t create an initrd.img, but then my machine booted fine without it so I won’t go dicking with it now.

6. Prepare the OS to be booted on your Qube.

   1. I had my drive plugged in as a USB device so Slackware detected it as /dev/sda. If this was the case for you too, you’ll need to edit the /etc/fstab entries from /dev/sda1 etc. to /dev/hda1 etc.

   2. Edit /etc/inittab to comment out the normal tty1, tty2, etc. and uncomment the first serial line ttyS0. Edit the baud rate of that serial tty from 9600 to 115200. It should look something like this:

      s1:12345:respawn:/sbin/agetty -L ttyS0 115200 vt100
      

      This will enable you to connect to your Qube using the serial terminal.

   3. You might also want to uncomment ttyS0 in /etc/securetty. Otherwise this will prevent you logging in as root via the serial console.

   4. Remove the network hardware automatically detected on your current machine:

      rm /etc/udev/rules.d/70-persistent-net.rules
      

      This will get automatically regenerated when we boot off the Qube.

   5. Set the ethernet speed correctly by adding the following lines to the top of /etc/rc.d/rc.inet1.conf:

      ethtool -s eth0 speed 10 duplex full autoneg off
      ethtool -s eth1 speed 10 duplex full autoneg off
      

Now everything’s jake — you can take your drive, plug it into your Qube, and boot ’er up. Plug in via the serial console to continue setting it up the way you like it. How do I know what you want a Qube for. Get your own ideas. Go on. Shoo.

Make the LCD Do a Thing!

What was the point of all that fiddling around with kernel drivers if we’re not actually going to use them? First I wanted to confirm they actually worked, so I did a couple of these:

cat /proc/cobalt/raminfo
cat /proc/cobalt/sensors/thermal

This spits out a bunch of data about the current RAM and CPU temperature, so we’re looking good on that front.

You can also run this:

cat /proc/cobalt/lcd

Now you can read what’s currently printed to the LCD panel at the back. But how the hell do you write to it? Turns out some angel-eyed developer called Jeff Walter created some utilities for interacting with the LCD panel, so let’s fire those up and see what’s what. His original site is now offline, but he did submit the source to the Debian repos at some point. You can download the source and compile it, then write to the LCD panel by running:

lcd-write "Skaboopy"

Go check your LCD panel — go on, I’ll wait. Isn’t that nifty?

I haven’t got the original program that shipped with the Qube to manage all the buttons, but it looks like these utilities will help you if you want to write a new program to do what you like with it. Personally I can’t imagine using the panel often enough to bother with that, but I did set up a little cron job to run this every day to display the Discordian date:

lcd-write "$(ddate +"%A")" "$(ddate +"%e %B")"

Hardware Recommendations

I had to go through some bum hardware before I figured out the smart way to do things, so let me save you some time. Don’t bother with an IDE hard drive. They’re all getting old now, and even if you find one that works it’s not going to last forever. Then what are you going to do? Make one? No, what you want is a 120 GB SATA drive to act as your main drive and an IDE-to-SATA adapter to plug it into the Qube’s IDE controller. You’ll need an adapter that specifically supports ATA 33, like this one from StarTech.com. If your adapter doesn’t mention ATA 33, don’t buy it — it probably won’t work.

120 GB is about the largest drive you can plug into that IDE controller due to the Qube’s hardware limitations. That isn’t a stellar amount of storage these days, so you may want some extra. You can plug an external hard drive into the USB port at the back, but it is USB 1.1 so be prepared for some glacial speeds. I preferred to grab a SATA PCI card, whack it into the Qube’s free PCI slot, and plug a 1 TB drive into that. Bob’s your auntie. Don’t forget to pick up a Molex to SATA power adapter too. You won’t be able to boot off this drive, but it will give you some bonzer extra storage at a decent transfer rate.

If you’re anything like me you’ll have got this far and, feeling very satisfied with yourself, prepare to put the lid back on your machine — only to find that the damn thing won’t close because your drives stick up too high. It appears that the old IDE ribbons had a pretty low clearance and the lid of the Qube was built without much wiggle room. Both my IDE-to-SATA adapter and the SATA cables for my secondary drive stuck up too high to let me shut the lid. Even replacing the SATA cables with right-angle connectors didn’t make them low enough, so you’re going to have to get a bit ingenious here. First thing is, make sure you get 2.5” drives, not 3.5”. It turns out 2.5” drives are short enough that you can just mount them one screw lower on the Qube’s mounting brackets. Sure, they’ll only be secured by one screw on either side, but they’ll fit into the slot like a dream and let you close that lid.

Now aside from the CPU, which can’t be upgraded beyond 550 MHz, there’s two remaining bottlenecks with these machines. One is the USB port which is USB 1.1 and crawls like a dead whale. The other is the ethernet, which is 10BASE-T and chugs along like Steamboat Willie. So far I haven’t been able to upgrade either because I already used up the PCI slot with a SATA controller. Too bad. If you’re not using a secondary drive you might consider a USB 2.0 or an ethernet PCI card (remembering to recompile the kernel with support for any new drivers you need). A USB card could theoretically let you plug in a fast external drive and a USB-to-ethernet adapter, but I haven’t been down that road. Personally I hear tales of a SATA-and-ethernet combo card, but I haven’t been able to track one down yet and I’m starting to suspect that they’re nothing more than the lonely dreams of old sysadmins, hunched and heating their frozen bones around a heatless fire, grown grey and wizened with years of disappointment.

Willya get a load of this thing? I totally got ripped off for it at the Ashby flea market, but god damn, it was worth it for a beautiful catastrophe of this calibre. It’s the Traid Corporation’s Fotron camera, a lemon sold door-to-door in the ’60s to housewives who were judged to be too dense to use a proper camera.

James Ollinger gives probably the best review of the Fotron I’ve read: “The result isn’t something bad like a Pho-Tak or a Holga is bad, this thing is bad on a Wagnerian opera scale. This thing could fire-bomb Dresden.” He’s not wrong, either. This camera is in nearly every way a monstrosity — an enormous plastic brick that could just as effectively be used to club muggers over the head or to break a window in case of an emergency. It used 828 film which was a standard film format at the time, but instead of using the standard packaging of this film on rolls, it loaded the film into proprietary cartridges which had to be returned to the Traid Corporation to be developed. Counting in its favor, however, are the pioneering built-in flash, an electric exposure counter, motorized film advancement, and a rather cute system of buttons for selecting the exposure and focus. If you wanted to make a kids’ camera a design like this wouldn’t be a terrible idea. I think we can give ’60s housewives a little bit more credit though, especially if they’ve got biceps big enough to lug this thing around in their handbags.

The photos it took were apparently pretty bad. I haven’t had the chance to experiment with mine yet because the capacitors inside don’t hold a charge for very long (or do I just need to let it charge for seventy million hours?) and because you can’t get 828 film in the proprietary cartridges any more. My camera does come with two unexposed cartridges of color film, so if I can get the camera to hold a charge for long enough I might take it for a spin. But even then the color film in the ’60s used a different development process that’s no longer standard, so I’d have a devil of a time even getting the film developed. Word on the street is you can develop color film as black and white, but then that seems to be missing the point — if I can use expired film from the ’60s, I want to see all those beautiful, wrecked, and unpredictable colors.

The Traid Corporation was the subject of a class action lawsuit in 1972 and went out of business shortly thereafter. If I’ve understood the legalese correctly, the plaintiffs complained not only that the camera was a heap of junk that took crappy photos, but also that they’d been sold for $491.60 a camera that was actually only worth about $40. The paperwork that came in my Fotron camera bag would seem to bear out the story that the camera took shite pictures. There are two notes from the Traid corporation technicians telling the owner why their pictures came out looking terrible.

According to the Internet the Traid Corporation produced three models of Fotron — a three-button model with a frame counter window, a three-button model with an improved frame counter, and a two-button model called the Fotron III. The paperwork that came with mine calls it a two-button Fotron III, but it clearly has three buttons so I’m assuming it was the intermediate model. Since all the instructions and warranty documents were crumbling I’ve scanned them and posted them here. They are beautiful bits of ephemera, what with the typed italics, the little warning that Traid couldn’t be arsed to charge the cameras before shipping them, and the warranty card (which was apparently a sticking point in the class action suit).

If some gorgeous thing plagues your life for three whole weeks, depriving you of sleep and sanity, it’s either an ex-boyfriend or a Cobalt Qube. I’ve wanted one of these for years — I mean look at it, who wouldn’t want such a beautiful computer in their house? But the expense was always a sticking point for me, even long after the Qube computers were current, until recently I spotted old Qubes going for about $70 on eBay. Ka-ching. Pick me up a cheap Qube, whack Debian on a hard drive, and Bob’s your aunty — adorable home server. Or so I thought. Little did I know that I was getting myself into three long, hard weeks of boot hell, kernel compiling, and painstaking upgrades.

But first, a little background. The Qube 3 is a square-ish computer designed as an easily configurable server with a web admin interface. The earlier models ran MIPS processors, but the Qube 3 runs an i586 AMD K6-2 processor. I gather they shipped different configurations of the machine, but the highest speed they sold was 450 MHz. My home server has been happily chugging along on a Sheevaplug for ages, but I’ve been irked for a while by the fiddliness of having the OS on an SD card, the lack of grunt of the 1.2 GHz ARM processor, and the fact there’s no good place to stick a hard drive. I thought, if I’m going to have a shit home server, it may as well be a cute one. I’ve determined that about the most modern release of Debian this is ever going to run is Debian Wheezy (still technically supported, but not for much longer). The process of upgrading the Qube to run something semi-modern is not straightforward, and this guide is for all you (one? two?) intrepid archaeonauts who want to make the best of beautiful old hardware.

Hardware Upgrades

Yes, you heard it here first. Raise that RAM to the mother-lickin’ roof. Mine came with a 64 MB stick of RAM, but you can upgrade it to a max of 512 MB. Do it! Grab some off eBay, stick it in, and boot it up. Amazingly, this was the only straightforward part of the upgrade process.

The CPU was held down by a tall, silver heatsink that did not want to budge. The clamps holding it down were merciless, and the thermal paste had hardened so much I thought the heatsink might actually be glued on. After prying at the damn thing with screwdrivers, I finally managed to free both the heatsink and the CPU without damaging the motherboard. Turns out the CPU that came with it was an AMD K6-2+ (450 MHz). Well I thought we can do better than that, so I popped on eBay and nabbed a 500 MHz K6-2+. That’s a performance boost of like… a ninth? Bonanza. Only when I booted, the ROM kept telling me the thing was only running at 450 MHz, or thereabouts. Turns out the jumpers for selecting the CPU speed aren’t actually jumpers at all. They’re resistors soldered onto the damn motherboard, under the CPU if you please.¹ Well I’m not taking a soldering iron to my motherboard for 50 MHz, so I guess I’ll stick with 450.

Now let’s talk hard drives. The Qube has room for two IDE hard drives, but the controller only permits a maximum size of 137 GB each. So far I haven’t had any luck replacing the 20 GB drive that came in the box. The first 120 GB drive I got off eBay was actually a mis-advertised 160 GB drive, and the second one I bought got delivered to Anchorage, Alaska. I live in California. I do, however, need something with at least a terabyte as a secondary drive so I can stream my music collection and run a small backup server. The Qube has one free PCI slot, so I bought a SATA controller card that has so far done nothing but throw “lost interrupt” errors and has prevented the machine from booting, so screw it. My 1 TB drive is currently connected with a SATA-to-USB adapter to the USB 1.1 port at the back of the machine. I’ve bought a USB 2.0 PCI card with an internal port, so hopefully that will give me slightly zippier storage. I’m thinking I can also get a USB-to-ethernet adapter and get some faster ethernet than the motherboard’s sluggish 10BASE-T.

The ROM

The Qube has a slightly bizarre boot process that’s going to inhibit everything we do from this point on. As far as I can tell it doesn’t load from the hard drive’s bootloader. It boots a minimal Linux kernel from its own internal ROM, which it then uses to load a secondary kernel from the hard drive. If it can’t load the secondary kernel, it will actually boot the OS using the ROM kernel. Being from 2002 the ROM kernel is version 2.2 (or something equally archaic) and won’t recognize an ext3 filesystem, but when Sun stopped supporting the Qube they open-sourced the ROM code and some enterprising developers made their own improvements.

You’ll want to grab the flashtool and latest ROM from the Cobalt ROM project. For the Qube 3 the appropriate ROM is cobalt-2.10.3-ext3-1M.rom.

1. Get yourself a serial-to-USB null modem cable and plug it into the serial port at the back of the Qube.

2. Boot the Qube while holding down the Reset Password button with a paperclip. This will enable the serial console.

3. From a Linux machine on the other end of that null modem cable, run:

   sudo screen /dev/ttyUSB0 115200
   

   You now have console access to the machine, and you’re going to be using this a lot.

4. We’re going to install a basic OS that will let us get started. The Qube supports netbooting, but fuck a lot of that, I’m going to use VirtualBox instead. Grab your hard drive and an IDE-to-USB adapter and plug it into your Linux machine.

5. Create a virtual disk mapped to your hard drive:

   sudo VBoxManage internalcommands createrawvmdk -filename /home/user/woody.vmdk -rawdisk /dev/sdd
   

   (or whatever your device is called)

6. Run VirtualBox (as root so you have access to that VMDK):

   sudo virtualbox
   

7. Create a new virtual machine with your VMDK file as its drive.

8. Grab an installer for Debian 3.0 (Woody) from Debian’s CD archive and set that ISO as the virtual machine’s CD drive.

9. Install the hell out of Debian, being sure to use ext2 partitions. Don’t worry about package repos — not yet anyway. We just need a minimal machine to flash the ROM.

10. Shut down the VM.

11. Copy your flashtool and ROM onto the drive.

12. Edit the /etc/inittab file to enable the serial console. I had to comment all the lines that enable tty1, tty2, etc., and uncomment the line that gives you a serial terminal:

    T0:23:respawn:/sbin/getty -L ttyS0 115200 vt100
    

    Make sure you’ve set the baud to 115200 as well, because by default it’s going to be 9600.

13. Move the hard drive to the Qube and boot it.

14. Back up your original ROM:

    ./flashtool -v -r > original.rom
    

15. Flash your new ROM:

    ./flashtool -v -w cobalt-2.10.3-ext3-1M.rom
    

16. Reboot and make sure your new ROM kernel boots successfully. You should be able to boot into Debian Woody at this point, but don’t worry, we’re not leaving it there.

Upgrade the OS Kicking and Screaming

Update: There’s a new post over at Cobalt Qube 3: Part 2 with more up-to-date instructions on compiling the kernel and installing the OS.

The Qube just does not want to run a modern OS. This is partly because the i586 processor architecture is all but unsupported these days. Debian dropped support for this with Stretch. Jessie will still run on an i586, but because of the fact we need a kernel patched specifically for the Qube and I haven’t been able to find a kernel patch for any version beyond 2.6.36, the latest Debian that we’ll be able to run is Wheezy. Getting us there is going to be a chore. You might think you could just install Wheezy on a hard drive, boot it from the ROM kernel, and compile your kernel right there. Nope. Nope. Big bag of nope. Wheezy won’t even boot with the ancient ROM’s kernel. So what we need to do is install the latest bootable Debian and start upgrading from there.²

1. Install Debian Etch on the drive using your Linux machine and the same VirtualBox procedure as above. When asked to configure the package repo, you can specify the Debian archival repo at http://archive.debian.org/debian/.

2. Boot Etch in VirtualBox and install the dependencies we’ll need to compile a kernel:

   apt-get install build-essential bzip2 kernel-package gcc libncurses5 libncurses5-dev bin86 gawk ncurses-dev initramfs-tools
   

3. Shut it down and copy to the drive all the Cobalt files we’ll be using. These consist of:

   • The 2.6.24 kernel source (Debian package):
     linux-source-2.6.24_2.6.24-7_all.deb
     

   • The 2.6.24 kernel patches for the Qube:
     linux-2.6.24.3-cobalt3-tw.patch
     

   • The 2.6.24 kernel config:
     linux-2.6.24.3-cobalt3-tw.config
     

   • An extra package needed for the 2.6.36 kernel:
     kernel-package_12.036+nmu1_all.deb
     

   • The 2.6.36.2 kernel source from Kernel.org:
     linux-2.6.36.2.tar.bz2
     

   • The 2.6.36.2 kernel patches, long vanished but still accessible courtesy of the Wayback Machine:
     linux-cobalt-2.6.36.patch
     

   • The 2.6.36.2 kernel config from the same site as the patches, but with a few fixes from me:
     2.6.36.2-3-cobalt-stj.config.txt
     

   • ethtool for Debian Wheezy, which will help us get the network online later:
     ethtool_3.4.2-1_i386.deb
     

4. Move the hard drive to the Qube and boot into Etch. We need to install a 2.6.24 kernel (but not greater) in order to upgrade to Lenny. After that we can install our 2.6.36 kernel.

5. Install the kernel source:

   dpkg -i linux-source-2.6.24_2.6.24-7_all.deb
   cd /usr/src
   tar -jxvf linux-source-2.6.24.tar.bz2
   mv linux-source-2.6.24 linux-source-2.6.24-cobalt3-tw
   ln -s linux-source-2.6.24-cobalt3-tw linux
   cd linux
   

6. Apply the Cobalt kernel patches:

   patch -p1 < ~/linux-2.6.24.3-cobalt3-tw.patch
   

7. Copy the kernel config:

   cp ~/linux-2.6.24.3-cobalt3-tw.config .config
   

8. Edit .config and set CONFIG_LOCALVERSION to “-cobalt3-tw”.

9. Prepare to compile:

   make oldconfig
   make-kpkg clean
   

10. Compile that mother! This will take a wee while. I’ve used the date as the revision number.

    make-kpkg --initrd --revision='2018.05.15.1' kernel_image kernel_headers modules_image
    

11. The previous step resulted in two beautiful new DEB files in /usr/src. Install them now:

    dpkg -i ../linux-headers-2.6.24-cobalt3-tw_2018.05.15.1_i386.deb ../linux-image-2.6.24-cobalt3-tw_2018.05.15.1_i386.deb
    

12. Create the vmlinux:

    make vmlinux modules modules_install
    strip vmlinux
    bzip2 -c vmlinux > /boot/vmlinuz-2.6.24-cobalt3-tw.bz2
    

13. Change into the /boot folder and configure the newly generated boot files for the Qube by setting up the appropriate symlinks:

    ln -s System.map-2.6.24-cobalt3-tw System.map
    ln -s initrd.img-2.6.24-cobalt3-tw initrd.img
    ln -s vmlinuz-2.6.24-cobalt3-tw.bz2 vmlinux.bz2
    

14. Reboot and make sure you’re now booting successfully from your 2.6.24 kernel (i.e. not falling back to the ROM kernel).

15. Move the drive to your Linux machine again and boot the VM. When GRUB comes up, you won’t be able to boot from your newly compiled kernel so just pick whatever came with Etch.

16. Upgrade Etch to Lenny by updating the release version in /etc/apt/sources.list and running:

    apt-get update
    apt-get upgrade
    apt-get dist-upgrade
    

17. Boot the Qube again. It’s time to compile a 2.6.36 kernel.

18. For some reason it won’t compile without a newer version of kernel-package, so go ahead and install that from the files we transferred to the Qube earlier:

    dpkg -i kernel-package_12.036+nmu1_all.deb
    

19. Unzip the source for the new kernel:

    tar -jxvf linux-2.6.36.2.tar.bz2
    

20. Compile the kernel using the same steps we used for 2.6.24. I used the 2.6.36 patches I found on the Web. They came with a kernel config that didn’t entirely work with subsequent versions of udev that we’ll get to in a later upgrade, so I made some tweaks and you’ll want to use that. It’s going to take considerably longer to compile than the 2.6.24 kernel did, so leave it overnight.

21. When it came to linking the new initrd.img, I found the compiler hadn’t generated one for me. No worries, we can do it ourselves:

    mkinitramfs -o /boot/initrd.img-2.6.36.2-cobalt.img 2.6.36.2-cobalt
    

    Remember to remove the symlinks we previously created in order to link to the newer kernel.

22. Plug the hard drive into your Linux machine and boot the VM again.

23. Upgrade Lenny to Squeeze.

24. Upgrade Squeeze to Wheezy. Now you’re upgrading to a supported distro, so you can change your repo URL to a current one instead of the archive (e.g. http://ftp.us.debian.org/debian/). By the time you read this it may no longer be supported, in which case stick to the archival repo.

25. Boot the Qube again. We’re now running Wheezy — huzzah! But there’s some additional steps we’ll need to get a few things working.

26. I needed to run “depmod” to get the kernel to generate/load/whatever the appropriate modules. Without that everything was SNAFU’d.

27. Remove the ethernet device definitions that will contain the virtual network card from VirtualBox because that virtual card buggerizes things a bit:

    rm /etc/udev/rules.d/70-persistent-net.rules
    

    Don’t worry, this file gets regenerated with the correct settings when you reboot.

28. Install ethtool, which will help us get the network running properly:

    dpkg -i ethtool_3.4.2-1_i386.deb
    

29. At this point I had a working OS, but no network! Turns out the OS tries to read the ethernet adapter as 100BASE-T when it’s only 10BASE-T, so we’re going to need to tell it what speed to use. Add this line to the end of the definition of eth0 in /etc/network/interfaces:

    up ethtool -s eth0 speed 10 duplex full autoneg off
    

30. Reboot — and there you go! Your own working, (semi-)modern Cobalt Qube 3 in only seventy million easy steps.

You’re welcome to go dickering with these steps — I’m positive there’s a lot of room for improvement, but I spent a long three weeks working these out by trial and error, so when I got to a working set of steps I wasn’t inclined to go screwing with it.

Where to from Here?

At the moment I’m quite happy with Wheezy. As of writing it’s still supported, so it has all the backports and security updates necessary to run a secure server. In the future I’ll probably wind up compiling more of my own software to keep it up to date. In terms of speed it’s not the flashiest thing in the universe, but it sure is the sexiest. I’m even running Subsonic on it to stream my music, and although the UI is a tad sluggish the MP3s are streaming flawlessly. Provided Subsonic doesn’t have to transcode anything, software really isn’t involved — the bottleneck is probably going to be the hard drive and ethernet speeds.

IMHO this is about as far as you’ll be able to upgrade the Qube without a newer kernel. I see no good reason the Qube shouldn’t be able to run Debian Jessie (the last Debian release to support i586) or the latest version of Slackware (still supports i586) if someone were able to patch a newer kernel, but that is waaaay beyond my level of expertise. Any volunteers out there? Can it be done?