Setting Up a SPARCstation
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.
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.
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.
Getting Started with DevOps - Including New Data on IT Performance from Puppet Labs 2015 State of DevOps Report
August 27, 2015
12:00 PM CDT
DevOps represents a profound change from the way most IT departments have traditionally worked: from siloed teams and high-anxiety releases to everyone collaborating on uneventful and more frequent releases of higher-quality code. It doesn't matter how large or small an organization is, or even whether it's historically slow moving or risk averse — there are ways to adopt DevOps sanely, and get measurable results in just weeks.
Free to Linux Journal readers.Register Now!
- August 2015 Issue of Linux Journal: Programming
- Django Models and Migrations
- Hacking a Safe with Bash
- Secure Server Deployments in Hostile Territory, Part II
- The Controversy Behind Canonical's Intellectual Property Policy
- Huge Package Overhaul for Debian and Ubuntu
- Shashlik - a Tasty New Android Simulator
- KDE Reveals Plasma Mobile
- Embed Linux in Monitoring and Control Systems
- diff -u: What's New in Kernel Development