BSD DevCenter
oreilly.comSafari Books Online.Conferences.


Tales of Rescuing Old Hardware

by Mikhail Zakharov

Everything began one fine day when I visited our storage room to see if there was anything interesting for me to look at. Soon I came across an old shabby dark-gray Toshiba notebook thrown there amidst different computer rubbish long ago, from the time when Intel's Pentium I was the top of performance. I couldn't pass by such unexpected richness and extracted the laptop from the trash.

The Machine

Some time later, with doubt but also with a great deal of curiosity, I looked at the newly washed Toshiba T2130CS with a 3.5" floppy drive, a PS/2 keyboard port, one parallel port, one 9-pin RS-232 serial port, and a VGA output for an external monitor. The system also has a green trackball placed on the keyboard. The PCMCI controller, once designed for two cards, now shows numerous marks of forcible death and obviously doesn't work. Clearly, that was the reason for putting our hero out of the way. The battery won't hold a charge, but I can always use the 220-voltage AC input.

When I turned on the power, POST successfully passed and the system detected 16MB of RAM. Then MS-DOS rather quickly started.

After a while, I learned to how to enter the BIOS: turning the power on, I figured out to press the Esc button until the string "Check system. Then press [F1] key" appeared. A pitiful beep followed, which little startled me at first. I didn't find any simpler way to get into BIOS, but then it helped me to discover that BIOS had version 5.00 and the notebook contained a processor of undetermined frequency. (The menu showed nothing but "CPU Cache = Enabled and Processing Speed = High"). Then I saw something that I couldn't quite understand: according to the configuration, the built-in display could work in 4096 or 222K color modes (if "K" meant "kilo-" then it was quite good).

To make heads or tails of the processor, video adapter, and everything else, I needed to do some research. I went to Toshiba's web site. Having gone through various references I guessed at last that in all probability my T2130CS was a representative of the Satellite model line. From there, I downloaded some useful files:

As I had expected, the user's guide worked only under Windows and required two blank floppies. Besides, it placed (without my approval) something funny in the C:\WINDOWS\SYSTEM directory. Reading the guide, I learned the following:

  • The processor in the T2130CS is an Intel 486DX4 75MHz.
  • The hard drive capacity is 500MB.
  • The color 10.4" display works with the resolution of 640 by 480 pixels and in 256 colors. (Though there was obviously some confusion with the quantity of colors in the guide: I came across 4096 and 256, as well as 222K, and even 256K).
  • PCMCIA allows the use of only one Type III card or one or two cards of Type I or Type II.
  • The dimensions of the laptop are 199 by 226 by 53mm and it weighs 3.17kg.
  • The notebook works with a port replicator, but I couldn't find it in storage.

I also discovered a lot of other useful and useless information in the guide. Having read it, I decided to update the BIOS. Of course, I needed a blank floppy for the operation (I was glad not to need two of them). The configuration program required me to place the floppy in the floppy drive and then to hard-boot the laptop. Then I had to follow some simple directions. I fulfilled everything. If the operation failed, I would have nothing to write about, but everything went successfully and installed the updated BIOS version 5.20. I didn't notice any other visible changes except the appearance of the number 5.20 instead of 5.00. For all that, I hoped there were in fact some important invisible changes.

Very pleased with myself, I decided nevertheless to clear my conscience and run the diagnostic tool tdiags, which impressed me with the utter poverty of its abilities. In other words, tdiags only tested what worked. Naturally the test succeeded, and it couldn't be otherwise.

The First Approach

It's all very well with MS-DOS, but indeed no real hacker will use it nowadays. By the way, reading the guide, I sometimes ran across Windows 3.x/95, but as you have already understood, it wasn't my way. I decided to install *NIX, of course, and it would be ... no, not Linux, but something that could really work on my very old and poor hardware. Actually, the computer worked very slowly, its hard drive capacity was low, and there was no possibility to connect a CD-ROM drive. Thus, I'd have to install my OS either with the help of the floppy set or through one of the LPT or COM ports. In any case, I needed a compact and fast OS: NetBSD, for example. I really didn't want to leave out the motto: "Of course it runs NetBSD." I made up my mind to set up NetBSD. What would it matter if NetBSD wasn't my best subject?

I ruled out the floppy installation at once, because it isn't decent to do so in the 21st century. I faced the choice between COM and LPT. The parallel port could provide wider bandwidth but it required a special cable. The nearby shop didn't have such a cable, and I had no desire to solder one myself. Besides, I had a null-modem cable prepared in my arsenal long ago. Thus, I decided to use the COM port.

Armed with maniacal enthusiasm and new NetBSD-2.0 release disk (having downloaded the image from NetBSD's FTP server), I successfully installed it on my home PC. I decided to call it server, because with its help and through the null-modem cable I intended to establish a connection between the laptop and the outer world. By the way, why do modern motherboards so often have only one serial port?

Installing server was my small victory. Inspired with it, I happily turned to my notebook, briskly inserted the null-modem cable, and switched on the power. Then a pause happened. As it was impossible to use the CD-ROM with my laptop at all, I had to return to my server and get ready to prepare installation floppies. Fortunately, the NetBSD distribution includes floppy images in the /i386/installation/floppy/ directory. As it turns out, the ordinary boot1.fs and boot2.fs images worked for me. Equipped with two floppies left from the ill-fated Toshiba guide, I stuck one into the server's floppy drive and entered the following commands:

server# echo "/dev/cd0a /cdrom cd9660 ro,noauto 0 0" >> /etc/fstab
server# mount /cdrom
server# cd /cdrom/i386/installation/floppy
server# dd if=boot1.fs of=/dev/rfd0a bs=64k

I performed the same operation for boot2.fs and the second floppy. With the standard NetBSD installation floppies ready, I could boot my notebook from them. I did so.

Then the standard procedure of installing NetBSD followed. I divided my hard disk into partitions, created filesystems, and chose distribution sets. Of course, I selected the minimum install: kernel, base, system. I prepared myself to install the distribution using NFS because I was afraid that there wouldn't be enough space on the hard drive if I first fetched the data by FTP and then unpacked it into the proper directories.

Then I met with cruel disappointment. You can see everything in Figure 1.

Figure 1
Figure 1.

On account of the motto "Of course it runs NetBSD," I couldn't expect such an amazing thing to happen. There were no network interfaces found, of course, but why wasn't the COM port suitable? I was at a loss to understand. I felt a bit offended, all the more so because it's easy enough to set up PPP, let alone SLIP, with NetBSD (see the NetBSD Guide).

Well, I didn't want to stop halfway and so I hit Google. I plunged into the depths of various mailing-list archives, forums, and how-tos. From time to time, I met enthusiasts who obviously came across the same problem of installing NetBSD through the COM port too, but I never saw one who offered any solution. Maybe I looked in the wrong place. After spending two days on this and finding nothing, I made up my mind to solve the matter myself. Surprised at such self-confidence, I reached into the source code.

The Patch

I discovered that the NetBSD installation program is sysinst and its source lives in the directory /usr/src/distrib/utils/sysinst. Of course, first of all it was necessary to install the source packages, which I downloaded from Then, before any compilation, I had to prepare the tools:

server# mkdir /usr/obj
server# cd /usr/src
server# ./ tools

I won't going deep into the details of how I dug into the insides of sysinit and how I found at the end an array eloquently called ignored_if_names[], where there were lists the names of network interfaces not to initialize during NetBSD installation. The SLIP and PPP interfaces (sl and ppp) somehow made it into the array and sysinst ignored them, which caused the appearance of Figure 1 above.

After researching the source code of the installation floppies (/usr/src/distrib/i386/floppies/), it became clear that the daemon pppd wasn't there at all. None of my attempts to generate the floppies to include pppd succeeded; every newly created image exceeded the size of the floppy. Maybe your attempts with pppd won't fail. As for me, I fortunately happened to notice /sbin/slattach in the list of the programs to install to the floppies. There was a solution, because SLIP wasn't any worse than PPP for my purposes. I set down to edit the sysinst source texts. After awhile I created a sysinst20.patch that enables support of sl-interface in the English version of sysinst. I also prepared a sysinst162.patch for the NetBSD-1.6.2.

In order to apply it to the sysinst on the server, I ran these commands:

server# cd /usr/src/distrib/utils/sysinst
server# patch < /full/path/to/sysinst20.patch

Now it was possible to rebuild the installation floppies themselves with my patched sysinst. First, I compiled the new default INSTALL-kernel:

server# cd /usr/src/sys/arch/i386/conf
server# config INSTALL
server# cd /usr/src/sys/arch/i386/compile/INSTALL
server# make depend && make

Before creating the floppies, I had to create the MAKEDEV script:

server# cd /usr/src/etc
server# make MAKEDEV

At last, I returned to /usr/src/distrib/i386/floppies/ to build the floppies:

server# cd /usr/src/distrib/i386/floppies/ramdisk-big
server# make
server# cd ../instkernel
server# make 
server# cd ../bootfloppy
server# make

In Netbsd-1.6.2, do instead:

server# cd /usr/src/distrib/i386/floppies/ramdisk-big
server# make
server# cd ../kernel-ramdisk
server# make netbsd.INSTALL.gz
server# cd ../bootfloppy
server# make

After that, in the directory /usr/src/distrib/i386/floppies/bootfloppy/ (/usr/src/distrib/i386/floppies/bootfloppy/obj/ for NetBSD-1.6.2) appeared images of two installation floppies, boot1.fs and boot2.fs. I installed them to the same two floppies remaining from the Toshiba user's guide:

server# cd /usr/src/distrib/i386/floppies/bootfloppy
server# dd if=boot1.fs of=/dev/rfd0a bs=64k
# (remove the first diskette an insert the second)
server# dd if=boot2.fs of=/dev/rfd0a bs=64k

With my floppies ready, I could turn on the notebook again.

Second Attempt

After booting the notebook with the new floppies and performing of all the common installation stages of partitioning, choosing distribution sets, and so on, I indicated the distribution source as NFS and approached the ill-fated spot again. The network interface appeared now as sl0. Due to the patch, I could configure it on the next screens. For example, I gave the server the IP address of and the notebook the IP address of At the end of the network configuration, sysinst suggested that I give the proper flags to slattach to start SLIP. I kept the default values, as Figure 2 shows.

Figure 2
Figure 2.

Now I had to configure the server:

  • Mount the NetBSD installation distribution to an NFS directory, for example, /cdrom.
  • Start nfs-server.
  • Configure the server's sl-interface.

I inserted the NetBSD distribution into the CD-ROM drive of the server and mounted /cdrom:

server# mount /cdrom

Then I configured NFS and started the proper daemons:

server# echo "/cdrom -ro -alldirs" >> /etc/exports
server# nfsd
server# mountd
server# rpcbind -l

Finally, I configured the SLIP interface:

server# ifconfig sl0 inet
server# slattach -s 115200 -l /dev/tty00

Now I only had to test how the interface worked:

server# ping
PING ( 56 data bytes
64 bytes from icmp_seq=0 ttl=255 time=20.564 ms
64 bytes from icmp_seq=1 ttl=255 time=19.730 ms
64 bytes from icmp_seq=2 ttl=255 time=20.750 ms
64 bytes from icmp_seq=3 ttl=255 time=20.737 ms
---- PING Statistics----
4 packets transmitted, 4 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 19.730/20.445/20.750/0.484 ms

I was glad to see my T2130CS's responses and returned to the notebook to continue the installation. I only had to specify the NFS host and directory from which to start the installation. I entered (my server) and the distribution directory /cdrom/i386/binary/sets/.

Now I was only one step away from the last proof. With bated breath, I pressed Enter. Nothing terrible happened: my laptop slowly but correctly began to unpack distribution sets, as Figure 3 shows.

Figure 3
Figure 3.


Naturally the installation process wasn't quick, but after everything finished, the fresh NetBSD-2.0 works quite decently on my old venerable Toshiba Satellite T2130CS. As I found out later, the X Window System works on the laptop without any problems, too; it works perfectly in 640 by 480 in 256-color mode. That is absolutely another story though.

Mikhail Zakharov is presently the senior UNIX Administrator in a Moscow banks where he administers a wide spectrum of servers running various UNIX-like operating systems.

Return to the BSD DevCenter.

Sponsored by: