Linux on the Sun JavaStation NC HOWTO

1.1. The Purpose of this Document

This document is to serve as a comprehensive HOWTO and FAQ collection regarding the Sun JavaStation NC and enabling the GNU/Linux OS on it.

The intended audience of this document is anyone who has an interest in enabling Linux on the Sun JavaStations. The document structure is laid out to serve as either a top-to-bottom read for a newcomer, or as quick reference on a single topic for advanced users. Pointers to sample files submitted by users are included for extremely hurried readers.

The author of this document is Robert Dubinski <rsd@dubinski-family.org>. Robert is the former computer technician and UNIX systems administrator for Marquette University's Math, Statistics and Computer Science Department, where he had 125 JavaStations running Linux. These machines were all configured using the information, techniques and files presented in this document.

In early 1999, Eric Brower <ebrower@usa.net> wrote the first informal HOWTO for the JavaStation. Parts of this document are inspired by his work, and all unique information presented there have since been merged into this document. Eric's original mini-HOWTO is saved for posterity at: http://dubinski-family.org/~jshowto/Files/texts/eric_brower_js_howto_19980218.txt

This HOWTO also aims to serve as a member document of the Linux Documentation Project. The LDP can be reached at: http://www.linuxdoc.org

1.2. Acknowledgments

Enabling Linux on the JavaStations , and allowing this HOWTO to come to be would never have been possible without the fine work of the following people:

• Pete Zaitcev <zaitcev@yahoo.com> (Primary JavaStation kernel mod author)

• Eric Brower <ebrower@usa.net> (XFree mods and author of the original embedded-build HOWTO)

• Varol Kaptan <varol@ulakbim.gov.tr> (made available his Krups images and patches. Backported kernel support to 2.2.x series)

• David Miller <davem@redhat.com> (the original Linux/SPARC kernel porter)

• The Linux/SPARC kernel porters and mailing list

• The thousands of contributors to the Linux kernel

The HOWTO author wishes to give a second thank-you to Pete and Eric for their work:

1.3. History

1.4. Document Copyright and Licenses

Copyright (c) 1999-2001 Robert S. Dubinski. Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.1 or any later version published by the Free Software Foundation; with the Invariant Sections being: "Why JavaStations are No Longer Produced", with one Front-Cover Text: "Linux on JavaStation HOWTO", and with one Back-Cover Text: "This document was written by Robert S. Dubinski in the hope that more people can put their JavaStation hardware to good use. Thank-you to the Linux kernel hackers who made this happen, and thank-you to Sun for a rock-solid piece of hardware." A copy of the license is included in the section entitled "GNU Free Documentation License".

The document author makes no warranties that all the information presented here is completely accurate, and cannot be held liable to any loss you experience as a result of the information you use from here.

Best efforts have been made to ensure everything included is accurate as of the publication date listed at the beginning of this document, but there is always a possibility something may be wrong. In this case, doublecheck with alternative sources first before considering implementing anything at a production-level. If you find something wrong, drop the author a line at <rsd@dubinski-family.org> or send a patch to the document source, and corrections will be made immediately.

This document is an official member document of the Linux Documentation Project.

1.5. Location of the Latest Version and Source

The latest online version of this document can be found at: http://dubinski-family.org/~jshowto .

The pre-processed XML source to this document, written to the Docbook DTD, version 4.1.2, is available from: http://dubinski-family.org/~jshowto/doc/src/

The pre-processed XML source to the GNU Free Documentation License, written to the Docbook DTD, and which this document is licensed under, is available from: http://dubinski-family.org/~jshowto/doc/src/gfdl.xml

Copies of this document are also available from the Linux Documentation Project at: http://www.linuxdoc.org/HOWTO/JavaStation-HOWTO.

This project used to be available at the URL 'http://javastation-howto.homeip.net'. In Spring 2001, homeip.net discontinued their free service and moved to a fee based scheme. Given the hundreds of mirrors of LDP documents, I do not find the fees justifiable. I have changed all references in this document back to my home server. Between my server's address, http://dubinski-family.org/~jshowto, the LDP website, and its hundreds of mirrors, you should be able to always find the JavaStation-HOWTO. If this is not the case, email me immediately at either <rsd@dubinski-family.org> or <dubinski@mscs.mu.edu>.

1.6. Reporting Bugs Found In or Additions to the HOWTO

Any problems or concerns about the HOWTO should be reported via email to the author, Robert Dubinski, at <rsd@dubinski-family.org>. Do NOT send document bug reports to the SparcLinux mailing list, the debian-sparc mailing list, or the Linux Documentation Project. The folks on there really do not care about my typos or server misconfigurations, so please don't trouble them.

1.7. TODO List for this HOWTO

1. As NetBSD now supports JavaStations as well, it would be good to talk about support and sample files for it too.

2.1. What is a JavaStation NC?

The JavaStation NC is a model line of network computers built and sold by Sun Microsystems between November 1996 and March 2000. The JavaStation line was Sun's low-cost terminal option during that timeframe. It was the marketed successor to the Xterminal 1 and is succeeeded by the SunRay, although all three machines are fundamentally different.

The JavaStation hardware ran Sun's own JavaOS and either Sun's Hotjava web browser, Sun's HotJava Views task-manager software, or custom Java applications of the customer's choice.

The JavaStation was originally billed in November 1996 sneak previews as a low-cost desktop terminal, providing customers access to hot new Java applications, "legacy" X applications, and "legacy" MS Windows apps. During its lifetime, The JavaStation's marketed functionality was changed twice from "desktop terminal" to "single-app desktop device" to finally a "browser-based kiosk device".

At no time did Sun market the JavaStation as capable of running its flagship Solaris operating system the Linux OS, or any other OS than Sun's JavaOS.

2.2. Definition of an NC including the Differentiation from PC's

A network computer, or NC, was hailed as "the next big thing" in computing from late 1995 to early 1998. Conventional PC's, called "fat clients", were expected to be minimized in businesses by thin-client NC's.

Thin-clients get their OS, applications, and data files entirely through the network. They are different from dumb-terminals; they run full-scale graphical applications. Thin-clients are also different than graphical X-terminals. X-terminals typically run an X server and display the client programs of a remote server. Thin clients generally run full-scale graphical programs locally, such as a web browser, a Java application, or a "legacy-connectivity program", which enables the thin-client to display X apps or MS Windows apps which run on more powerful servers.

Advantages of NC's include:

• "Zero-Administration". (Add a new NC and it will get everything it needs off the network, without an admin ever needing to visit it.)

• Lower Total-Cost-of-Ownership (TCO) (No internal hard drives, floppy drives or CD players reduces form-factor, repair expenses, selling price and thus total-cost-of-ownership.)

• Access to all web-based apps as well as "legacy" X and MS Windows apps.

• Quick upgrades (just upgrade your server and the changes propogate throughout)

• Longer lifespan (just upgrade the software, growing hard disk and memory requirements is not an issue)

• Smaller OS footprint (when running brower-based apps)

Disadvantages of NC's:

• No local access to data files (all your files stored on a remote server)

• Requires fast, stable networks

• NC's generally have a low maximum amount of memory. Though not as bad as with fat-clients, this does eventually become a liability for the thin-client.

2.3. Description of the JavaStation Model Line including Hardware Specs

Depending on who you talk to, the number of JavaStation models that were created is anywhere from one to six. The descriptions below will explain why.

Boot device: /ethernet   Arguments:
MAC Address: 08:00:20:95:5b:49
Open Boot 3.0, Built February 16, 1999 17:38:37
NIC: 10b7,9055 ethernet in PCI1                                           64MB SDRAM
Non-Volatile Device Memory Module Not Installed
SmartCard Reader Found
CPU Speed:  266 MHz


Can't open boot device

ok                         

2.4. Reasons for Running Linux and NC Myths Dispelled

It turns out that Linux makes the JavaStations perform more than adequately on the desktop. Thanks to the dedicated work of the Linux developer community, the JavaStations offer users the low-cost, zero-admin, versatile desktop NC's they were originally billed to be, but with the added freedom granted by the Linux OS.

While low-cost PC's now eclipse the JavaStation in terms of default CPU speed and RAM size, the JavaStations running Linux are still well-suited for a number of tasks:

• Diskless X-Terminal. (Gives the JavaStations the capability of the Sun Xterminal 1 hardware that they replaced).

• The NC solution, Linux-style: local X + a java-capable browser can make the JavaStations perform like they did with JavaOS/ HotJava, only many times faster.

• A beowulf node, or a dedicated RC5/ SETI@HOME client. The JavaStation running Linux makes a stable, long-lasting number cruncher.

• A small, standalone machine. While a task more suited on today's low-cost machines, there's not much that prevents the JavaStation from performing as a full-fleged standalone UNIX machine by itself. Just remember to set your expectations appropriately when doing so; they were "low-budget" clients when they were sold, and should not be directly compared to today's workstation offerings.

• A small router and server, particularly with the Espresso model decked out with added IDE disks and NIC.

In all of the above scenarios, there is little to no maintenance of the machine once configured properly. Such is the advantage of the NC hardware.

JavaStations run so much better with Linux than JavaOS, one would think that even Sun should have offered it as an option. Unfortunately, Sun had killed the line in favor of the Sun Ray . While the performance of the Sun Ray is good, keep in mind it is not intended as a dedicated computing device, and due to its firmware is little more than a graphics display hanging off your Sun server, which can give you some unexpected bonus features (translation: "brand-name product lock"). The performance on the JavaStations with Linux will be similar to what you can get with a Sun Ray, but if ever you want to do something different with your machines, you have the flexibility to do so with the JavaStations. There was rumor of work to try and override the default behavior of the SunRay firmware, and make it into an adjustable computing device, but until that happens, running another OS on a SunRay is just a pipe-dream.

Lastly, if you're thinking of switching to diskless Xterminals on your network, you might consider the JavaStations over stripped down PC's. The hardware is standardized, smaller, and you do not need to worry about burning boot PROMs and the like.

2.5. Why JavaStations are No Longer Produced

Sun's official stance is that the JavaStation line was terminated in favor of the new Sun Ray line. A trip to the former JavaStation section of Sun's website at http://www.sun.com/javastation verifies this formal positioning. (fair use archival copy at: http://dubinski-family.org/~jshowto/Files/texts/sun_js_site_death.txt )

As the Sun Ray is not an NC in the traditional sense (it has a MicroSparc IIep CPU, but the firmware on the device prevents anyone from grasping it), there is no explanation why the two products could not co-exist.

In talking to the users of the JavaStations in the pre-Linux era, you will find strong opinions as to why the JavaStations are no more. The common thread in almost all opinions collected is that the software provided by Sun was inadequete for a production environment. Here are collected opinions from users of the Sun-provided software, included with their permission:

More comments and rebuttal statements by Sun employees are always welcome.

(update Oct 2001): A year and a half of this document's existance and not a single rebuttal statement by Sun. There were a couple initial requests to omit this section, but I refused. After all, imagine a new reader who never saw a JavaStation before: They'd read to this section, think "Wow, what a great little machine..let me get one!", and then ask themselves, "If it did all this, why don't they make them anymore?". The bad must be included with the good, and to leave this section out is a disservice to all the users who suffered through the poor software and support during the official lifetime of the JavaStation. This section, therefore, is a necessity, and although this document is licensed under the GNU Free Documentation License, the eagle-eyed reader will note that this section has been labeled as "invariant" to protect it from entities who may wish to bury it (which is precisely the reason why the Invariant clause of the GFDL exists).

2.6. Where to Purchase a JavaStation

Since Sun has canceled production of the JavaStation line, it no longer sells them through their official channels. Sun contacts have informed me that all internal JavaStation stock was cleaned out and dumped in 2000. Therefore, All JavaStations are now found out in the wild.

Your best bet to get JavaStations though is out on the open market. Educational institutions which received a handful from Sun as demo units are now trying to offload them any way they can (too bad they don't read this HOWTO). Search around the auction sites like Ebay and Yahoo Auctions, and you should be able to turn some up.

A great resource for JavaStations used to be "Bodoman's JavaStation site" at: http://www.bodoman.com/javastation/javastation.html. Sadly, as of October 2001, the domain bodoman.com seems to no longer resolve. Ebay may now be your best bet.

Mr. Coffee is the most widespread JavaStation model, and has tended to sell around $30-80US consistently for the last year or so.

Krups models more rare and sell at higher prices, probably because the stylish case still stands out today. Prices on Ebay are always over $100, but for Oct. 2001, their technology is definitely no longer worth that much. A good price would be $80-85US. Many reports have come from the UK telling of many Krups models getting dumped there.

The Dover models were a very hush-hush thing when this HOWTO was initially published, but the secret is out: if you want one, go to South Africa. Dovers seemed to have been dumped there en masse. Pricing is unknown, but should be comparable to a Cyrix-266 PC clone.

The Espresso and JavaEngine models are near impossible to find, so if you get one, consider yourself lucky. If you have a Fox, well, you're just too cool. Pricing for these models is likely a premium. (>$100US).

3.1. Complete Hardware Requirements

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, a Sun SparcLinux server is recommended 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. (You might also use a cross-compiler to produce the kernel images, but prototyping a filesystem is best done on a Sun SparcLinux server.)

Reports of successful boot servers used include Sun boxes running Sparclinux, Sun boxes running Solaris, and PCs running MS Windows. It is only when you are building a new kernel or filesystem that a Sun box running Linux becomes valuable.

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 pointers to example kernels, filesystems and a complete out-of-the-box solution for you to use, eliminating your need for a Linux/SPARC server, but you still need a server of some type to feed the image to the JavaStations as they boot.

3.2. Network Service Requirements

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.

3.3. Understand the JavaStation Boot Sequence

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:

1. C: "Who am I?"

2. S: "You are xxx"

3. C: "Where do I go for my boot image?"

4. S: "You go here."

5. C: "Give me my image from here...Please?"

6. 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.

The original JavaOS and Hotjava Views environment, when run on a JavaStation, required the setup and maintenance of the core services above, plus also NIS, HTTP, DNS, POP, and NTP servers. If setting up a JavaStation boot server seems like a lot of work, imagine adding these extra services into the mix too.

3.4. Additional Software Requirements: Replacement Firmware (PROLL)

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, a complete PROM replacement called PROLL now exists to get by this limitation.

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: http://people.redhat.com/zaitcev/linux/.

The current version at the time of this writing is "14".

PROLL can also be found mirrored on "VGER ", and also on this HOWTO's distribution site at: http://dubinski-family.org/~jshowto/Files/proll/proll_14.tar.bz2 (HOWTO website mirror - version 14)

3.5. Decide on your Filesystem-type: NFS-Root, or Embedded?

Before you begin, you must decide upon the root-filesystem type you wish to use for your diskless JavaStation. There are two possibilities.

3.6. Support Sites to Check Out: Zaitcev's Linux Site

One website to keep on reference when you begin thinking about putting Linux on your JavaStation is kernel hacker Pete Zaitcev's website at: http://people.redhat.com/zaitcev/linux/, referenced throughout this document as the "ZLS" site (short for "Zaitcev's Linux Site"). Here you will find the latest version of PROLL and many low-level details about dealing with the JavaStations. Many items on the ZLS have been merged into this document, but not all.

Oct. 2001 update: It is in your best interest to review all the information on Pete's site, in this document, and references pointed to, before diving in and setting up your JavaStation with Linux. Almost all questions people have had in setting up their systems are covered in the materials presented.

4.1. Before you begin

This chapter assumes you wish to compile your own Linux kernel for the JavaStation. If this is something you can not do, there are sample kernels pointed to at the end of this chapter.

This chapter assumes you already know how to compile Linux kernels in general, perhaps on a PC, a SPARC server running Linux, or any of the other Linux ports. If not, read the Kernel-HOWTO and the README file of your kernel source.

Compiling a kernel for a JavaStation is not much different than compiling a Linux kernel elsewhere. You just need to know the right options to pick. In general, you're compiling for a Sun4M class architecture, and enabling JavaStation-specific options. The following sections in this chapter will take you through the steps.

While it may be possible to compile the JavaStation -enabled kernel on alternate platforms by way of a cross-compiler, this HOWTO assumes you will do it on a Linux/Sparc based server running in 32-bit mode. Cross-compiling will not be covered, and questions regarding it will not be entertained.

4.2. Make sure you use 32-bit mode

When compiling your own JavaStation-capable kernel on a Sun server, you need to make sure the machine you work on is set to 32-bit mode. So, if you're on an Ultra-class machine, be sure to first switch to 32-bit mode before you begin compiling.

To check what mode you're in, do a uname -a. If it says "sparc", you're in 32-bit mode and don't have to do anything. If it reports "sparc64", then you should perform a sparc32 bash first to switch to 32-bit mode. A subsequent uname -a should reflect the change.

4.3. Supported Linux Kernel Versions

The kernel source revision you should use depends both on which model of JavaStation you have, and which series kernel you are using. The current "stable" series of Linux kernels is 2.4.x, but as we will read in a minute, this may not be the best bet to use.

First, a few note on the 2.2.x and 2.3.x series. Mr. Coffee has had kernel support since about kernel version 2.2.5, and definitely works out of the box with the RedHat 6.0+/SPARC distribution kernels. Krups support did not work well out of the box until the latter 2.3.x kernel cycle. Krups support was added in the early 2.3.x sequence, but the MMU changes to the 32-bit SPARC kernel had kept it from compiling cleanly until later on.

Kernels for both Mr. Coffee and Krups compiled cleanly by the HOWTO author with the Mar. 17, 2000 CVS kernel, and are included in the Sample Kernels section.. Krups support was backported into the 2.2.x kernels (where x>15). The latest 2.2.x kernel "should" compile cleanly for the Mr. Coffee and Krups models, but your mileage may vary.

Now onto the 2.4.x series.

The only kernel which has been tested and compiles cleanly for Mr. Coffee and Krups is version 2.4.2. All other versions are broken or require a patch.

The reason for this is that the sparc32 branch of the kernel has not had an active maintainer for many months. Some are contributing fixes, but without an active maintainer things go slow.

There is another reason to be weary of the 2.4.x series. From 2.4.0 through 2.4.9, the VM of the kernel was found to be inadequate under heavy loads, and was subsequently replaced in 2.4.10+. This was a big change for the so-called "stable" series of kernels.

To add further insult to injury, there have been security flaws detected in all of 2.2.x kernel series and up through 2.4.12. This is patched in pre-2.2.20 and 2.4.12+. As of this writing, 2.4.12+ has not been checked by the author as functioning on the JavaStations.

So basically, it has been a crap-shoot over which kernel to choose. Try a few until you find one that suits you best.

If you can not get a kernel to compile, or wish to avoid the headache or trying, you may try the samples pointed to by this document.

4.4. Required Kernel Configuration Options

When you do your make config command to enter the kernel configuration stage, there are a few things you are required to enable. Note that the following option names are from a 2.2.x kernel, and may be slightly different on a 2.4.x series kernel. If in doubt, check the sample files later in the chapter.

For all JavaStations, you want to enable PCI support:

CONFIG_PCI=y 

Don't forget your mouse:

CONFIG_BUSMOUSE=y 
CONFIG_SUN_MOUSE=y 

You'll want video, done with the Linux framebuffer interface:

CONFIG_FB_TCX=y (for Mr. Coffee) 
CONFIG_FB_PCI=y 
CONFIG_FB_IGA=y (for Krups/Espresso) 

Audio is done with the Crystal Audio 4231 chipset:

CONFIG_SPARCAUDIO=y 
CONFIG_SPARCAUDIO_CS4231=y 

Don't forget your network interface:

CONFIG_SUNLANCE=y (Mr. Coffee) 
CONFIG_HAPPYMEAL=y (Krups/Espresso) 

You'll no doubt need to support a filesystem:

CONFIG_EXT2_FS=y 

You'll want IP autoconfiguration, and RARP/BOOTP support:

CONFIG_IP_PNP=y 
CONFIG_IP_PNP_BOOTP=y 
CONFIG_IP_PNP_RARP=y 

When doing the "NFS-Root" filesystem configuration, you will need both NFS and NFS-Root support:

CONFIG_NFS_FS=y 
CONFIG_ROOT_NFS=y 

When doing the "Embedded-Root" filesystem, configure both RAM disks and "initial ramdisk" support:

CONFIG_BLK_DEV_RAM=y 
CONFIG_BLK_DEV_INITRD=y   (for 2.4.x, also configure size of ramdisk)

You can get a working ".config" file which has the required options set later in this chapter.

4.5. Necessary Patch for "Embedded-Root" FS Configurations

If you have decided to go with the "Embedded-Root" filesystem option, you will want to make a patch to the RAMdisk driver source first.

The default size of a RAM disk when using the RAM disk driver is 4 MB. Chances are that you will want an embedded filesystem of more than that size, particularly when you start thinking about running an X server, or including a Java runtime.

You can do this for 2.2.x kernels by a manual edit yourself, or by using the patch pointed to below. The change is a one-line edit in the file <LINUXROOT>/drivers/block/rd.c . Look for a line that says:

int rd_size = 4096; /* Size of the RAM disks */ 

and change it to the size of the RAMdisk you wish. Typically, most embedded systems are under 16 MB, so a common edit is to change the line to:

int rd_size = 4 * 4096; /* Size of the RAM disks */ 

If you can not do this, the patch below makes the edit for you.

4MB to 16MB kernel patch file is at: http://dubinski-family.org/~jshowto/Files/patches/ramdisk_patch.txt

Kernels in the 2.4.x series allow you to select the amount of RAM as a configuration option. The patch is no longer needed for those kernels.

It should also be noted in this section that there is currently a limit on the size of Linux boot image for all JavaStation models, due to the implementation of PROLL. This limit is technically 8 MB. This topic is mentioned again in the "Questions and TroubleShooting" section of this document.

4.6. Build the JavaStation-Ready Kernel

To build the kernel, you type make vmlinux. If you come from an x86 Linux background, you might be surprised that you do not perform a make bzImage or make zImage. Do not be alarmed: this command is correct.

When the compile is finished, you will find a file named "vmlinux " in the kernel source root directory. You are almost ready to put this kernel to use.

4.7. Convert Kernel from ELF to a.out format

You need to make one more change to your kernel before it is ready for use. You need to convert it from ELF to AOUT executable format. You can do this with the "elftoaout " utility included in most Linux/SPARC distributions.

To convert your kernel image to the AOUT executable format, you issue the command:

elftoaout -o vmlinux.aout vmlinux 

You will probably now want to rename the image file to a longer name which includes the current date and kernel revision you used, so as not to get confused with when you have multiple boot kernel images down the road.

The elftoaout program should come with your SparcLinux distribution. If not, try VGER or your favorite kernel mirror.

4.8. JavaStation-Ready Kernel Images, System.map and .config File Samples

Here are some sample ".config" and JavaStation -ready kernel images. They were prepared and donated to help get you up-to-speed quickly.

Warning: Some of these kernel images are considered out of date, and should be avoided in a production environment. It is up to you to decide how much of a liability you feel running them holds. The document author and kernel contributors cannot be held liable for any damage caused by the use of these kernels. They are provided with absolutely no warranties.

If for some reason you have troubles downloading, try holding left-shift on your browser as you click the link. Kernel images are compressed with bzip2 compression. They must be uncompressed before use. Kernel images are already converted to a.out format.

If you mirror these files, or can verify they work on a machine not yet confirmed, PLEASE email me so I can add your information here.

5.1. Preparing Yourself to Build Your Own Filesystem

Building a filesystem for use with the JavaStations is a time-consuming, but rewarding task for those who undertake it. You will learn more about library dependencies than you ever thought you could, all the time while trying to keep the overall image size as small as possible.

WARNING: This is not an easy task. Creating a lasting filesystem is not for novices. If you seriously consider undertaking this step, prepare to budget a bit of time to get things just right, particularly if you plan to make an embedded-root filesystem which fits in the 8MB limit. You have now been properly warned.

There are two common approaches one can take when rolling a new JavaStation-ready filesystem.

1. Start with an established distribution's filesystem and whittle down to the core.

2. Start with an established distribution's "rescue disk" filesystem and add desired functionality.

Which path you take, of course, is entirely up to you. The "rescue disk" build procedure seems to work best though, as more base commands in a rescue disk are statically linked, increasing the starting image size but causing less initial library headaches. Commands included on a rescue disk also happen to be bare-bones, with many extraneous options not compiled in.

Obviously when building a filesystem in the context of the JavaStation, you will be basing off of an existing Linux/SPARC filesystem. The filesystems that come with the RedHat, SuSE or Debian distributions are good starting points.

5.2. Contents of the "/etc/fstab" File

The configuration lines placed into "/etc/fstab" depend on whether you will be using the "NFS-Root" or "Embedded-Root" filesystem configuration.

###
#
your.nfs.server:/path/to/filesystem  /  nfs defaults,rsize=8192,wsize=8192 1 1
#
none                    /proc                   proc    defaults        0 0
###

###
#
/dev/ram /     ext2  defaults
#
/proc    /proc    proc  defaults
###

5.3. The "Embedded-Root" Image Creation Procedure

Prepping up the "Embedded-Root" boot image requires a number of extra steps. Due to these extra steps, the "NFS-Root" filesystem option is recommended for beginners to Linux on the JavaStation. You might also try the samples pointed to in this document. Should you still wish to build and embedded image on your own, this section outlines the basic instructions.

Creating the "Embedded-Root" boot image is a 5-Step Procedure:

1. Prototype Your Filesystem

   This whole chapter deals with rolling your own filesystem. In this step, it is assumed you create your own filesystem, perhaps by prototyping one on a working "NFS-Root" filesystem configuration.

   One thing to keep in mind is that unlike your "NFS-Root" filesystem, the "Embedded-Root" filesystem must fit within the confines of your allocated RAMdisk, generally 4-16 MB. Your maximum size is dependant on the setting of the RAMdisk driver.

2. Create an Empty File for Your FileSystem

   You now need to create a file-based filesystem "container". This is just a file that is the size of your RAMdisk.

   To create this, try the dd command:

   dd if=/dev/zero of=./fs_test.img bs=1k count=8000

   Using this example, you now should have an 8 MB file named "fs_test.img". Note: Be sure the count you use matches the RAMdisk size you allocated for in the kernel's RAMdisk driver!

3. Format your Filesystem "Container"

   Now that you have a "contain