Booting a Qube 2 from compact flash

[Sanguinary]

In case this is interesting to anyone, I have a Cobalt Qube 2 running off a compact flash card via a CF-IDE adapter, using unionfs to unify a tmpfs filesystem with a squashfs read-only filesystem. I use the machine as a dial-on-demand modem (being stuck on dialup), with a modem in the Qube's PCI slot. The Qube has 128 MB of ram, and, with a minimal 2.6.15.4 kernel, boots up with roughly 47000K free. The system has worked beautifully so far.

The Qube was running with a 30 gig hard drive, which was virtually unused, and seemed a waste of space and power. I used the running Qube to construct the necessary components to create a working CF-based system.

My kernel is mips-sources-2.6.15.4, with virtually everything stripped out and such kernel stalwarts as NFS left as modules (in case I need them at some point, although I've never modprobed them on the CF-based system). The kernel is also compiled to minimize size, which I believe is a relatively new kernel option.

Added to that, I patched the kernel sources to support squashfs, which isn't available in mips-sources, but, so far, has worked just fine. Even though unionfs is masked on mips, it also seems to work just fine. I emerged unionfs-1.1.3, which results in a kernel module. My gut feeling now is that I should have just patched the kernel sources to build-in unionfs support (as with squashfs), but my setup works as it is, so I'm not going back to fiddle with it.

I then emerged squashfs-tools, and used that to build the squashfs root filesystem. The big items left out were /usr/portage (leaving the CF-based system unable to emerge anything, but since all filesystem writes go to ram, emerging things would be a bit silly) and /usr/src.

The significant hurdles came in trying to boot the thing, using the Colo bootloader. The first problem is that I simply do not understand the references in the Colo documentation regarding booting a kernel with an initial ramdisk. I needed this or the functional equivalent to modprobe the unionfs module and then pivot_root into the unified filesystem.

My solution: I faked it on the CF card itself. I copied just enough files (e.g., /bin/sh, /bin/mount, /sbin/modprobe, /sbin/pivot_root, and similar files, plus the required libraries) to allow the kernel to boot with an "init=/linuxrc" command line. (The big problem here was that my initial attempt just copied the symbolic links to a bunch of libraries, so none of the programs would work.) The linuxrc script then modprobes unionfs, mounts the squashfs and tmpfs filesystems, unifies them, then pivots_root into the unified filesystem and passes off to the real init.

I built all this on my spare Raq2's original 4 GB hard drive until I got it all working (since my Qube provides my internet connection, I couldn't directly experiment on it). The only thing of note was neutering the now-pointless checkroot script, which was done per the suggestion in this thread: https://forums.gentoo.org/viewtopic-t-356951.html

On switching over the actual CF card, Colo presented the final problem: Colo does not like CF-IDE adapters. Although it will be loaded from the CF card, it will refuse to mount the card itself, complaining it is not an ATA device. The problem is that the ATA specs were changed with the advent of CF cards, and they respond to identify requests differently, and Colo doesn't interpret their responses correctly. Until Colo supports CF directly, the simple solution is to make one small change to the source code, specifically in file ide.c, commenting out the code that tests if the device is a valid ATA device (since you know it is).

Once this was all done, the system boots and functions correctly. There is only one real oddity: on booting, the kernel spends some time probing for and complaining about non-existent hdc and hdd ide drives. It didn't do this with the hard drive version, so I suspect the CF-IDE adapter is odd in this respect. It does not appear to cause any problems, other than slowing down the boot process.

[Redhatter]

Nicely done

A tip on the initrds... Debian actually use initrds to load their kernels... so you might want to have a look at the way their NFSroot image is structured.

This is how I got the current netboot images going, although I use initramfs, not initrds.

On the hdc/hdd issue... there are parameters apparently for turning this off, but I've never really looked (hdc=off, hdd=off or something like that), but yeah... it's annoying. For what it's worth... I see the same thing on my x86 desktop, whose only IDE device is a DVD reader. (The HDDs are SCSI)
_________________
Stuart Longland (a.k.a Redhatter, VK4MSL)
I haven't lost my mind - it's backed up on a tape somewhere...

Gentoo/MIPS Cobalt developer, Mozilla herd member.

[Sanguinary]