Setting Up a SPARCstation

by John Little

Many PC users have taken the plunge into the Unix world with Linux and, I imagine, quite a few Unix die-hards like me have taken their first, faltering steps with PC hardware, using Linux, too. I have to say that for a long-time Sun user, the attempted transition to PCs was not without its trials. The mysterious workings of BIOS and extended-vs-expanded memory still elude me, so it was with more than a little relief that I noted, towards the end of last year, the release of Red Hat 4.0 for the SPARC architecture. Now we Sunnites can run our favourite OS on our favourite hardware, and the PC folks have a chance to run a familiar OS on what many may have, until recently, considered rather exotic hardware. Many institutions are selling off, or even scrapping, their first generation SPARCs as they become less and less useful when running the relatively “heavy” OS which Sun now ships. Many of these workhorses are becoming available to the individual user at little or no cost, and Linux provides an ideal solution to the question of which OS to use.

SPARCstations generally offer better performance than a PC of equivalent age and come with a relatively standard set of peripherals and interfaces. Among the benefits are a much higher screen resolution than the old VGA-based 386 machines (the standard resolution for Suns is 1152x900) and built-in audio, Ethernet and SCSI controllers.

In this article I hope to introduce those readers unfamiliar with Sun hardware to a few of the peculiarities of the breed, provide pointers to which systems are good buys and which should be avoided, and to provide enough information for you to get Red Hat's SPARC distribution up and running on your machine.

Shopping For SPARCs

What systems are out there and what should you look for when shopping for a Sun workstation on which to run Linux?

First of all, several groups of machines are not currently supported under Red Hat Linux/SPARC and will not work under the 4.0 or 4.1 releases.

  • None of the VME-based deskside or server machines are supported (i.e., the 400 and 600 series).

  • The SS1000 and SS2000 servers are not supported.

  • The newer “Ultra” based machines are not supported.

I should emphasize here that SPARC Linux is one of the platforms where changes are happening very rapidly (kudos to the dedicated band of portmeisters), and I expect that by the time that you actually read this an Ultra version will be available. However, the Red Hat version 4.0 and 4.1 releases discussed here do not support that architecture.

More recent desktop machines, the Classic and SPARCstations 10 and 20 (all “4m” architecture), run SPARC Linux quite happily, and the testing and boot details given later in this article are generally valid for them. However, it's unlikely that the average home user will come across one of these machines on the market at a price which he'd be willing to pay for an unfamiliar piece of hardware, so I'd like to concentrate here on the machines which you're most likely to encounter, the older, “4c” architecture systems.

First, you need to be aware that several of Sun's chassis will accommodate several different types of CPU. A good example of this is the original “pizza box” SPARCstation enclosure (about the same size as a large size pizza delivery box, with a distinctive “dimple” pattern on the front and cooling holes in the same pattern on the sides). This chassis was virtually unchanged between several different models, the SPARCstation 1, 1+ and 2 (the SPARCstation 2 had a small fan and a floor grille added for disk cooling).

A Sheep In Wolf's Clothing

Unfortunately for potential buyers, this chassis also accommodates the Sun 3/80 CPU. The 3/80 is 68030 based (not SPARC) and, at the moment, no Linux port is available for it. Unless you're intent on joining the band of volunteers working on the Sun3 porting project, you do not want to buy a 3/80 in SPARCstation clothing. Don't accept that the logo on the front of the machine actually reflects what is inside. Take a good close look at the business end of the CPU. Even if you can't open the case to check the CPU chip, a dead give-away that the machine is actually a 3/80 is the presence of a 9-pin D-type serial port on the CPU. None of the desktop SPARCstations has this type of connector, although most, including the 3/80, have a 15-pin D-type Ethernet connector, so count those pins.

Figure 1. Red Hat Release & SPARCstation 1+

Any of the other machines mentioned above, the SPARCstation 1, 1+ or 2, will run Linux quite happily. They generally come configured with a floppy drive and one or two internal hard disk drives. They don't have an on-board frame-buffer though and one of the three available SBus card slots must be sacrificed to add one. Note: on the 1 and 1+ machines, the third SBus slot is marked as a “slave” slot and is only suitable for frame-buffer boards. It will not support I/O cards such as SCSI or Ethernet.

Table 1

Two other models appearing on the second-user market more frequently nowadays are the SPARCstation SLC and ELC systems. Both of these machines are easily mistaken as being nothing more than ordinary monochrome monitors, as the CPU is built into the housing of a 17 inch grey scale monitor. The clues are the SCSI, RS232 and keyboard connectors on the back panel of the machine. Keep an eye open for these two, and you could pick up a bargain.

Although both models first saw the light of day after the original SPARCstation 1, they were explicitly targeted at the bottom end of the market and mostly ended up as diskless workstations. The ELC is the more powerful of the pair, though not by much, and it can be recognized by the CPU access panel at the top rear of the monitor housing. However, as with the previously mentioned machines, CPUs and chassis are interchangeable, so the only way to tell for sure which machine you have is to power it on.

Another two systems with a common chassis are the IPC and the IPX. The enclosure for these two is smaller in width and depth and a little taller than the “pizza box” machines, and it is designed to have the same desktop “footprint” as the (separate) monitor. This enclosure can be installed under the monitor or stood on edge using an “L” shaped, blue-grey plastic stand supplied by Sun along with the system.

The compact design of the enclosure emphasizes the fact that these systems were targeted at the desktop user. The chassis is limited to a single 3.5 inch hard drive bay (plus a floppy), and non-standard mini-DIN style sockets are used for the RS232 connectors on the CPU back-panel.

Both machines have a built-in frame-buffer. The on-board frame-buffer supplied with the IPC is only monochrome, although it is possible to add colour by utilizing one of the two available SBus slots. The IPX sports a colour frame-buffer and uses a different type of SIMM, making it possible for the IPX to have a greater overall memory capacity while actually having only one third of the number of SIMM sockets of the IPC. Of the two, the IPX is also the more powerful.

Which To Choose?

Of all of the “4c” architecture machines mentioned above, probably the best choice of all is the SPARCstation 2. It offers the versatility of three SBus slots and a two-disk chassis, and has a much more powerful CPU than it's two look-alikes, the 1 and 1+. One of the SBus slots is needed for a frame-buffer during the install stage—Red Hat Linux/SPARC 4.0 needs a bit-addressable console device for install. It can be removed later and one of the RS232 ports used for the console connection instead, freeing up the slot for another SCSI controller, for instance. The extra fan between the floppy and hard disk mountings means that this model runs the drives a little cooler. Although the IPX might be a more suitable choice if you're looking for a colour desktop machine, the SPARCstation2 is probably the ideal candidate for use as a low-cost, high-capacity server.

The SPARCstation 1 and 1+ really are the elderly spinsters of this older generation of machines. While both have mounting points for two 3.5 inch SCSI disks, most of the drives available on the market today require much greater cooling than this chassis can provide. It's probably best to avoid these two systems unless you plan to use only the Sun-installed internal drive and make all additions and expansions on the external SCSI bus. Do NOT install high speed, high capacity, hot running drives such as the Seagate Barracuda into either of these machines. The airflow around the drive bays is inadequate and you'll seriously reduce the reliability and lifetime of the drive.

While the SLC and ELC appear, on face value, to be the least attractive, they still have their good points. There's no cooling fan (or disk) in either, so operation is quiet. Many people still like monochrome systems for their crisp, steady displays, especially when using the machine for extended hours for simple tasks such as text processing. Both of these systems need an external hard drive to run Red Hat Linux/SPARC. As already noted, the ELC is the best choice of the two.

The IPC and IPX are more compact than the other models in the Sun4c range and both have the advantage of a built-in frame-buffer. However, with only one internal disk and two SBus slots, they are probably best suited as desktop machines, rather than for server applications. A few people on the SPARC Linux mailing list have mentioned install difficulties with the IPC, but whether this is simply because it is such a common system or due to a specific system problem is an issue which remains unresolved at the time of writing. The IPX is the best choice between these two anyway, as it is the more powerful, has larger memory capacity and a colour frame-buffer as standard.

Getting there... Red Hat's SPARC Linux Release

There are two basic options available for obtaining the Red Hat Linux/SPARC distribution. For those of us without a direct connection to the Internet, buying the Red Hat CD-ROM set is probably the best choice, as the package includes a soft-cover manual and technical support via e-mail or fax. This being Linux, there are already some other CD-ROM collections available which include the Red Hat distribution (but without the hard copy manual or technical support options). On the other hand, if you have a fast Internet connection, you might want to download the distribution directly from the Red Hat ftp server or one of it's many mirrors. Because the Red Hat installation program has an ftp option, you can even limit your initial download to the install image and use that option to download only the package groups you specify during the interactive install process. The ftp option also has an additional benefit. The folks at Red Hat usually make their latest release available in the “devel” tree, so it's possible to download the “latest and greatest” version using this method.

No matter how you obtain the distribution, you must visit Red Hat's web site and pick up the very latest version of the errata file before you begin to install. This will save you some wasted time and frayed nerves.

Despite the general excellence of SPARC Linux, several problems with Red Hat's initial 4.0 release, which can spoil your whole day if you don't know about them, came to light only after the CD-ROM set was created. There are two files which you should look at, the Linux/SPARC errata and the general errata for whichever version you're loading. The latter covers problems common to all architectures. Table 2 contains the URLs for the list of ftp mirror sites carrying the release and for the errata.

Boot (And Booting Problems)

There are several methods for booting into the Red Hat installation program. Unfortunately, many of the worst bugs in the initial release were directly related to the boot process, so 4.0 could be quite a struggle to install, especially for anyone not familiar with the peculiarities of a SPARCstation to begin with. While the 4.1 release addressed many of these problems, there are still a few remaining bugs with the boot floppy images on the CD-ROM, and you'd be much better off ftp-ing the latest images from the Red Hat server.

Booting from the CD-ROM is the first and most obvious method. Note that while the official Red Hat CD-ROM is bootable, copies of the distribution on other vendors' “compilation” CD-ROM sets will usually not be. The drawback with a boot from the 4.0 CD-ROM is a bug preventing installation across multiple partitions, on the target disk. If you boot from the 4.0 CD-ROM you must install everything into one, large partition. If you attempt to install across multiple partitions, the install process fails shortly after creating the file systems on your hard disk. I need to emphasize here that this problem is restricted to booting from CD-ROM and 4.0 only. Any of the other methods of installation outlined below will circumvent this problem, as will booting from a 4.1 CD-ROM.

The command for booting from the CD-ROM is bsd(0,6,0) (from the > prompt) for those machines with a boot PROM revision of less than 2, or boot cdrom (from the ok prompt) for those machines with a boot PROM revision of 2 or greater. The single partition problem can be overcome by net booting your machine (see below) and then continuing with the install from the local CD-ROM.

Creating boot and root floppies is the obvious method for anyone who has downloaded the distribution across the Internet or who must boot from CD-ROM. Creating the floppies is simply a case of using dd on a Linux or Unix system, or using the supplied “rawrite.exe” program on a DOS machine. Booting from the floppy is either bfd() (PROM revision less than 2), or boot floppy (PROM revision 2 or greater).

Unfortunately, as mentioned earlier, the v0 floppy image from both the 4.0 and 4.1 CD-ROMs has major problems, and the boot process will almost always fail with messages which tend to make it appear as though the media itself were faulty:

ok boot floppy
Booting from: fd(0,0,0)
SILO
Read error on block 1
Read error on block 8
Fatal error: Unable to open filesystem
boot:

The third method for booting, and the one I'd recommend, is a network boot. This is your only option if your system has neither a floppy nor local CD-ROM drive, and it is an elegant work around for the problems besetting the CD-ROM and floppy installs. Assuming that you have access to a network and at least one other Linux or Unix system, this is by far the most reliable method. Note that what we're talking about here is only booting across the network, not setting up a diskless client. Creating a diskless client requires a server with a fair sized chunk of free disk space, and assumes that the server has the horsepower and network bandwidth to support the client machine, whereas a boot server needs only enough disk space to hold the install image file and serve it to the client once at boot time. The client machine is not otherwise dependent on the server, and once the install program is running on the client it need never refer to the server again.

Setting Up A Boot Server.

The “images” directory on the CD-ROM and the ftp server contain both the floppy files (boot-v0.img and boot-v2.img) and a separate tftpboot.img file. As with the floppy images, the latest tftboot.img file can downloaded from one of the Red Hat mirror sites.

It is this latter file that is required for a network boot. The method used to configure the boot server is almost identical for Linux, SunOS and Solaris systems. We'll use an example configuration, where our boot server is a machine called tyne.gaijin.co.jp and the SPARCstation client is coquet.gaijin.co.jp. The server IP address is 172.17.172.50.

  • Assign an IP address for your new machine on the same sub-net as the boot server. In our example, the next available IP address for the client “coquet” is 172.17.172.52. It's hardware Ethernet address (MAC) is 8:0:20:3:9:96.

  • Create a directory for the tftp boot files on the server. SunOS and Solaris machines use /tftpboot by default, and we can use this directory on a Linux system, too.

  • Copy the tftpboot.img file to the newly created directory.

  • Create a symbolic link from the tftpboot.img file to a unique file name which the SPARCstation boot PROM requests across the net. The format of the symbolic link is <CLIENT_HEX_IP_ADDRESS>.<ARCHITECTURE>. Take the IP address which you assigned in the first step and convert it, section by section, to hex and then add the architecture of your system. In our example, we need to convert 172.17.172.52 into hex words and, since we aren't exactly sure what architecture our new system is, we'll create links for both 4c and 4m machines.

172     =       AC
17      =       11
172     =       AC
52      =       34
ln -s ./tftpboot.img AC11AC34.SUN4C
ln -s ./tftpboot.img AC11AC34.SUN4M

Note that unlike SunOS and Solaris, the same boot image can be used for both 4c and 4m architectures.

Figure 2. Connections to SPARCstation ELC

  • Enable the tftp daemon in /etc/inetd.conf. The syntax for this entry is slightly different between Linux and SunOS/Solaris systems. On the Sun systems there's a -s option which enables the daemon in “secure” mode. The Linux tftp daemon does not use this option and, if it is present in the config file, it treats it as a directory name and all tftpd accesses fail. The other difference between Linux and SunOS/Solaris is that most recent versions of Linux come with the inetd.conf file configured with the tcpd logging daemon configured as default.

Linux:

tftpd dgram udp wait nobody /usr/sbin/tcpd\
        in.tftpd /tftpboot

SunOS:

tftpd dgram udp wait root /usr/etc/in.tftpd\
        in.tftpd -s /tftpboot
Solaris:
tftpd dgram udp wait root /usr/sbin/in.tftpd\
        in.tftpd -s /tftpboot
  • Reinitialize inetd using a kill -HUP <inetd PID> or by rebooting the server.

  • Ensure that the the client's Ethernet address is in the arp cache, and the rarp cache for Linux systems, on the server.

arp -s 172.17.172.52 08:00:20:03:09:96
rarp -s 172.17.172.52 08:00:20:03:09:96
Note the leading zero padding added to the Ethernet address in both cases.

The rarp command might produce this error:

cat: /proc/net/rarp: No such file or directory

It indicates that rarp isn't compiled into the kernel, and that the rarp module hasn't been loaded. Use insmod to load it and rerun the rarp command.

server# insmod /lib/modules/2.*.*/ipv4/rarp.o
If the module isn't present, you'll have to rebuild the kernel with rarp enabled.

The client system usually takes about three minutes to boot into the installation program. The screen changes from the default black-on-white to white-on-black with a much smaller font once the kernel loads. You'll start to see the normal Linux boot messages as devices are probed and identified. At the end of the boot sequence the system drops straight into the install program, and from that point onwards the prompts are pretty much self explanatory. There are still a few things to watch out for, though.

Virtual Consoles

Red Hat install makes virtual consoles available to the user during the whole of the installation process. <ALT>F1 gets you to the main installation screen, <ALT>F2 is a shell, <ALT>F3 displays informational messages from the installation program, <ALT>F4 displays console messages and <ALT>F5 displays messages from the individual package installation programs as they run.

Fdisk

Figure 3. Bare Connections to SPARCstation ELC

The SPARC-Linux installation requires that you create a “whole disk” partition (file system type “5”), spanning from cylinder 0 to the last available cylinder. Root, swap and /usr partitions are created in the normal way and overlap this “whole disk” partition.

As you can see, SPARC-Linux also numbers cylinders from 0, rather than the i386 Linux default of 1.

4.0 Specifics

If your initial install is from a 4.0 CD-ROM, there are a few things which you need to know (see Red Hat's errata list for up to date information). You really should update your kernel as soon as possible to circumvent a particularly nasty networking bug which plagued the 2.0.18 kernel shipped with this release. The problem causes random hangs and crashes, especially when the machine is attached to a network where IPX packets are also present. When updating the kernel on your system, be sure to update the kernel loadable modules, too. New kernel and module packages are available in Red Hat's RPM package format on their FTP server, or alternatively, you can get a binary “snapshot” of the latest kernel from vger.rutgers.edu (see Table 2).

Another problem which can be perplexing if you don't know about it beforehand is the dump program. This slipped into the distribution without having been checked for “endian-ness” and consequently behaves very strangely indeed, complaining about seeks to negatively numbered sectors and blocks. Again, an updated dump package is available from the Red Hat site. Version 0.3-5 or greater should work.

Wrap-up

As I write this, a group of folks are putting together the first Debian release of SPARC Linux. However, Red Hat is the only complete packaged release available on CD-ROM. While Red Hat's initial, 4.0 release suffered from a few teething problems, it has brought SPARC Linux into the mainstream Linux arena, rather than being confined to a backwater as something of an oddity. The worst of the problems have been fixed in 4.1, and this newer release also comes at a much more attractive price. The availability of both versions via FTP and on other vendors' compilation CD-ROMs is adding to the popularity of this architecture, and the installed base is spreading rapidly as evidenced by the increased traffic on the SPARC Linux mailing list. While I.T. professionals may still be reluctant to migrate the whole of their user base to SPARC Linux, there certainly seem to be a growing number of organizations out there who have one or two systems at least under evaluation. Many more old SPARC workhorses are getting a new lease on life with Linux and popping up on the Internet as FTP and Web servers.

John Little worked for Sun for nine years, is from the U.K., lives in Japan and works in Tokyo for an American company. He wears a range of increasingly bizarre hats in an (mostly futile) effort to hide his incipient baldness. He can be reached by e-mail at gaijin@pobox.com.
Load Disqus comments