This section should not be taken as replacing the debian installation instructions. It is more appropriate to think of this a representing a series of hints for creating a set of debian machines that are configured appropriately for mosix installation.
Once you start installing, don't be afraid to tear the whole thing down and start all over again. If you are creating a cluster as part of a learning exercise - well. that is what you are here for. If you are configuring the cluster to be part of a working production environment and you don't tear it down and start all over again when you realize that on a basic level your configuration has a problem you are simply setting yourself up for more difficulties later, for problems at that level tend to propagate, constraining the use of the system. That is not to say that every time you find something you realize could have been done differently you have to start all over again. That's clearly absurd. As you acquire familiarity with your system and the demands placed on it you will see a number of ways in which your system could te tweaked to provide a higher level of responsiveness, reliability, or whatever. One of the strengths of using a cluster of surplus-level hardware lies in the fact that it would be easy to simply configure a new cluster while the first is still in production. On the other hand, if you were to continue implementing a system with a design flaw you see now, you will have less flexibility to deal with problems and less room within which to tune the cluster to better respond to the patterns of utilization it receives in your environment. For example, in the following section I shall relate that when a hard drive began to fail in Ralphzilla-faxa a few days after its initial configuration, I realized there was a good chance the amount of space that had been set aside for outgoing fax storage was inadequate. Now suppose that I had simply replaced the failing drive, and that amount of space did indeed prove to be inadequate. Short of reconfiguring the ralphzilla-faxa box at that point, the most probable response would be to utilize some of the storage on ralphzilla-raider, and connect to it through the mfs file system. This sounds all well and good, but recall that one of the limiting factors in this environment is anticipated to be the 10 Mbps shared ethernet hub which connects the machines. This will be discussed in more detail later, but the hub is limiting not so much for its speed, but because it is a shared medium. Indeed, it is quite possible that ralphzilla-faxa could access a file on ralphzilla-raider faster than on the two-drive stripe set currently configured to hold the fax cache, under the ideal circumstances in which that was virtually the only traffic on the hub. That hub essentially represents the system bus for the gestalt mosix system. In practice, it is quite possible that the additional traffic placed on the hub would, during times of more serious system utilization, be sufficient to significantly reduce effective network bandwidth by increasing ethernet collisions, perhaps to the point of inducing network saturation and bringing system functioning to a crawl. Replacing the hub with a switch would, of course, address that, but the point is that you are now allowing the system to drive you, rather than the other way around.
In any event, if you don't have a broadband internet connection when you start configuring the set of machines you will use in your cluster, purchase as complete a set of the debian CD's as possible. There are a number of sites on the internet from which it is possible to purchase a set of a full debian distribution of three or four CD's for less than $10 USD. If you are planning on using CD's as your primary installation media, go ahead and buy sets for both the potato (stable) and woody (testing) releases. You will need the woody release to load mosix, but remember that woody is the current testing distribution, and as such there are times when scripts bomb out and packages do not configure appropriately. At some point you may have difficulty with a given package or set of packages, and when you do the odds are good that having the potato set will serve you in good stead. As I will mention in other contexts following, my own preferred method of installation is to first install as a potato system and then upgrade to woody. It is my feeling that you are ensured a more stable system by installing in that fashion.
Prior to installation there are some steps you can take that will likely ease the pain of installation considerably. The most important of these is to make a note of the configuration settings of the hardware in your machine. In this circumstance, that primarily means the network card used in your machine, particularly if it is an ISA card. PCI cards can frequently be auto-configured by debian, but this can be determined by the effectiveness of the plug and play extensions on the motherboard in the machine you are using, so it is not a bad idea to find what you can about the settings for the card you are using. For whatever reason, I have had trouble getting 3com 3c905 cards to work. That may be attributable to the plug and play issues I mentioned above, but if you want to play it safe try to come up with another card. Ironically, I've not had that problem with the 3com 3c509, in either its ISA or PCI incarnations. Ralphzilla, as the cluster controller, has two PCI cards, an Intel Etherexpress Pro 100 (running at 10 Mbps) and a PCI 3com 3c509. Each of those cards was set up appropriately by the debian installation when specified. The client machines in the cluster each have NE2000 compatible ISA cards as their network interfaces. These cards were chosen in this context because they are fairly ubiquitous, and if the kernel compiled with mosix support assumes the presence of that card then one element of system configuration has been simplified. The IO address and IRQ's assigned to the cards should, however, be noted before installing any given machine. I adopted the strategy of assigning each a common set of values, IRQ 10 and IO 0x300 (the network driver installation for the ne2000 will require that the IO address be expressed in exactly that fashion, so if you're using ne2000's remember that.) Beyond network cards about the only hardware I can readily anticipate you'll want to use might be SCSI adapters. Check compatibility, but you should be ok. If you somehow want to use multiple adapters in the same machine, however, be aware. I once spent most of a Sunday generating kernels until I found one specific configuration that would allow two SCSI adapters to play together.
If the machine on which you are installing debian has a bootable CD drive and that is your method of installation, simply put the potato installation CD into the machine and boot to it. However, the machines I use in the cluster generally don't have CD drives, and in the cases in which they do the drive is not bootable. This is not an unusual situation for machines of this age. In such instances, your first step should be the same as for a network installation ... make a copy of the potato installation diskettes. The generation and use of those diskettes is the most tedious part of the installation, but is the most reliable way to get the job done using older hardware. The image files for standard 3 1/2 " 1.44 Mb floppy disks can be found in the path /debian/dists/potato/main/disks-i386/current/images-1.44 on your friendly neighborhood debian mirror (consult www.debian.org for a list of mirrors), or should be available in an analogous location on the potato installation CD. The relevant files all have the extension .bin. If you go to the parent directory you will see the directory dosutils. Pick up a copy of rawrite2.exe (and rawrite2.txt, if you actually want the instructions), you will need that program to create the diskettes on a dos/windows machine. While you are there you might as well also download the files rescue.bin, root.bin, and the driver*.bin files from the woody directory. I suggest that because I have been able to rescue a woody machine whose driver modules had mysteriously disappeared by going through a partial installation and rebooting the machine. If you have a bootable woody cd and a bootable cd drive, of course, you could accomplish the same thing by booting the cd into the installation.
When I set up the machines that are part of the ralphzilla cluster, I was also re-configuring machines that had generally been in use for some time as Win95 workstations. In some circumstances I had not reconfigured the target machine in a couple of years. Since each of these machines is five to seven years old, I did not find the notion of dealing with each one onerous, because any problems that machine might have were likely to be revealed at that point.