Installing Linux on a Compaq Contura Aero 4/33C Laptop
This Linux install became 3 weeks in the middle of my very own "Linux Nightmare" of the "so close & yet so far" variety.
Although I used Slackware distributions prior to kernel 2.0.x, I chose to give RedHat 4.1 a try. Aside from a few odd idiosyncrasies, it installed & ran just fine on my desktop. So, naturally, I started out with it for my Aero install. While I don't have a parallel or PCMCIA cdrom, I do have an Ethernet card (paid all of $40 for it...there are deals on older stuff, ya just hafta look!).
So I figured it was a no-brainer to NFS my desktop's cdrom, fire up a Linux NFS boot kernel, NFS mount the cdrom, & I'd be off to the races, so to speak. Naturally I have Samba running on my desktop so it was no problema to copy loadlin & boot & root images to the laptop's hard drive. Without unplugging the Ethernet card, I booted & got RedHat's startup screen, followed by a screen asking me if I wanted PCMCIA support. I answered yes, & I was prompted to put the "supplementary" diskette into the floppy drive. Uhhh, that wasn't so good: note one little detail from the specs: the Aero's floppy plugs into the single PCMCIA port - the kernel crashed when I unplugged the floppy & plugged in the Ethernet card (likely unexpected interrupt?).
I searched the cdrom for a boot/root pair that supports PCMCIA - no dice. First, I fired off a message to RedHat asking if they had anything that might help, eventually receiving advice to check out the various Linux Laptop pages. Not helpful - already been there, already done that.
Next I spelunked thru the cdrom's subdir tree & figured out from makefiles how to build images. It took me a couple of days before I got smart enough to look through the Linux HOWTO list & found the Bootdisk-HOWTO. With all this newfound knowledge I went about trying to create my own root image with PCMCIA support. I succeeded building a root image & booted, & ran into the next roadblock. The next little problem I discovered, the /etc/pcmcia/config file listed a "IBM Home and Away Adapter", but I reflashed mine with a file I found at IBM's web site & it now reports "IBM w95 Home and Away Adapter". So I added a "w95" config & rebuilt the root image. That brought me to the last problem - or, rather, the one I gave up on. I managed to get the kernel booted only to find there was no "ifconfig" on the root image. Seems RedHat includes "ifconfig" in the source of the 1st of the 2-part install program but not in the 2nd part. So, yet again I started down the road of making yet another root image with "ifconfig", but couldn't bring it together before I ran out of my computer room in a howling, screaming fit! Arrrggggghhhhhhh!!!! Sometimes you just need real beer, virtual just won't do!
Ok, to heck with RedHat, I'll try my Slackware 3.0 with kernel 1.3.20. Only, when I tried booting the "net" boot image & PCMCIA root image with Loadlin 1.6, some undecipherable voodoo about "couldn't find setup" printed on the screen. I could find no patience to fix this problem just to install an older kernel.
Ok, to heck with RedHat & Slackware , I'll just order a Debian cdrom. I have a friend using Debian so after a discussion with him I ordered Debian 1.3, Slackware 3.4, & an archive set from Cheapbytes - $10 for the whole mess, tho I did add another $5 donation to Debian. The 2nd-day shipping almost cost more than my order!!!
After receiving my order I messed around with Debian - I concluded from something I read on the cdrom that PCMCIA support was indeed included on the root image. After booting I couldn't find any PCMCIA stuff. Rather than "push that chain", I decided to try the Slackware cdrom.
Loadlin 1.6 booted the Slackware "net" boot image & "PCMCIA" root image but the system crashed when the pcmcia_core module probed memory. So, it was "change the root image" time again!!!
After I unzipped the PCMCIA distribution, I tracked the error message to a file called rsrc_mgr.c which is linked into pcmcia_core.o. I thought about hacking it, but after a bit of spelunking thru man pages & sources I discovered the switch "probe_mem=0" should prevent memory probing. So instead of hacking rsrc_mgr.c, I hacked rc.pcmcia to work specifically with my Aero, built a root image & booted.
It worked. It worked so well that the card manager discovered my Ethernet PCMCIA & did all the right module stuff, only to have "ifconfig" fail. I booted yet one more time & "ifconfig" worked, "mount -t nfs" worked, & all I had to do then was type "setup". A couple hours later (well, that's what it felt like) I completed an install, configured the network stuff, & started copying stuff over from my desktop.
Whew! & I have X to configure...!
Aero/Win95 performance is mediocre by today's standards. Aero/Linux/Apache performance is astoundingly quicker at suppling Web pages & executing cgi-bin's that make up my wife's master's project. We hope to extend this project into a useful product. Being able to demonstrate the project on 2 laptops is the reason behind all this.
As a little bonus I'll share my root image recipe. I customized pcmcia.gz, but any of the root images should work. Note, however, that I found images with a 1.44Mb length required "mke2fs -m0 /dev/ram 1440".
I have an IBM Home & Away Ethernet/modem PCMCIA card. It works reliably w/ Win95 but is unreliable w/ Linux. I can get it working by doing little changes to the Linux PCMCIA config files, but it would fail on the next power-up boot. So, I traded it to my wife for her IBM Credit Card Ethernet adaptor (the real manufacturer is National Semiconductor). Both cost $40 US.
The program that writes the H&A's flashROM displays a 12 digit number (in hexadecimal format) & recommends the user copy & save it in case it is needed again. This number is the Ethernet hardware address, known also as a MAC (Media Access Control) Address. Each Ethernet card (& most other types of network adaptors) has its own hardware address which must be unique on the network the computer is attached to. To insure uniqueness, all network cards are given unique addresses by its manufacturer. I don't know who is responsible for coordinating the assignment of address ranges to manufacturers.
Note that a unique hardware address is irrelevant to devices only used for point-to-point protocols, such as modems. OTOH, maybe modems are only used for point-to-point because they don't have unique hardware addresses. A "who came first, the chicken or the egg" kind of question.
At the hardware level, Ethernet adapters put packets on the physical medium (wire) with a header that includes the MAC Addresses of both the source & destination Ethernet adapters. The header format is specified in the IP (Internet Protocol) definition. An Ethernet adapter processes those packets in which the header includes its MAC Address in the destination field. (I am not addressing the handling broadcast packets nor Ethernet adapters used in promiscuous mode.)
So, how does a Ethernet adapter determine a destination's MAC Address? Starting at the user level:
o An IP Address is resolved to a MAC address by ARP (Address Resolution Protocol) software. ARP software maintains a cache of IP Address to MAC Address mappings; a request for an unknown IP to MAC mapping results in the broadcast of ARP packets in hopes that some other network node knows the mapping.
All this happens automagically in what's known collectively as the IP network stack software. It seems overly complex, yet it is a very flexible & robust design. It is not without its own shortcomings, but it does work. For a better (& longer) introduction to IP networking, point your favorite browser (hopefully Netscape) at http://www.sangoma.com/fguide.html.
What this means to us H&A owners: Ideally, your H&A should be reprogrammed with its original number if it is available. This insures it won't conflict with any other Ethernet adapters on a network to which it might be attached. FWIW, all IBM Ethernet MAC addresses start with 08005A leaving 6 hexadecimal digits to use for unique addresses. That's 16,777,216 addresses.
Pragmatically, I think it would be very unlikely that all 0's would conflict on any private network so it shouldn't be a problem. If a conflict does occur, you might try using your birthday or other significant set of numbers - maybe some digits from the fractional part if the contstant pi? - to reduce the probability of encountering another all-0's MAC Address.
The problem is irrelevant if you only use the H&A's modem.