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?

linux - timezone/time changes

Links:
Brief clock-setting example       Ntpd daemon documentation (in depth)
Clock processes on Red Hat     Clock processes in Archlinux

The Red Hat link describes time features functionally with some commands. The Archlinux link includes specific configuration file information.
Note: "RTC" and "UTC" are similar acronyms, and of course we want to keep them straight. My device is to remember, "U is close to Z", since UTC is Zulu time (Zulu=GMT=UTC). "RTC" is the BIOS clock.

---

Overview of clock/timezones in Slack/Zenwalk

The hardware clock, more technically the RTC (Real Time Clock) in the BIOS, is the battery powered CMOS clock that sits on the motherboard. During startup, we can enter BIOS and set the BIOS clock directly, or we can set it through some commands (see below). The software system clock reads the hardware clock at boot time. To assist with system clock accuracy, some users also employ an ntpd daemon. After the system boots, ntpd periodically checks calibrated servers via the Web and make corrections to the system clock. At shutdown, the system clock's time is written to the hardware clock, to assist with the hardware clock's accuracy going into a powered-off state and battery power.

RTC -> System Clock (once,at boot) ->System Clock (corrected by NTPD) -> Timezone offset -> Desktop display

Linux views the hardware time in two potential ways: as carrying "local time" or to "UTC" (aka "GST", "GMT", "Zulu") time. This decision is made by the user during installation, but the file can be directly accessed and toggled any time by the (root) user. In Zenwalk, the file is /etc/hardwareclock. The file contains only one word, either "localtime" or "UTC" (minus quotes). In other Linux systems, local or UTC is noted in /etc/sysconfig/clock. Zenwalk/Linux systems use either the local or UTC when calculating the current time to display to the user.

It's up to the individual, but I set BIOS to UTC and select "UTC" in /etc/hardwareclock. With UTC: 1) my system remains consistent across both the hardware and system clocks and, 2) UTC is the time served by Internet ntp time servers. Also, when traveling, I don't needn't alter clock settings beyond changing /usr/share/zoneinfo or, eg Orage (if I want to use a GUI).

What appears when I type "date"
Neither the system clock nor hardware clock. "Date" is the system clock (taken from BIOS at boot), modified according to /etc/hardwareclock and /usr/share/zoneinfo settings. As noted above, because I keep system and hardware clocks set to Zulu, the simplest way to keep things accurate at all 3 levels (bios, system, user-display), is to run a time server update on systemclock and then send it to the BIOS:

# ntpdate pool.ntp.org
# hwclock --systohc

More recently, since Arch demoted ntpd to the AUR, the mainstream application is now the memory hog ntp, activated by

$ systemctl restart ntpd
$ systemctl restart systemd-timesyncd
$ systemctl restart ntpd
$ timedatectl status
[correct information should be displayed]

These commands will be explained more below, but the above command makes life easy after, say, one replaces a CMOS battery on the motherboard. Browsers won't be able to SSL lock unless the time is relatively close to the current date. For example, Chromium won't navigate to the Google home page unless the system time is within the current CA certificate, (eg, June 1, 2001 won't allow access in 2009), because Google always connects "https" and 'can't' do so via an expired certificate.

Hardware clock (RTC)
It's possible to directly set the time on one's hardware clock to whatever one wishes using hwclock commands.

To view the hardware clock:
# hwclock

To change the hardware clock to whatever the system clock currently indicates:
# hwclock --systohc

To change the system clock to whatever the hardware clock currently indicates (this is what happens at boot):
# hwclock --hctosys

System clock
The system clock periodically receives an accurate UTC/GST/GMT from ntpd . Settings are configured in /etc/ntp.conf and one can check operation with # service list. One can also force an ntp update to the system clock. Turn off ntpd, (# service stop ntpd), to free the ntp port. Google an ntp time server and run ntpdate or just go to the ntp pool, which will determine and use the nearest server:
# ntpdate pool.ntp.org

To view the system clock, for example to verify an update:
$ date

Timezone offset
Suppose I fly from Chicago to NYC or vice versa; how do I set the timezone? From the desktop, I open Orage and change the timezone there. If I want to do it without a GUI, most of the answer is in /usr/share/zoneinfo.

The file /etc/localtime is supposed to be a soft ("sym")link pointing to the correct timezone in /usr/share/zoneinfo. In my system, there was a hard file in /etc/localtime instead of a symlink. Accordingly, to be sure, I removed both files and and created a new symlink to the correct timezone. For instance, since NYC is EST, this would be the process when flying to NYC:

# rm -r /etc/localtime
# rm -r /usr/share/zoneinfo/localtime
# ln -s /usr/share/zoneinfo/US/Eastern /etc/localtime

With these three commands, and setting /etc/hardwareclock to UTC, all should be good at the next reboot.

Sometimes a system is sticky even with this. If that's the case, do all of the above and also export the time variable $TZ, to the kernel. For example in PST regions:

$ export TZ=PST8PDT

Ancillary notes

• the directory /usr/share/zoneinfo contains the premade time zone options. It appears all potential time zones are in here.
• the timezone file /etc/localtime appears filled with weird symbols like it's a bin file. It can't therefore be edited with a text editor.
• the /usr/share/zoneinfo directory contains two soft links: localtime -> /etc/localtime, and timeconfig -> /usr/sbin/timeconfig. The symlink for /etc/localtime is explained above, but I'm uncertain why the timeconfig application would be linked here since it can easily be ran in any terminal.