This chapter describes the base hardware and software requirements for enabling Linux on the JavaStation.
For hardware, you will need one or more JavaStation clients and a server to feed it its Linux image from, all networked on the same net segment.
This server you use can be any server which supports DHCP and TFTP, and RARP. These are the base protocols needed to perform a network boot of the JavaStations. You may also need NFS service as well, but it is not necessary in one type of configuration this HOWTO describes. Also, you can get by without RARP on both the Krups and Espresso models.
This document will describe how to set up serving the network Linux OS image to the JavaStation from a Sun server running SparcLinux. While you do not need a Sun server to serve your Linux image off of, the Sun SparcLinux server is needed should you wish to compile a kernel of your own, or prototype a new filesystem for your JavaStations to use. Otherwise, you will need to use prepackaged kernels and filesystems somebody else has pre-built and made publicly available for use.
Your network can be a simple 10 Mbps ethernet LAN, but when you begin using more than 50 JavaStations at once, a switched 100 Mbps network becomes desirable for your server to handle multiple concurrent boot requests.
This HOWTO includes example kernels and filesystems for you to use, eliminating your need of a Linux/SPARC server, but you still need a server of some type to feed the image to the JavaStations as they boot.
As discussed in the last section, the JavaStation boot cycle will make use of DHCP and TFTP with possibly NFS and RARP. To understand why, read up on the JavaStation boot sequence in the next section.
The JavaStations follow a typical diskless workstation boot sequence.
When powered on, the JavaStation sends out a broadcast request for its IP. It gets its IP info via RARP or DHCP. With a DHCP response, it gets information about the network it is on and where to go download its boot image from via TFTP.
There are subtle variations in diskless boots from one diskless machine to the next. For instance, BOOTP may sometimes be substituted where DHCP is, and RARP may be eliminated in favor of either of the two. But in general, the sequence is typically the same between the client and the server:
C: "Who am I?"
S: "You are xxx"
C: "Where do I go for my boot image?"
S: "You go here."
C: "Give me my image from here...Please?"
S: "Here's your image."
After the kernel is finished loading, your diskless client typically mounts its root filesystem from the network via NFS. Alternatively, it may load and mount it from a RAMdisk.
JavaStations came with two different PROMs installed in them. Version 2.30 shipped with the earliest Mr. Coffee models, and was updated by latter versions of the Sun Netra J software environment to 3.11. Krups and Espresso came with 3.x versions of the PROM by default.
It turns out the later 3.x series of PROMs is not conducive to booting Linux upon. Fortunately, kernel hacker Pete Zaitcev <zaitcev@metabyte.com> wrote a complete PROM replacement called PROLL.
PROLL becomes the first image your JavaStation grabs by TFTP. It then will load your true kernel image and boot into Linux.
No matter what PROM revision you have, get PROLL. This can make troubleshooting new installs easier.
The current, master version of PROLL is available from Pete Zaitcev's website at: http://www.metabyte.com/~zaitcev/linux.
The current version at the time of this writing is "11".
PROLL can also be found mirrored on "VGER", and also on this HOWTO's distribution site at: http://www.mscs.mu.edu/~tech/Linux_on_JS/Files/proll_11.tar.gz (HOWTO website mirror)".
Before you begin, you must decide upon the root-filesystem type you wish to use for your diskless JavaStation.
In this setup, after the boot kernel is retrieved off the network, the running JavaStation makes an NFS connection for its root filesystem. The root directory "/" is mounted off the network for the duration of the current session.
The "NFS-Root" solution is the recommended way to go for beginners, as it is easier to troubleshoot if there are problems. It also makes it easier to prototype the proper filesystem, as any changes you make on a running system can be propogated for the next boot cycle (so long as you are in read-write mode, of course).
In this setup, the root filesystem is loaded directly into RAM and accessed from there.
The advantage of this setup is that there is no NFS traffic to worry about, resulting in a clean solution.
The disadvantage of this configuration is that you can no longer do rapid prototyping of your filesystem, as any changes you make to a running system are lost. If you have no "NFS-Root" setup available, you develop an embedded filesystem by making small tweaks and performing reboots to test.
First time users will want to set up an "NFS-Root" configuration. When you have things stabilized, move to "Embedded-Root" and make use of its advantages.