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.
|Designing Electronics with Linux||May 22, 2013|
|Dynamic DNS—an Object Lesson in Problem Solving||May 21, 2013|
|Using Salt Stack and Vagrant for Drupal Development||May 20, 2013|
|Making Linux and Android Get Along (It's Not as Hard as It Sounds)||May 16, 2013|
|Drupal Is a Framework: Why Everyone Needs to Understand This||May 15, 2013|
|Home, My Backup Data Center||May 13, 2013|
- Linux Systems Administrator
- New Products
- Senior Perl Developer
- Technical Support Rep
- UX Designer
- Designing Electronics with Linux
- Dynamic DNS—an Object Lesson in Problem Solving
- Using Salt Stack and Vagrant for Drupal Development
- Making Linux and Android Get Along (It's Not as Hard as It Sounds)
- Favorite (and easily brute-forced) pw's
1 hour 14 min ago
- Have you tried Boxen? It's a
7 hours 6 min ago
- seo services in india
11 hours 38 min ago
- For KDE install kio-mtp
11 hours 38 min ago
- Evernote is much more...
13 hours 38 min ago
- Reply to comment | Linux Journal
22 hours 24 min ago
- Dynamic DNS
22 hours 58 min ago
- Reply to comment | Linux Journal
23 hours 56 min ago
- Reply to comment | Linux Journal
1 day 47 min ago
- Not free anymore
1 day 4 hours ago
Enter to Win an Adafruit Pi Cobbler Breakout Kit for Raspberry Pi
It's Raspberry Pi month at Linux Journal. Each week in May, Adafruit will be giving away a Pi-related prize to a lucky, randomly drawn LJ reader. Winners will be announced weekly.
Fill out the fields below to enter to win this week's prize-- a Pi Cobbler Breakout Kit for Raspberry Pi.
Congratulations to our winners so far:
- 5-8-13, Pi Starter Pack: Jack Davis
- 5-15-13, Pi Model B 512MB RAM: Patrick Dunn
- 5-21-13, Prototyping Pi Plate Kit: Philip Kirby
- Next winner announced on 5-27-13!
Free Webinar: Hadoop
How to Build an Optimal Hadoop Cluster to Store and Maintain Unlimited Amounts of Data Using Microservers
Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.
Some of key questions to be discussed are:
- What is the “typical” Hadoop cluster and what should be installed on the different machine types?
- Why should you consider the typical workload patterns when making your hardware decisions?
- Are all microservers created equal for Hadoop deployments?
- How do I plan for expansion if I require more compute, memory, storage or networking?