Editor's note: Welcome to the first of a new series of columns, Linux on board. developerWorks columnist Peter Seebach will look at Linux running on various kinds of hardware -- PDAs, embedded devices, or just ancient hardware no one thought was useful anymore. The series will alternate between looking at specific Linux devices and showing you in detail how to set up Linux on decrepit hardware that's past its reputed prime.
When people talk about Linux on old hardware, they generally mean hardware a year or two old, stuff that is still pretty useful. The hardware in question is in good shape, reasonably well maintained, and possesses decent specs -- perhaps it's even an old server. For this series, however, we'll be setting our sights a little lower.
Enter, stage left, an old Gateway box (I mean no disrespect for Gateway). In October of 1997, I spent nearly $3,000 on what was at the time a top-of-the-line laptop. Boasting a Pentium® 133, 32 MB of high-speed SDRAM, and an 800x600 TFT LCD display, the machine had 1.15 MB of video memory -- just enough to allow 16-bit color at the 800x600 resolution of its on-screen display.
I remember being in awe at how fast this machine was, coming to it as I was from a 33 Mhz 68030 machine.
Well, that was eight years ago. A few years back, a glass of wine was spilled on it. Fans of 1980s B movies will be disappointed to learn that it did not attain sentience; all that happened was it needed to be repaired. Unfortunately, the CardBus slots have never been the same and are prone to errors. A run-in with an El-Al baggage handler some years back left it with a cracked and unusable screen. The only advantage it has is an additional 64 MB of memory, installed a year or so before the run-in with the wine.
By current standards, this machine is a toy. You can buy embedded systems from companies like Technologic with better basic specifications and additional features such as built-in Ethernet. It's not even fully functional anymore, to put it mildly.
So, the challenge here is to show that the machine can be made reasonably usable. In this series, I'm going to build it into a sort of useful household box.
Now, a challenge, even a self-imposed one, requires rules, and the rules are simple -- I can spend no more than $50 per project. Since it would take me 60 projects to catch up with the original cost of the machine, I'm going to allow for "free" hardware (hardware that's at least four years old and lying around unused). Otherwise, the spending has to be accounted for. Oh, and downloads are free.
The obvious concern is that the 2 GB disk the machine came with is probably a little small. Luckily, I have a 6 GB disk lying around that came originally in a 2000-vintage PowerBook G3 -- that's a bit over four years, so it's within the rules. Installing the drive wasn't hard at all, although I did manage to do it wrong the first time; the drive was jumpered as a slave (I have no idea why). With that fixed, I now have a machine with a 6 GB disk, last formatted on a Mac in 2001 or so and obviously not bootable.
I have an LCD monitor I bought in 2001. It's a little too recent to be kept (according to the rules), but I can "borrow" it during setup. The monitor will be useful during setup, but I don't plan to keep it in use once the system's up and running. The machine has a BIOS setting for whether to use the external display, the internal one, or both. It amuses me that the external setting is called "CRT" even though it isn't a CRT.
With the monitor and the new hard drive connected, the machine is ready to boot. Spinning it up reveals one problem -- the drive is really loud, so it might be failing. But hey, it was free. And it'll probably run for a few months.
All we need now is an operating system.
Remember, free downloads are considered free. I was originally planning just to use my SUSE Linux install discs on this project, but I ran into two problems. The first is that the system requirements list 128 MB of RAM. The second is that I only have the DVD, and buying a new boxed set would cost money.
I decide to be cheap and download. A bit of asking around turned up a recommendation for a small, light, distro called Slackware.
Slackware's Web presence offers advice for people with 16 MB or less of available memory. That sounded friendly to me. I downloaded BitTorrent (a tool that enables "cooperative distribution" and reduces bandwidth overload for the more popular downloads) and started downloading the distribution CDs for Slackware 10.0. Next morning, I burned some CDs. (Four of them, in fact. I got these a while back when CD blanks cost money, so I'm calling them $.50 each.) Then I noticed that Slackware 10.1 had just been released. Oops.
I downloaded the 10.1 CDs. A quick reminder: Don't just kill BitTorrent when you're done downloading. The point of a cooperative network is to offer something back to the community. Mere courtesy dictates that you should leave it running until the amount of data you've uploaded is at least equal to the amount you've downloaded.
Once disc 1 of the new Slackware was available, I burned a copy and started the install. This time, I only burned the two install CDs, not the source CDs. Another day, another dollar.
The installer booted and found a disk drive on /dev/hdb. This is when I discovered my drive was enslaved. After a few minutes with a screwdriver and a tiny pair of pliers, I was on my way.
The Slackware installer is extremely lightweight. It's not a graphical installer; it doesn't use a frame buffer driver or X or anything. It tells you to partition your disk before running the installer, then offers a login prompt.
There was not much guidance given about selecting partition sizes; this was a bit of a nuisance. As an old BSD user, I favor the split between the root file system and /usr. I also made separate partitions for /var and /home, as well as carving out a bit of swap space. The numbers I guessed at turned out to be reasonable; about 128 MB for root (plenty of extra space for test kernels), 256 MB for swap, most of a gigabyte for /var, two gigs for /usr, and the leftover space for /home.
Slackware offers a fairly simple division of files into top-level categories. I omitted all of the X-based things, including GNOME and KDE, and installed everything else. This machine is not suited to a life as a graphics workstation, so that frees up a lot of space. (Conveniently, it also makes the second install disk largely irrelevant. I coulda saved $.50!)
Using the installer was not entirely trouble free. Once I had formatted my disks and run the install, I was informed that LILO had failed to run and I would need to fix it before rebooting. Conveniently, the install offered me a shell prompt when I was done with the target disk mounted on /mnt. A little poking around in /etc/lilo.conf spotted the culprit:
Listing 1. A ha! The culprit
boot = (IN [...] root = (IN |
I don't know what this represented. I changed it to values that seemed like they might work:
Listing 2. Good old-fashioned values
boot = /dev/hda [...] root = /dev/hda1 |
Rerunning LILO produced no errors, so I rebooted. Sure enough, the machine came up just fine.
That was it for problems with the install. (Actually, not quite. I had to redo the process of assigning mount points because I made a typo the first time, but I can hardly blame Slackware for that.)
Now that the system is installed, I can check how my guesses about partition sizes worked out.
Listing 3. Not bad for a guess
$ df -m Filesystem 1M-blocks Used Available Use% Mounted on /dev/hda1 130 55 69 45% / /dev/hda5 950 31 871 4% /var /dev/hda6 1900 1434 369 80% /usr /dev/hda7 2326 37 2170 2% /home |
That's not too bad. If I want to install a lot of additional software, I might run out of space in /usr. I certainly don't have enough space for a full collection of source. On the bright side, there's plenty of space for the Web page root (/var/www/htdocs), and if I really need to load something else, I can probably move some files into /home and set up a symbolic link.
A bit of poking about in /usr reveals a few specifics. Your friend here is du -m. Unfortunately, this version of du doesn't recognize values in $BLOCKSIZE other than the word HUMAN (which indicates to use human-readable numbers); otherwise, you could just set it to 1 M and have df and du stick to 1 MB blocks. Running sort -n on the output from du gives a list of the top directories in /usr by size:
Listing 4. Ah, directories by size
86 ./lib/jre1.5.0_01 92 ./src/linux-2.4.29/drivers 112 ./bin 146 ./doc 173 ./share/texmf 205 ./src 205 ./src/linux-2.4.29 384 ./lib 428 ./share 1402 . |
In short, some of the largest things installed are the TeX software and support files, the kernel source, and the Java™ runtime. Java may well be pointless on a machine with this little memory, so it's a good candidate for removal if I ever run out of space. There's probably a lot of wasted space in the kernel source, and TeX may well be something I could afford to remove. So, if I need a few hundred megabytes of space, I can get them. Nice to know, but in the meantime I have plenty of room, and all the things I'm likely to want are already installed.
The first order of business is getting an Ethernet port. Unfortunately, my aging USB hub with an Ethernet port produced cryptic errors when connected, so I decided to use the inexpensive Targus USB "dock" I picked up a week or two back for testing. This gives me PS/2 keyboard and mouse ports (useless in my case), another serial port, another parallel port, two more USB ports... and a 10 Mbps Ethernet port.
You might think 10/100 would be better (and that's probably why this gizmo was marked down to $29.99 instead of selling for the $70 that it did a year or two back), but on a USB 1.1 machine, there's not much point in 100 Mbps support.
My hub auto-senses the port and I'm covered. The 2 Mbps of USB bandwidth I'm not tying up will be available for running gizmos later.
The device probed automatically. Oddly, dhclient wouldn't work on this interface. It said it couldn't find a broadcast interface. Configuring the interface manually and writing resolv.conf by hand worked fine. One tiny little surprise for me: The syntax I'm used to, route add default gateway, produced the moderately cryptic error message SIOCADDRT: No such device. A quick check of the man page corrected my spelling -- route add default gw gateway.
With that done, the machine is now working fine on the network. It is reachable on the local network and able to use my broadband connection to reach the outside world. I can also ssh in now.
That doesn't do much good without an account to log into. My login name is always seebs, so I tried the first thing that came to mind; useradd seebs. That worked, but it left me with no home directory. Easy enough to add one. Now it's time to put the machine through its paces a bit, copy over a few programs I like to have around, my usual .profile, things like that. The system shipped with gcc version 3.3.4, which is recent and supports a fair number of C99 idioms.
Of course, configuring everything by hand from the console after a boot is problematic. You don't want to have to do that every time. The relevant configuration knobs (IP address, for instance) are in /etc, specifically /etc/HOSTNAME for the host name and /etc/rc.d/rc.inet1.conf for the network address.
Rather than relying on DHCP, I decided to assign a fixed address in here. After all, this machine will eventually be a local server, and it would be obnoxious for its address to change all the time. You can also do this by running netconfig, but part of the fun of running Slackware is that there aren't a lot of files labeled "warning: machine-generated file, do not edit."
Well so far, the machine is not doing a lot, but it's an installed system with remote access via ssh and a reasonably complete Linux install. Expenses are $3 for CD blanks and $31.94 for the USB network widget. (Later, I will probably be glad of the extra power budget and ports and the second serial port.) That's comfortably under budget.
Coming up next time for This Old Box: setting up a household calendar program so we can get some use out of the machine. With all these people using multi-megabyte class libraries to schedule meetings, I'd be happy with a multi-kilobyte Perl script that can tell me when it's my turn to do the dishes.
-
"Boot Linux from a FireWire device" (developerWorks, July 2004) demonstrates that obtaining an external drive is a great way to breathe new life into older hardware, or to use Linux on machines on which you can't alter the internal hard drive.
-
"Slackware Linux 101" (developerWorks, March 2001) gives you a glimpse inside the Slackware Linux init sequence.
-
The official BitTorrent site explains all about cooperative distribution.
-
Welcome to the Slackware Linux Project, an advanced Linux operating system designed with ease of use and stability as top priorities.
-
Go here for SUSE Linux.
- Find more resources for Linux developers in the developerWorks Linux zone.
- Get involved in the developerWorks community by participating in developerWorks blogs.
- Innovate your next Linux development project with IBM trial software, available for download directly from developerWorks.
Peter's the electronic equivalent of Frankenstein (the Doctor, not his Monster). To comment on his experiments, please contact him at dwlinux@plethora.net.
Comments (Undergoing maintenance)
Table of contents
Local resources
My developerWorks community
Tags
Use the slider bar to see more or fewer tags.
Popular tags shows the top tags for this particular content zone (for example, Java technology, Linux, WebSphere).
My tags shows your tags for this particular content zone (for example, Java technology, Linux, WebSphere).
Popular article tags |
My article tagsSkip to tags list
Popular article tags |
My article tags
