CLI slackware on a 1999 laptop

Links: CNET specs   broadcom module

---

AmeriNote RL366C 366MHz Celeron  

In the late 1990's, CompUSA¹ apparently sold a line of laptops called "AmeriNote"s. It's unclear who manufactured these for CompUSA, but the laptops did garner at least some good reviews in their day. I recently had an opportunity to salvage one in unknown condition. Current market value would be less than 50 cents, but the project seemed interesting: a 366MHz Celeron with 256Mb of 144 pin 60MHz SODIMM, 3.2 GB HDD (not bad for '99), CD-ROM drive, single USB 1.0 port, and a 12.1" 800x600 screen. The screen appeared to be without a backlight, passively lit, if that's possible. Full specs are in the link at top.

operable?

The laptop powered into BIOS OK, but did not boot; apparently it suffered corrupted HD sectors. I located a 2008 Slackware 12.1 CD and it booted with "huge.s". Bad sectors seemed about 100MB leaving sufficient space for a CLI install. First, the verification of the checksum of the old install disk however:

$ cd /media/foo/S12.2d1
$ md5sum -c CHECKSUMS.md5
md5sum: WARNING: 12 lines are improperly formatted

The warning is inconsequential since it just means whomever created the checksum file made a syntax error. Any warnings that "computed checksums did NOT match" however would have to be evaluated.

time

The on-board battery had obviously not kept-up, and was stuck in 2005. Some applications (eg. WiFi modules) will not compile if the OS date is too far removed from the dates in the source code. I fixed this based mostly on the information from this site, adding quotation marks as follows...

# date --set="Sat Apr 24 18:49:00 EST 2013"

... and sent it to the hwclock using

# hwclock --systohc --utc

user - adduser

Creating a user with "useradd" appeared the most flexible, but seemed to always lead to account expiration errors even when a directory, expiry, and so forth seemed properly initialized. After several iterations of "useradd", "usermod", and "userdel" with different option flags, eventually sampled "adduser". "Adduser" worked the first time and so seemed worth the annoying GECOS hand-holding, etc. The command is simply...

# adduser foo

Subsequent verification of the user set with # passwd -Sa ("status", "all"), and $ groups confirmed a normal scenario, including a user directory.

applications

I had a USB stick with application source --- how to get them into a user directory using CLI? I found instructions here. I varied from these slightly by using udevmonitor to detect the drive name, and by creating the mount directory (as $) under my home directory, eg /home/foo/myusb...

$ mkdir /home/foo/myusb
# udevmonitor [returned "/dev/sda1" from usb stick]
# mount -t vfat -o rw,users /dev/sda1 /home/foo/myusb

I was able to easily move files as a user. Then, prior to removing the USB stick...

$ umount /dev/sda1

network - pcmcia

The AmeriNote of course only had a built-in 56K modem. This left the PCMCIA or USB ports as possible network adapter inputs (how did we get by back in '99?). PCMCIA seemed best for WiFi: leave the USB available. For whatever reason, I had a small pile of PCMCIA WiFi cards in an old shoebox. Each was detected, but using the numbers in lspci -vn, the subassembly chips seemed to require ndiswrapper, which I wanted not to use. And peering into /lib/modules/`uname -r`/kernel/net/wireless, it seemed that, after all these years, very few native modules have emerged². However, one of the cards was a Broadcom 4300 series. It seemed worth a try with a 32 bit driver. The source compiled without errors, but when I went to insert it, I had errors which ultimately required a kernel recompile enabling more WiFi networking features than the vanilla install. I have instructions for such recompiles in a March 2009 post. I also considered stripping down the running modules and running make localmodconfig, since that runs "lsmod" to determine the Makefile. In the end, I recompiled the Slackware 12.1 source, enabling wireless.

Before trying the Broadcom driver noted above, I checked to see if the newly compiled modules might natively drive the card. But using...

$ ls -l /dev/sys/net

...only revealed an eth0 and no wlan0. Hmmm...

¹Absorbed since 2012 into TigerDirect.com
²Self-defeating firmware opacity on the part of manufacturers?