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.

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".

mke2fs -m0 /dev/ram 2000

gunzip < [desktop path/]pcmcia.gz > /dev/ram

dumpe2fs /dev/ram

mount -t ext2 /dev/ram /mnt

cd /mnt/etc/pcmcia

copy [desktop path/]config.opts .

cd /mnt/etc/rc.d

dir

copy [desktop path/]rc.pcmcia .

cd ~/

umount /mnt

dumpe2fs /dev/ram

gzip < /dev/ram > pcmcia.gz

Copy to DOS partition along with boot image & loadlin.exe, & boot.

Some references:

"initrd.txt", a paper by Wernet Almesberger & Hans Lermen, found on
the Slackware cdrom at docs/linux-2.0.30/initrd.txt. (I think I found
it on the RedHat cdrom, too.)

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 IP network addressing is based on the "workstation@networkdomain.
org" naming convention. Name server software (DNS - Domain Name
Server) resolves these alphabetic names to an IP Address of the
form xxx.xxx.xxx.xxx (where 0 <= xxx <= 255).

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.