Tales of Rescuing Old Hardwareby 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.
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.
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.
I discovered that the NetBSD installation program is
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 ftp.netbsd.org. Then,
before any compilation, I had to prepare the tools:
server# mkdir /usr/obj server# cd /usr/src server# ./build.sh 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
ppp) somehow made it into the array and
sysinst ignored them, which caused the appearance of Figure 1
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
won't fail. As for me, I fortunately happened to notice
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
also prepared a sysinst162.patch for the
In order to apply it to the
sysinst on the server, I ran these
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
sysinst. First, I compiled the new default
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.
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 192.168.10.10 and the notebook the IP address of
192.168.10.100. At the end of the network configuration,
suggested that I give the proper flags to
slattach to start SLIP.
I kept the default values, as Figure 2 shows.
Now I had to configure the server:
- Mount the NetBSD installation distribution to an NFS directory, for example, /cdrom.
- Configure the server's
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 192.168.10.10 192.168.10.100 server# slattach -s 115200 -l /dev/tty00
Now I only had to test how the interface worked:
server# ping 192.168.10.100 PING 192.168.10.100 (192.168.10.100): 56 data bytes 64 bytes from 192.168.10.100: icmp_seq=0 ttl=255 time=20.564 ms 64 bytes from 192.168.10.100: icmp_seq=1 ttl=255 time=19.730 ms 64 bytes from 192.168.10.100: icmp_seq=2 ttl=255 time=20.750 ms 64 bytes from 192.168.10.100: icmp_seq=3 ttl=255 time=20.737 ms ^C ----192.168.10.100 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 192.168.10.10 (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
Enter. Nothing terrible happened: my laptop slowly but correctly
began to unpack distribution sets, as Figure 3 shows.
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.