Subsections

2 The Challenge

The transformation from mere WebPad to Useful Computer essentially requires, in short, installing Linux. This will seem, initially, to be no difficult task since ProGear's already runs Linux, some of them anyway, and certainly one could just start installing new apps onto the machine. However, this has a few shortcomings and at least one serious obstacle.

Files can be retrieved using Netscape or ftp, the latter fortunately being one of the few tools included in the factory system, but the stock ProGear lacks all development tools so installing anything from source is out and you must start by using prebuilt binaries or building things on a different machine. The Progear also initially lacks any package management tools, not just the complete auto download/update, keysigning, dependency checking standards like dpkg or rpm, but even Slackware's own installpkg. tar, however, is present (if I recall correctly) so you can at least pack things up into .tar.gz's and install them without having to manually place every file in the filesystem.

2.1 Minimal Slackware Update...

This is a perfectly sufficient minimalist means of expanding functionality though in practice there are obstacles to getting apps installed this way to run. The libc6 present is a relatively old 2.1(.3). The latest version is 2.3(.2) and even debian stable, and the oldest Slackware version I could find on the Web was 2.2 based. So trying to launch just about any binary you find lately, even old Slackware supplied binaries, will yield a gripe about libc being too old. A similarly dated ld-linux occasionally presents similar problems.

You can try rebuilding things linked to the older libraries, but that will get tedious fast and you should really just update the libraries on the ProGear. I was wary of doing this as I was worried about introducing some possible weird version incompatibilities with the rest of the base system that would prevent the machine from booting, or even just preventing a full launch to X, or breaking the network connection. I was completely paranoid about this possibility for a while since recovery is so difficult, as discussed in more detail below, so I never did it. But it is probably perfectly safe. Keep the old library files around for a while. Even though mv, cp, ln, rm depend on them, those probably wouldn't break to the point that you couldn't put the old versions back in place should there be trouble. You could also install some statically linked versions of these tools working before mucking around.

2.2 ... or Install from Scratch

My patience for figuring out package dependencies and keeping track of all the files on the system manually has long been exhausted. So even though I was raised on Slackware, I have long since abandoned it, finally in favor of Debian. Naturally I wanted to use Debian on the Progear. Superficially this would work fine, after the previous aging library trouble was addressed. You could install dpkg and apt and start piling thing on, the dependencies would be managed effortlessly.

But details, like the filesystem hierarchy and boot scripts are different between the two systems and this will start to cause trouble. You will need to do extra work to get things like wwwoffle, fetchmail, exim, ssh,.... started at boot. Eventually you will want to install something that wants to upgrade X, which will cause all sorts of trouble, first while just setting it up, second for trying to keep the old Progear apps running, and third getting the extra features like screen rotation, and joystick working. You will have to modify either the new packages to work the Progear way, or convert the Progear to boot in the way Debian is used to. The differences are so common, and the factory Progear modifications and streamlining so invasive that it will take as much work or more making the two systems work together as it would to just install a new system from scratch. So I chose to basically scrap the factory system and the project became a (modified) clean install, with the certain complications discussed below.

I, at the same time, wanted to keep the original user environment available, if only for nostalgia. Since the two don't easily mix, I chose to install debian on a separate partition, though could also have just been a separate directory, and made this a dual boot system. Though as you will see, initially both systems boot the same original Progear kernel, from the same image in the same place, and the transition is effected via a chroot to the root of the debian system before starting X. For most purposes this is all that will ever be necessary.

2.3 Upgrading the Kernel

Supplementing the machine with a Debian system, or anything else, in this way is straight-forward and quick. Though X will still require some work to enable a familiar features (Screen Rotation, Joystick input), the rest of the hardware and basic system functionality (PCMCIA, USB, sound, battery status, suspend, ...) is already taken care of by the stock Progear Kernel. At some point you will probably want to upgrade the kernel, either to keep up to date with performance features and security, or simple to add support for new hardware or software, (wlan, cuecat, Win4Lin). Here you finally run into some difficult problems and this is the fundamental reason why installing Linux on the Progear, which already runs Linux, is not completely trivial.

The core kernel is easy. You could get a toaster to boot Linux trivially if it had an IDE hard drive, or an alarm clock without one with only slightly more work. The challenge is getting the rest of the hardware, the devices, configured operating properly. In the case of the Progear much of the hardware, or certain features of it, are supported in the factory Progear kernel by custom devices drivers. Controls for dimming the LCD or shutting it off are handled through a dedicated custom device, as is suspending/sleeping the machine. The PCMCIA drivers are modified slightly to cooperate well with suspension. The sound driver has been tweaked for purposes I haven't yet figured out, and certain low level interfaces, the i2c bus in particular, have been modified, apparently to work around some hardware implementation problems, so that they can be used to, among other things, monitor battery status. Much of this stuff should have been handled through ACPI, but for some reason wasn't, so restoring their functionality requires porting these device driver and tools or configuring standard Linux drivers and programs to handle them properly. In the end I was able support everything but the LCD dimmer and DPMS controls using drivers in the stock kernel, or standard driver projects like lm-sensors and i2c, pcmcia, and acpi. Though even with that I don't yet get the suspend lifetime performance that the custom power management drivers yield.

2.4 Complications

The other important difficulty is due to the fundamental nature of tablets, and limitations of the Progear BIOS. These days installing Linux is usually as easy as putting a CDROM in a drive. The Progear, of course, has no internal drives other than the hard drive. There is a USB port, but the BIOS is unable to boot off devices connected to the USB port. So booting from a floppy or CDROM is completely out. The BIOS is similarly unable to use any sort of PCMCIA device for booting. The only way to get anything on the the hard drive then, is to remove it and put it on another machine, or boot off of it. The former is perfectly reasonable, if tedious and uneasy, and I discuss some details of this method later as I eventually had to do it anyways when wanted to upgrade the harddrive, but fortunately, until you screw it up, the latter is possible.

Installing through the existing OS is also made somewhat laborious by the lack of a keyboard. The first bits are fine to manage with just the pen and the on-screen keyboard, but later this becomes too much work, in particular when trying to configure X windows on the new system. Since any onscreen keyboard can only work after X starts, if you don't get things right, and X doesn't start, your only way out is a reboot and so it is a long way around to correct even a single simple mistake, though fortunately not fatal. I tried to stick to only using the pen just for the sheer artificial intellectual challenge, but I got sick of that quickly. The Progear kernel includes loadable module support (but not BIOS support) for a USB keyboard, get one and plug it in and work from the console. Or install sshd or telnetd and log in from a different machine with a keyboard.

Either works fine until you mess up USB or PCMCIA support, or do something else that results in the system failing to start before loading the appropriate modules. This usually might happen with a misconfigured kernel or PCMCIA, or messed up init or hotplug scripts or module configuration, that fail to automatically load the proper modules, or some new library that fails to allow some system to work properly. These possibilities will come up regularly when upgrading so it will require more attention later, but for the initial install, since we intend to leave the stock system alone and play around only in an isolated filesystem, there is generally no danger of messing up the original system except for at least one possibility.

If, while using the new installation or otherwise, crash the machine in such a way that fsck can't repair the filesystem by itself during the next boot, you are stuck. The keyboard support is from the kernel module, not the BIOS, and it is included as a loadable module, not compiled into the kernel. FSCK works before mounting the root file system. If fsck fails, root never gets mounted, and modules will never get loaded. Even if you had the modules in an initrd.img, the modules are still not loaded, even though now they are effectively available, until after root is mounted. Either way the system is effectively dead to the world. You can do a little better if, for example, USB keyboard support is compiled in in which case the keyboard will be functional somewhat before fsck might require it, but that is not the case with the Progear kernel.

Otherwise, since the BIOS does not support the keyboard itself, even if you happened to have another root filesystem on a different partition, or a different kernel with compiled in keyboard support that boots far enough to load it, and you already had lilo set up to allow it as an option, you are unable to use the keyboard with lilo before booting to select a working alternative. And as you can't boot off a rescue disk to fix things you are really finally reduced to removing the hard drive anyway to fix it on another machine. Annoyingly, I managed to do this twice while trying to set up the new installation, though I was, at that time, being a bit reckless in my overconfidance.

I should mention that I have heard of others using the keyboard to manipulate BIOS settings in the usual way by pressing F2 or F8 or something before booting. In this case there must be BIOS keyboard support because it is used before the kernel gets involved. However, elsewhere I have found that the Progear technical docs say otherwise and personally my BIOS can't help my keyboard. Maybe this was a feature of a later BIOS version.

For at least my case then, the lesson is watch out when booted from the Progear kernel, be prepared to have to remove the hard drive to possibly have to fsck it on another machine, and even after the initial install, consider how any change in the system might cause it to fail and arrange to be able to avoid as many traps as possible. In this way the process becomes much like installing or upgrading a remote system, the same cautions apply and many of the same procedures are effective, [Jacobson]. More ideas for effecting these sorts of failsafes are discussed with [*] Replacing the Kernel, and in [*] Stability Notes.

SourceForge.net Logo