This chapter explains how you can manage boot configurations centrally using diskless workstations. It explores the reasons why you might want to use diskless workstations, as well as looking at some of the drawbacks to their use. After some background on boot PROMs and how they work, it describes in detail how to set up diskless workstations in a single- or multi-server environment.
Diskless workstations are client workstations that boot from a file server rather than from a local disk. The "disk" in "diskless" really refers to the boot disk. So-called diskless workstations frequently have floppy disk drives and sometimes have hard disks, but they don't boot from them. Instead, their boot configuration and startup files are stored on a server and accessed over the network. Diskless workstations generally boot up more quickly than workstations booted from floppies but not quite as quickly as workstations booted from a hard disk.
This bootup behavior is achieved using a boot PROM (programmable read only memory), an optional chip that plugs into a special socket on a network adapter. The boot PROM takes control of the workstation boot process and allows a special container file on the server (a boot image) to act like a phantom boot floppy disk. The effect is quite convincing--if the workstation has a floppy drive, its drive activity LED lights up and its spindle spins as it reads from a disk that does not exist! Once the bootup process has been completed, the boot PROM retires gracefully and the workstation behaves as if it had been booted from a floppy disk.
It is worth noting at this point that there are two basic types of boot PROM: the older Novell Remote Boot PROMs and the more recent (since 1992) Enhanced Remote Boot PROMs. The former type are variously referred to as IPX PROMs, traditional PROMs, or Novell PROMs. The latter are referred to as RPL PROMs (RPL stands for remote program load), enhanced PROMs, IBM RPL PROMs, or FIND-FOUND PROMs. Both types carry out a similar function but in quite different ways. The differences in behavior are explained in context throughout relevant sections of this chapter.
This is an overview of the sequence of events which occurs when a diskless workstation boots from a file server:
Boot from Network (Y or N)?
NOTE: The server that the workstation is connected to after loading the workstation shell need not be the same server from which it received its boot image.
Boot PROMs can be a powerful management asset to many network managers, but they are not always appropriate. This section looks at the pros and cons.
Diskless workstations are particularly suited to environments where large numbers of similarly configured PCs are used or where users do not maintain the software on their own machine. Booting workstations from a file server has three major advantages over using floppy or local hard disks as boot media:
The next three sections examine these advantages.
Central Management. The simple task of upgrading a driver can be a logistical nightmare if that driver is used by a large number of client workstations. If the driver is stored on the hard disk of each client, you need to visit each workstation before making the change. If your users have their own boot floppy disks which they use to connect to the network, you are faced with the task of recalling and updating all boot floppy disks that are in circulation.
All startup files for diskless workstations are stored in a boot image file on the server, so you can manage them from any client that has access to that server. This gives you the luxury of being able to reconfigure the most remote workstation on the network without having to physically visit it.
Sharing Common Files. A number of workstations might have the same type of network adapter and load the same version of DOS, same network drivers, and same TSRs. Since all files required to boot a diskless workstation are stored on the file server, you can avoid maintaining duplicate sets of files by having all such workstations use the same boot image file. If the workstations need a new driver, you only need to update the boot image.
Write-Protection of Files. Using diskless workstations spares you the management overhead of all those local disks. Whether they're hard disk or floppy, conventional boot disks are prone to a range of disasters:
By storing the boot material in a safe, central place you can make good use of the security features of your network to protect your users from themselves and others.
NOTE: Diskless workstations are "read-only" in another sense: if a diskless workstation has no floppy drive, it cannot be used to download confidential data or to pirate software from your server. Likewise, it cannot be used to upload pirated software, viruses, or other undesirable material.
Diskless workstations are not for everyone. Some reasons for sticking with more conventional boot media are
User-Maintained Boot Configurations. Your users might prefer to manage the configuration of their own workstations. They might want the ability to experiment, or might not want to call you every time a minor amendment to CONFIG.SYS is required.
If so, you can consider installing both boot PROM and a hard disk. Users then would have the option at startup time of booting from the server (your configuration) or from the hard disk (their own). A choice of boot options can provide users the best of both worlds.
If you decide to go this route you should negotiate with users beforehand to ensure that you agree on where the responsibilities of each party begin and end. If you maintain the boot image but users consider you responsible when they mess up their own hard disk, you might find yourself with a doubled maintenance burden.
Cost of Boot PROMs. Boot PROMs cost money, but remember that the additional cost of a boot PROM in each workstation must be set against the cost of providing a hard disk or boot floppy disks to all users. You should also factor in the cost of the administrative overhead of updating local boot disks (either hard disk or floppy).
Dependence on the Server. If the server is down, diskless workstations will not boot. Of course, if applications are stored on the server, then users wouldn't be able to do anything even if they could boot up! In practice, with boot image files stored on multiple servers, this usually is not a problem.
Disk Space Overhead on the Server. If your client workstations use a wide variety of network adapters, then you may need to have several boot image files. Each can take up as much as 700K of disk space on the server. Besides reducing the amount of available free space on the server, a large number of boot image files can have implications for your backup system.
Adding an additional boot server does not affect the amount of disk space required on any one server, of course, as each server needs to hold its own copy of each boot image. Bear in mind, the total amount of disk space used by all servers for storing boot images increases proportionately with the number of boot servers.
Performance Overhead on the Server. Diskless workstations also have a performance hit on your server. The scale of the effect on performance depends on the number of diskless workstations, the number of servers supplying the boot images, and the frequency with which the workstations are booted. For example, in a student laboratory environment where a large number of workstations are booted regularly, the server has to send the boot image out on the network quite frequently. If the machines are all booted more or less on the hour, as is often the case, there may be intermittent but serious performance degradation on the server as dozens of machines clamor for boot images at the same time. In contrast, a small number of diskless workstations booted once or twice a day would have no noticeable impact on server performance.
Adding an additional boot server should give a proportionate decrease in the boot image load on each server. The total server resources given over to delivering boot images to the clients might increase slightly, however, as each server has to cache its own copy of the boot images.
Performance Overhead on the Network. There may also be a degradation in performance on the network between the server and the remote-booting clients. Those boot files need to travel to each client each time it boots, so frequent reboots can generate a lot of traffic that would not occur in the case of locally booted machines. The preceding comments about server performance overhead apply equally here: Large numbers of remote-booting clients rebooted simultaneously at regular intervals are likely to cause problems, while an occasional reboot will pass unnoticed.
Management Overhead. If you manage the boot configurations of a very small number of clients, or if your users are capable of configuring their own workstations, then it may be easier to deal with boot floppies or bootable hard disks than to set up boot image files.
In summary, you need to consider whether the advantages of central boot management are worth the overhead. Boot PROMs cost money and there is a disk space overhead on the file server. On the other hand, boot PROMs can save a lot of time and tedium in configuration maintenance for you and your users.
This section deals with planning and purchasing issues and describes how to set up a workstation to boot from a server.
NOTE: This process is closely linked to the workstation adapter installation and configuration. Refer to chapter 6, "The Workstation Platform," for detailed information on this topic.
The smaller the number of boot images you have to manage, the better. Each boot image can support only one MLID (ODI network driver), so it makes sense to stick with the same network adapter model as much as possible when buying new machines or upgrading existing ones.
That's not always practical of course, but you should at least bear in mind, when buying adapters that every new model you install on your network means another boot image file to maintain. As a minimum concern, make sure your servers have sufficient disk space to store all the necessary boot images and that your backup system can cope with the volume.
Make sure when ordering that you specify which type of PROM you require, the older IPX or the newer RPL. Unless you have a particular reason for wanting IPX PROMs, specify RPL.
If you're ordering a set of adapters and PROMs that you intend to manage as a set, using a single boot image, your order should clearly specify the make and model of the adapter and PROM. Two different models might not work with the same drivers or settings. Watch out also for motherboard differences that may prevent you from using the same interrupt or RAM address on all machines in your set--the boot image can only hold one copy of NET.CFG.
Finally, beware of buying into discontinued lines. You might not be able to find matching adapters or PROMs in the future, and if you have to replace any hardware, you might be forced to set up a whole new boot image, possibly for a single workstation out of dozens.
TIP: If you are installing diskless workstations for use in an unattended environment, consider buying adapters with a hardware jumper that can be set to disable software setup. This prevents users from innocently or maliciously reconfiguring the adapter to prevent it from booting.
Follow the manufacturer's instructions when installing a boot PROM. It is not uncommon, however, for PROMs to arrive without any documentation, so follow these general guidelines if you have nothing else to go on:
Once the boot PROM has been physically inserted, it must be configured for use. The boot PROM must be activated and configured to use a specific RAM area.
The procedure for enabling the boot PROM is different for every adapter model. Older adapter models such as the Novell NE1000 and NE2000 use physical jumper blocks. Remote reset jumper settings for Novell adapters are given in the Novell Ethernet Supplement shipped with all copies of NetWare.
More recent adapters that are partially or totally software configurable can be configured for remote boot by specifying a RAM address for the PROM using the adapter's setup utility. Even if you cannot obtain a copy of the adapter documentation, it is vital that you get a copy of the setup/configuration utility for the particular make and model of the adapter that you are using.
Don't rely too much on claims of compatibility: "NE2000 compatible" adapters may be fully software compatible with the NE2000 but may have a completely different physical layout, a different number of jumpers, or a software setup utility that was lost before the adapter reached you.
Boot PROM installation time is a good time to record the information you will need to configure and manage the diskless workstation. That's because most of the information concerns the adapter you have in your hands while installing the boot PROM.
Whatever data you decide to gather, record the information systematically. Use a database package to keep track of the information if you're dealing with many diskless workstations.
The data required is
Network Number and Adapter Network Address. The network number is required for creating the BOOTCONF.SYS file. You can find it on the BIND IPX line in the server's AUTOEXEC.NCF file.
The Ethernet address might be printed on the adapter, but if not, you should be able to determine it using the adapter's setup/diagnostic utility. Record the full, 12-digit Ethernet address in hexadecimal form. Separate pairs of digits with colons for clarity. 00:00:E8:C2:57:6E is easier to read than a string of digits (0000E8C2576E) and provides you less chance to accidentally drop a digit.
One way to find an RPL PROM's Ethernet address is to boot up the workstation that it is installed in, without connecting the workstation to the network. The Ethernet address will be displayed along with the adapter configuration details while the PROM waits in vain for an RPL server to respond.
TIP: If all other means fail, you can see the address of an adapter with an IPX boot PROM using the TRACK ON command at a server console. See details in the later instructions in the "Type of Boot PROM (IPX or RPL)" section.
Adapter Model and Configuration. The adapter model and configuration information should be at hand now since you've just used it to configure the adapter to use its boot PROM. Record the make, model, connector type, IRQ, I/O port, and RAM address.
Type of Boot PROM (IPX or RPL). Make sure you know which type of boot PROM you have just installed! This information is vital when preparing the boot image and the server. The RPL PROMs date from about 1992 onward and often are clearly labeled as RPL PROMs. Token-ring adapters always use RPL PROMs.
If you're still not sure whether the PROM is RPL or IPX, try the following:
Figure 28.1
This is a typical server TRACK screen.
Workstation's Physical Location. Take the time to write down enough information to help someone else locate this particular workstation. If there are bad packets coming from 00:00:E8:C2:57:6E and your data only tells you that the workstation with that adapter is one of 20 workstations in room 120, you have quite a bit of work to do to find the faulty machine. It's much more useful if your data tells you that it is "third PC on left, back row, room 120."
Workstation Model and Serial Number. Even the most detailed descriptions of physical location are of limited use if someone moves the workstations around. Take note of the workstation model and serial number so you can be sure that you have a correct match of Ethernet address and workstation.
Contact Name and Number. The name and number of a contact person can save a lot of time, especially if the diskless workstation is very remote. If you just want to know if PC X is booting up as usual, you can call someone who is close to it and can check quickly, thereby saving yourself a long trip.
This section explains how to prepare a boot image file for a DOS workstation.
Before you begin, decide which version of DOS the diskless workstation is using. Note that all the DOS external commands have to be stored on the server for access by the diskless workstation. Since DOS versions don't mix very well (for example, DOS 6's XCOPY won't run on a machine booted using DOS 5), each server needs to keep a separate copy of each version of DOS used by any diskless workstations that may connect. It makes sense, therefore, to keep the number of DOS versions to a minimum.
CAUTION: Check that you have enough DOS licenses to cover all diskless workstations! If you intend to use more than one DOS version, check that you have enough licenses for each version. DOS upgrades are not free.
You need the following to prepare the boot image file:
TIP: A laptop computer with PCMCIA network adapter, a range of transceivers, all the necessary network drivers, and your favorite diagnostic utilities is particularly useful when you're setting up and testing remote booting workstations.
Finally, if the diskless workstation has an IPX boot PROM, you need a copy of RPLODI.COM. This is because IPX boot PROMs were designed to work with older, dedicated IPX drivers, rather than ODI drivers. They communicate with the server using dedicated IPX code, which is fine as long as the adapter loads a dedicated IPX driver from the boot image. If an ODI driver is loaded instead, the ODI code interferes with the boot PROM's IPX code, meaning that the PROM can read no more of the boot image. The error message
Error reading boot disk image file
appears on-screen and the workstation hangs. RPLODI.COM fixes this problem by looking after the hand-over from the PROM's IPX code to the boot image's MLID.
NOTE: RPLODI.COM is needed only for IPX boot PROMs, not for RPL boot PROMs.
TIP: You occasionally might have to replace an IPX PROM with an RPL PROM. If the workstation's boot image still loads RPLODI.COM, your users will see an error message and hear an irritating beep when RPLODI.COM discovers that the workstation on which it is being run has not been booted using an IPX PROM. If the boot image is not still used by IPX PROM workstations, simply remove the RPLODI.COM load line from the boot image's AUTOEXEC.BAT. If, however, there are still IPX workstations which use the boot image, you don't have to create a whole new boot image for this single workstation. Edit the AUTOEXEC.BAT to redirect RPLODI.COM's output to NUL, withRPLODI > NULThis stops RPLODI.COM from beeping and displaying its error message on-screen. RPLODI.COM continues to do its job for IPX PROMs but quietly ignores RPL PROMs.
Use the following sections to prepare the master boot floppy that the boot image will be built from.
Boot a Master PC. Boot a PC that uses whatever version of DOS you want the diskless workstation to use.
Format the Master Boot Floppy. Format a floppy disk using the /S option (DOS) or choosing Disk, Make System Disk in Windows File Manager. The floppy disk then contains a boot sector, two hidden system files, and COMMAND.COM. This disk is to be your master boot disk, so be careful with it. Label it clearly with the identity of the diskless machine, the date created, the DOS version used, and the type of Ethernet adapter.
Copy Files to the Floppy. Copy all other required files to the master boot disk. Remember that you need to include all files used when booting, up to the point where the adapter's driver is loaded.
In particular, make sure you have the following:
TIP: EMM386.EXE "remembers" the path with which it was loaded so that it can reload at a later stage. If it is loaded during a remote boot, the path is A:\. This can cause problems when, for example, a remote-booted workstation tries to load Windows--it looks for EMM386.EXE on drive A but the file is not there any more. To avoid errors, use the /Y switch to specify the full path to a copy of EMM386.EXE after logon. For example, you might use
DEVICE=EMM386.EXE /NOEMS /Y=F:\WINDOWS\EMM386.EXE /X=D000-D800
lsl rplodi ne2000 ipxodi vlm
NOTE: If your copy of DOSGEN is version 1.2 or later, then you can store some of these files in subdirectories. If it's older, leave everything in the root directory of drive A because older versions of DOSGEN don't support subdirectories.
Copy Files to the Server. If this is the only boot image you will have on the server, copy AUTOEXEC.BAT to the SYS:LOGIN directory. See the later "Multiple Boot Images" section if you expect to have more than one boot image.
Any programs run from AUTOEXEC.BAT after the point where the workstation shell is loaded should also be copied to SYS:LOGIN. This might include mouse drivers, menu programs, and so on.
Switching to the Server. The boot PROM shuts down once the workstation shell is loaded during remote boot. Its job is done--the PC has found a boot device, loaded an operating system and network drivers, and connected to a server. At this point--when NETX.EXE or VLM.EXE loads--the diskless workstation switches from reading a batch file in the boot image to reading a batch file of the same name in the SYS:LOGIN directory of the file server.
It does this by keeping track of its position in the batch file as it processes the boot image. This position is recorded as a byte offset amount from the start of the batch file. When control is handed over to the SYS:LOGIN batch file, processing begins at the byte offset position.
As long as the contents of the two batch files are identical, the use of the byte offset ensures a smooth transition from boot image to logon area. If the copies are not identical, the byte offset might point to the wrong location in the second batch file and strange results might occur. Consider these two batch files:
Boot image copy of AUTOEXEC.BAT
lsl smc8000 ipxodi netx mouse
SYS:LOGIN copy of AUTOEXEC.BAT:
lsl ne2000 ipxodi netx mouse
The only difference is that the first contains smc8000 where the second contains ne2000--the latter is one character shorter. The byte offset calculated for the first file is therefore too great for the second file, which will start processing after the m in mouse; the first command executed will be ouse, probably resulting in an error.
That's what can happen with a one-character offset difference. If one file contains entire lines that the other file does not contain, the likelihood of error is much greater. The second batch file might try to load network drivers that are already in memory or that clash with software already in memory. That the workstation might hang is a possibility.
Multiple Boot Images. The byte offset mechanism can give rise to difficulties with multiple boot images. Each boot image insists on using its own byte offset when passing control to SYS:LOGIN. If the workstation shell has been loaded from AUTOEXEC.BAT, this can mean different byte offsets being used on the same AUTOEXEC.BAT file--after all, there can only be one copy of this in any one directory.
There are various tricks that allow you to work around this to some extent, such as renaming all MLIDs so that they are exactly the same length. These tricks are based on the fact that, strictly speaking, the files need not have identical content as long as the byte offset after loading the workstation shell ends up at the correct value. Trying to maintain files this way, though, is bound to cause problems.
There is an easier approach--don't load the workstation shell from AUTOEXEC.BAT. Instead, rename the AUTOEXEC.BAT for each workstation using a name matching the boot image name. Then create a dummy AUTOEXEC.BAT that calls this surrogate AUTOEXEC.BAT. As long as each surrogate is uniquely named, you can maintain a copy of each in SYS:LOGIN. Then you just need to make sure that the surrogate batch file in SYS:LOGIN is an exact copy of the surrogate in the corresponding boot image.
For example, given two batch files named NE2$DOS.SYS and SMC$DOS.SYS:
NE2AUTO
SMCAUTO
You then can maintain the two boot images and their surrogate AUTOEXEC files independently from one another. The AUTOEXEC.BAT files in the boot images remain there--no AUTOEXEC.BAT is required in SYS:LOGIN unless it is used by another boot image.
TIP: Adopt this procedure even if you are creating only one boot image. It takes little or no effort, and greatly simplifies the process of adding more boot images later if that becomes necessary.
Test the boot disk now by using it to boot the target workstation. Don't skip this step! You need to test the exact set of files on the disk--that CONFIG.SYS, those particular NET.CFG entries, the versions of the network drivers--on the workstation or workstations that will actually use the boot image. Don't assume that because a boot floppy disk works properly on one machine, it will work on another. Even if both have the same type of Ethernet adapter, you might have difficulties with differences between model revisions or clashes with other adapters that were not present in the first workstation.
If you have loaded RPLODI.COM, expect an error message when you boot the diskless workstation using the master boot floppy. RPLODI.COM looks for a stamp left in memory by the boot PROM's IPX code. As you're booting from a floppy disk, the boot PROM code is not present, so RPLODI.COM beeps and displays an error message: FATAL: BootROM Stamp not found. This message should appear only when the workstation boots from the master boot disk, not when it boots from the file server.
This procedure copies the contents of the master boot disk to a boot image file on the server.
The default name for a DOS boot image file is NET$DOS.SYS. You need a separate boot image for each boot configuration--generally speaking, one boot image for each adapter model--so choose an appropriate name for each boot image. Names such as ACC$DOS.SYS, SMC$DOS.SYS are better than NET1$DOS.SYS and NET2$DOS.SYS. (The xxx$DOS.SYS naming convention is not essential but it makes the function of these files obvious.) The section later named "BOOTCONF.SYS" explains how to make each workstation pick up the correct boot image.
DOSGEN. DOSGEN is a NetWare utility that reads the contents of your master boot floppy and transfers them to the special container file which is a boot image. It reads the floppy's boot sector and File Allocation Table, as well as the files you copied onto the floppy.
The syntax for DOSGEN is
[path]DOSGEN drive: [imagefile]
where path specifies the directory path to DOSGEN, drive is the drive with the master boot floppy, and imagefile specifies the image file to be created.
The default drive is A: and the default image file name is NET$DOS.SYS.
You usually need to map a drive letter to SYS:SYSTEM to pick up DOSGEN and another to SYS:LOGIN so that you can specify the destination for the boot image. Figure 28.2 illustrates a typical sequence of commands issued when using DOSGEN.
Figure 28.2
This is a typical use of DOSGEN.
NOTE: If you have version 1.2 or later of DOSGEN, the directory structure of your master boot floppy is copied to the boot image along with any files in subdirectories. Earlier versions of DOSGEN complain about subdirectories on the master boot disk by beeping and displaying an error message (...Not supported) beside the name of the subdirectory.
RPLFIX.COM IPX boot PROMs need a little help to work with DOS version 5 or later. This is because DOS 5's COMMAND.COM is much bigger than COMMAND.COM in earlier versions of DOS. Here's the sequence of events without RPLFIX:
RPLFIX modifies the boot image file so that COMMAND.COM does not overwrite the boot PROM code while it is still active in memory.
The syntax for RPLFIX.COM is
RPLFIX imagefile
where imagefile is the name of the boot image file to be patched, including the path if the file is not in the current directory.
RPLFIX should report that the image file has been successfully modified. For example,
C:\> G:RPLFIX F:SMC$DOS.SYS
NetWare Boot Disk Image Patch Program v1.03 (930630)
(c) Copyright 1991, 1993 by Novell, Inc. All rights reserved.
This program fixes Boot disk image files for:
MS-DOS 5.xx, 6.xx, and DR-DOS 6.xx
Boot disk image file has been modified
RPLFIX needs to be run only once on a given boot image file. If you run RPLFIX on an image that has already been RPLFIXed, RPLFIX tells you so and won't modify the image again.
If you run DOSGEN again to regenerate the boot image file for any reason, you should run RPLFIX on the new image.
NOTE: RPLFIX.COM is only for DOS version 5.0 or later, and only for IPX boot PROMs. RPL PROM code is not overwritten by COMMAND.COM as it loads, so RPL PROMs do not require this fix.
Finally, make sure the boot image file is properly accessible by the diskless workstations. It must be
FLAG F:SMC$DOS.SYS S
NOTE: For the same reason, you should flag as shareable any of these files which are in SYS:LOGIN: BOOTCONF.SYS, AUTOEXEC.BAT and any batch files called by the boot image's AUTOEXEC.BAT in a situation with multiple boot images.
A server must be correctly configured if it is to deliver boot images to diskless clients. This section looks at configuration issues for both types of boot PROMs.
NOTE: Many different types of computers can act as an RPL server: NetWare file servers, UNIX machines, Windows NT Servers, even Personal NetWare clients. Because NetWare servers are by far the most common, this section will cover NetWare server RPL configuration issues only.
All boot files must be stored in the logon area, SYS:LOGIN. This is the only area on the server accessible by NOT-LOGGED-IN connections.
The following files should be in SYS:LOGIN:
| Network Adapter Type | File |
| IBM MCA Ethernet | ETHER.RPL |
| IBM Model 25SX Ethernet | F1ETHER.RPL |
| IBM PC Baseband Network | PCN2L.RPL |
| Adapters using Enhanced Boot PROMs | RBOOT.RPL |
| IBM Shared RAM Token Ring | TOKEN.RPL |
Flag each of these files as shareable (the process is described in the earlier "Putting the Boot Image in Its Place" section). This allows more than one remote booting workstation at a time to use them.
Do not flag these files as read-only because that would make it awkward to update them. (A read-only flag is of no real benefit as a security measure unless your logged on users have write access to SYS:LOGIN.)
The default file name for DOS boot images is NET$DOS.SYS. If all diskless workstations on your network have the same boot configuration (in practice, the same network adapter model and settings), only one boot image is required and you do not need to create a BOOTCONF.SYS file.
If you have more than one boot image, the diskless workstations need to determine which one they should use when booting. That's what BOOTCONF.SYS is for. It is a text file with a one-line entry for each diskless workstation, indicating which boot image it should use.
The basic syntax for a BOOTCONF.SYS entry is
0xnetwork,address=bootimage
where network is the server's IPX external network number in eight-digit hexadecimal form, address is the 12-digit address of the workstation's Ethernet adapter, and bootimage is the name of the boot image to be used by that workstation.
Create BOOTCONF.SYS with a text editor. Use the notes you took when installing the boot PROMs to ensure a full list of Ethernet addresses and to match each address with the correct boot image. Meaningful boot image names are particularly useful at this point.
For example, assume that network 8C87 has three diskless workstations. The boot images are SMC$DOS.SYS for SMC8000 adapters and NE2$DOS.SYS for NE2000 adapters. The adapters are
BOOTCONF.SYS:
0x00008c87,08006737e8f4=smc$dos.sys 0x00008c87,0000e8c2576e=ne2$dos.sys 0x00008c87,08006737e8a2=smc$dos.sys
Here's some further explanation of the BOOTCONF.SYS entries:
Gerry's PC: 0x00008c87,08006737e8f4=smc$dos.sys Print servers: 0x00008c87,0000e8c2576e=ne2$dos.sys 0x00008c87,08006737e8a2=smc$dos.sys
NOTE: Bear in mind when adding comment lines that they make BOOTCONF.SYS longer. This means slower parsing and, in the case of IPX PROMs, more network traffic. This is unlikely to be noticeable, however, especially if the number of diskless workstations is on the order of dozens rather than hundreds.
This section covered the basic syntax for BOOTCONF.SYS. Everything mentioned previously applies to both IPX and RPL PROMs. See the "BOOTCONF.SYS RPL Enhancements" section later for details of some extra features available when using RPL PROMs.
IPX PROMs look for their boot image file in the LOGIN area of the server that they first attach to:
Make sure that all servers with the boot images are configured to respond to GNS requests. This is the default behavior, but you can turn it on explicitly using the SET command at the server console:
SET REPLY TO GET NEAREST SERVER = ON
Servers without boot images should not respond to GNS requests. If they do, workstations will attempt to download boot images from them and will hang, resulting in an error message. You can use the console to explicitly turn off a server's ability to reply to GNS requests. Enter the following in the AUTOEXEC.NCF of all non-boot servers on the network:
SET REPLY TO GET NEAREST SERVER = OFF
RPL PROMs need an RPL server on the network. This is either a NetWare server running RPL.NLM or, in the case of Personal NetWare, a client workstation running RPL.COM. It may or may not have copies of the boot image files.
The following sequence of events illustrates how an RPL PROM finds its boot image. It is a typical rather than a definitive description because the default behavior of an RPL server may be overridden in many ways. The features of an RPL server and the enhanced syntax of BOOTCONF.SYS for RPL PROMs are explained in detail in the "BOOTCONF.SYS RPL Enhancements" section later in this chapter.
An RPL PROM typically finds its boot image file in the LOGIN area of a file server as follows:
The behavior of RPL servers may be configured in two ways:
Together, these options give system administrators the ability to customize remote boot activity for the whole network--or for individual machines--in a variety of ways not possible with IPX PROMs. The following sections look at each in turn.
RPL.NLM. An RPL server is usually a NetWare server running RPL.NLM. RPL.NLM provides diskless workstations on the network with the information they require to locate their boot images. It may also instruct them to download the boot image in a non- default way. A NetWare server running RPL.NLM may also provide boot images to clients or may direct clients to look for boot images on other servers.
Load RPL.NLM on the server using the LOAD console command, bind it to any network adapter in the server that is using the Ethernet 802.2 frame type. For example,
LOAD NE3200 SLOT=3 NAME=ipx_drv FRAME=ETHERNET_802.3 BIND IPX TO ipx_drv NET=8C87 LOAD NE3200 SLOT=3 NAME=rpl_drv FRAME=ETHERNET_802.2 BIND IPX TO rpl_drv NET=8C8B LOAD RPL BIND RPL TO RPL_DRV
That is enough to provide the default behavior. Set up the boot image or images as described earlier with a BOOTCONF.SYS if there is more than one boot image.
RPL BIND Parameters. The flexibility of RPL.NLM is achieved through a range of optional parameters used at BIND time. These parameters are summarized in table 28.2.
| Parameter | Values | Default |
| ACK | No | |
| FRAME | Ethernet_802.2 Ethernet_II Ethernet_SNAP | Ethernet_802.2 |
| GNS | No | |
| NODEFAULT | No | |
| PROTECT | No | |
| PS | Server | Boot Server |
| WAIT TIME | 0-65535 | 0 |
These parameters are explained further in the following sections.
ACK. The RPL server normally sends the FILE.DATA.RESPONSE in packet burst mode. If this causes problems for your boot PROM--if the PROM cannot keep pace with the server--use the ACK parameter to slow things down. The RPL server waits for the boot PROM to acknowledge receipt of each FILE.DATA.RESPONSE frame as it is sent. Use this parameter only if you suspect communications difficulties with RPL PROMs.
FRAME. The bootstrap program will use the Ethernet 802.2 frame type unless instructed otherwise. If either EII or SNAP is specified, the bootstrap program sends a GNS frame on the network to find a server to search for a boot image.
GNS. Forces the workstation to use a GNS request to find a server to search for a boot image. You might want to use this to provide boot server redundancy--see the "Considerations with Multiple Servers" section later for more information. The default is to search the server specified in the bootstrap program.
NODEFAULT. By default, the RPL server responds to any FIND frame that comes its way. If the NODEFAULT parameter is used, the server only sends a FOUND frame if the workstation's Ethernet address is found in BOOTCONF.SYS. This means that the workstation won't even start to boot unless an entry for it is added to BOOTCONF.SYS.
PROTECT. If you suspect that the bootstrap program is being overwritten in memory by another program during the boot process, use this parameter to make the bootstrap program "claim" the memory it occupies.
CAUTION: Use this parameter only as a last resort. The memory thus claimed is not freed up after the workstation finishes booting, so the amount of conventional memory available might be reduced by as much as 60K.
PS. The bootstrap program will look for the boot image on the server which is running RPL.NLM unless instructed otherwise using this parameter. Use this parameter if you want to have separate RPL and boot image servers.
WAIT TIME. The RPL enhancements to BOOTCONF.SYS (see "BOOTCONF.SYS RPL Enhancements" later for details) allow you to specify multiple boot images for a single workstation, giving users the choice at boot time of which image file to use. As explained in the later "Multiple Boot Images" section, they are presented with a list of boot image names and invited to select one. The default behavior is for the workstation to wait indefinitely for the user to choose an image.
The WAIT TIME option can be used to force the automatic selection of an image if the user has not selected one after a given length of time. The value is expressed in seconds. The default value is 0, meaning that no automatic selection will take place.
Here's an example of how to use this parameter:
BIND RPL TO RPL_DRV WAIT TIME=5
RPL BIND Parameter Overrides. Many of RPL.NLM's optional BIND parameters can be overridden for specific workstations or groups of workstations by additions to the relevant workstation lines in BOOTCONF.SYS. This gives finer control over remote booting than setting parameters either for all workstations or for none. The parameters that can be overridden are listed in table 28.3 and are explained in the sections that follow.
Use these overrides if you have used an RPL BIND parameter that you do not want to apply to all diskless workstations or if you want to experiment with RPL BIND parameters on some workstations without affecting others.
| Override | Default |
| NOACK | ACK |
| NOGNS | GNS |
| NOPROTECT | PROTECT |
| REP string1|string2 | None |
NOACK. Turns off the ACK BIND time parameter for the specified workstation. The RPL server will not wait for this workstation to acknowledge each FILE.DATA.RESPONSE frame.
NOGNS. Turns off the GNS BIND time parameter for the specified workstation. This workstation will not send a GNS frame to locate a server from which to download its boot image.
NOPROTECT. Turns off the PROTECT BIND time parameter for the specified workstation. The bootstrap program will not protect itself in the workstation's memory, and available conventional memory will not be reduced.
REP. This is a global replace function for an entire boot image. The text strings must be ASCII text, separated by a vertical bar (|). The replacement string cannot be longer than the original. If it is shorter, it is filled out with space characters to the length of the string being replaced.
This replacement function is case-sensitive. For example, the effect of REP horse|cow on A HORSE is a Horse is a horse is to change it to A HORSE is a Horse is a cow REP is a powerful feature. It can be used, for example, to set an environment variable to different values on different workstations:
0x00008c87,0000e8c2576e=ne2$dos.sys REP GO32VAR|C:\TMP
and
0x00008c87,0000e8c248f5=ne2$dos.sys REP GO32VAR|D:\
If the AUTOEXEC.BAT for NE2$DOS.SYS contains the line
SET GO32=GO32VAR
GO32 is set to C:\TMP on the first workstation and D:\ on the second.
Watch out for the padding spaces if you replace existing strings with a shorter string. Suppose that you want AUTOEXEC.BAT to run a program MYPROG using the line
PROGDIR\MYPROG
where the directory path PROGDIR varies from one workstation to another. REP can cause problems here because
REP PROGDIR|C:\BIN
will replace the line in AUTOEXEC.BAT with
C:\BIN \MYPROG
resulting in an error.
In cases like this, you can replace the entire string. In AUTOEXEC.BAT, include the line
MYPROGFULLPATH
and at the end of the workstation line in BOOTCONF.SYS, use
REP MYPROGFULLPATH|C:\BIN\MYPROG
TIP: The REP parameter is particularly useful when used with the BOOTCONF.SYS extensions that allow for the use of wild cards in Ethernet addresses. For example, REP can be used to replace strings with different values for different makes of card.
The RPL Server and BOOTCONF.SYS. The RPL server usually caches the contents of BOOTCONF.SYS in memory so that it, and not the boot PROM, can parse it. This saves the PROM from having to download all of BOOTCONF.SYS, which might be quite large, to find a few bytes of information. However, if BOOTCONF.SYS is too large for the RPL server to hold in memory, the RPL server does not store it--the PROM must download it and parse it itself. Every 100 entries in BOOTCONF.SYS takes only 5K or so of RAM, so this is unlikely to be a problem on a NetWare server.
BOOTCONF.SYS RPL Enhancements. RPL behavior can be customized for specific workstations or groups of workstations using extensions to the BOOTCONF.SYS syntax.
NOTE: Do not use the enhancements in this section for IPX PROMs--they are valid only for RPL PROMs. The effect on IPX PROMs would be the same as having a corrupt BOOTCONF.SYS file. The most likely result is that they will either attempt to boot from a non-existent file or, if they fail to find their address in the file, try to boot using the default boot image file name, NET$DOS.SYS. If the former happens or the latter in cases where NET$DOS.SYS does not exist, the workstation will hang with an Error opening boot disk image file message.
RPL PROMs can take advantage of three major improvements to the BOOTCONF.SYS syntax:
Wild Cards. Most BOOTCONF.SYS files contain a lot of repeated information. A batch of NE2000 adapters, for example, will have Ethernet addresses with the first several digits in common. If they all use the same RPL BIND override parameters--or no parameters--then you can save a lot of typing by using wild cards.
The valid wild-card characters are the asterisk and the question mark. The asterisk masks a range of characters, and the question mark masks a single character.
For example, a group of entries like
0x00008c87,0000e8c2576e=ne2$dos.sys 0x00008c87,0000e8c25602=ne2$dos.sys 0x00008c87,0000e8c2570b=ne2$dos.sys 0x00008c87,0000e8c257f4=ne2$dos.sys 0x00008c87,0000e8c24e71=ne2$dos.sys
can be replaced with either
0x00008c87,0000e8c2*=ne2$dos.sys
or
0x00008c87,0000e8c2????=ne2$dos.sys
NOTE: BOOTCONF.SYS is only scanned for a given Ethernet address until a match is found. This means that lines specific to one adapter should be placed near the top of the file, lines for groups of adapters later in the file, and any line intended to apply to adapters not matched by those lines should go at the end of BOOTCONF.SYS.
Multiple Boot Images. One of the disadvantages of boot images is that they encapsulate a single, fixed boot configuration. This cannot be optimal for all users and all applications. For example, one application might require that EMM386.EXE be loaded at boot time, but another application might not run at all if EMM386.EXE has been loaded.
The ability to specify more than one boot image file per workstation offers a solution to some of these difficulties, while maintaining all the benefits of centrally-managed boot configurations. One boot image has a CONFIG.SYS that loads EMM386.EXE, and the second does not; the user chooses between the boot images at boot time, and the workstation loads EMM386.EXE or not, as appropriate.
Multiple boot images are specified in BOOTCONF.SYS by listing after an equal sign the names of all boot images for a given workstation, separated by spaces. For example,
0x00008c87,0000e8c2576e=ne2$dos.sys ne2noemm.sys
gives the user at address 00:00:e8:c2:57:6e a choice between two boot images at boot time (see fig. 28.3).
Figure 28.3
This is the workstation screen with a choice of boot images.
The first file name is highlighted. The user can select the other file name by using the cursor keys. When the user presses Enter, the bootstrap program downloads the selected boot image.
You can use this feature with a wild card to offer a choice of boot images as the default. If the last line in BOOTCONF.SYS is
0x*=ne1$dos.sys ne2$dos.sys smc$dos.sys 3com$dos.sys
any workstation that does not have an entry earlier in the file will present the user with the names of the four images listed on this line and allow them to choose which one the workstation boots with.
Multiple Lines. Finally, the ability to override RPL BIND parameters and to specify multiple boot images can lead to very long lines that are difficult to edit. The introduction of the continuation character was therefore necessary.
Place a space and a colon at the end of a line in BOOTCONF.SYS to force RPL.NLM to treat the next line as a continuation of the current line. For example,
0x00008c87,0000e8c2576e=ne2$dos.sys ne2noemm.sys : PROTECT ACK REP TMPDIR|C:\
DOS is more than a boot sector and command interpreter. There is also the matter of dozens of so-called external commands such as XCOPY and MODE that are not built into COMMAND.COM but live as independent programs in a directory of their own. This section describes how to make such commands available to users of diskless workstations.
DOS Directories. A DOS workstation with a hard disk generally stores the programs in C:\DOS and has this directory in its DOS search path. A remote booting workstation with a local hard disk can also do this, of course--just make sure that the programs stored in the local DOS directory are from the same version of DOS that the workstation uses to boot.
A workstation with no local disk must rely on the server to store the DOS program files. If all workstations use the same version of DOS, this is very simple to organize:
MAP G:=SYS:PUBLIC MD G:DOS
COPY C:\DOS\*.* G:DOS
MAP INS S1:=SYS:PUBLIC\DOS The users then have access to all DOS commands, just as if the DOS program files were stored on a local hard disk.
The process is rarely that simple, though. It might not be possible to insist that all diskless workstations use the same DOS version--for example, old applications might not work under newer DOS versions. New applications might require a more recent version of DOS than the one currently installed on the server, but you might not want to upgrade DOS on all the workstations for other reasons. In short, you probably should bank on having multiple DOS versions on the server at the same time.
Creating several DOS directories is simple, but how can you guarantee that each workstation gets a search mapping to the correct DOS version? Remember that mappings are created at or after logon time, so you cannot configure them in the boot image.
The answer lies in some obscure logon script variables provided by Novell. As long as you name the DOS directories according to Novell's conventions, these variables allow you to use a single MAP statement in the system logon script to map to the correct DOS directory, no matter which version of DOS the workstation is running. Table 28.4 lists the relevant variables.
| Variable | Meaning |
| MACHINE | Workstation Type |
| OS | Type of DOS on the Workstation |
| OS_VERSION | Version of DOS on the Workstation |
In most cases the only variables needed are OS_VERSION and OS. If all your diskless workstations are using MS-DOS, then only the OS_VERSION variable is required. The MACHINE variable should be needed only if one or more diskless workstations are not 100% IBM-compatible.
A typical system logon script entry for mapping the DOS directory appears as follows:
MAP INS S1:=SYS:PUBLIC/%OS/%OS_VERSION
On a workstation booted using version 5.00 of MS-DOS, this line is interpreted as
MAP INS S1:=SYS:PUBLIC/MSDOS/5.00
Plan your DOS directory structure accordingly. The simplest system is to create a SYS:PUBLIC/MSDOS directory with subdirectories named 3.30, 5.00, 6.00, 6.20, and so on, as necessary.
Setting COMSPEC. DOS sometimes needs to reload its command interpreter; for this reason, it stores the command interpreter's location in an environment variable named COMSPEC. When a diskless workstation boots up, COMSPEC is set to A:\COMMAND.COM. You must change this value to point to a copy of COMMAND.COM (of the correct DOS version) as a user logs on because A:\COMMAND.COM will cease to exist.
There should be a copy of COMMAND.COM in the relevant DOS directory in SYS:PUBLIC, but you have no way of telling which drive letter will be mapped to that directory for a given logon. The drive letter used will be decided only when the MAP INS command is executed.
COMSPEC is best set in the system logon script immediately after the DOS directory search mapping is created. At that point, you can be certain that the first search mapping is S1, regardless of its DOS drive letter. If you get LOGIN.EXE to resolve S1, then the problem is solved. For example,
MAP INS S1:=SYS:PUBLIC/%OS/%OS_VERSION COMSPEC=S1:COMMAND.COM
NOTE: Many programs overwrite the transient portion of COMMAND.COM when they execute, forcing the PC to reload it from disk when the program terminates. It is essential that COMSPEC is set before this situation arises, so apply the previous solution as early as possible in the system logon script.
Restricting to Diskless Workstations. Adding a search mapping to the DOS directory and resetting COMSPEC are necessary for diskless workstations to function but might interfere with normal operation on workstations with a local copy of DOS. You might find that you need to restrict these logon script entries to diskless workstations only.
One way to do this is to set an environment variable to any value in the AUTOEXEC.BAT file of any remote booting workstations, for example,
SET REMOTEBOOT=Y
The system logon script can then check this variable and pick up DOS from the server or not depending on whether it has been set:
; Pick up DOS for remote booting clients only: if not %<REMOTEBOOT>.=. then begin map ins s1:=sys:public\%os\%os_version comspec=s1:command.com end
If you have a single server on your network, it must act as an RPL server (if using RPL PROMs) and as a source for boot images for all diskless workstations. This section discusses issues that might arise if you have more than one server and details some extra configuration steps that might be necessary.
Choosing the Number of RPL and Boot Servers. RPL.NLM does not place an appreciable load on a server, so in the normal course of events, one RPL server should be sufficient for any network. If the server running RPL.NLM happens to crash, however, no diskless workstations with RPL PROMs can boot. It is therefore desirable to have at least one additional RPL server on the network as a backup.
The same redundancy argument holds for servers carrying the boot images. If one server goes down, the diskless workstations still will be able to boot up. Unlike with RPL servers, there might be a performance payoff in replicating boot image servers; on the other hand, there will be a cost in server disk space. Weigh the pros and cons carefully before deciding on the number of boot servers to use.
It's important to remember to keep the configuration of multiple RPL and boot servers properly synchronized. If you change the BIND RPL line on one server but not on the other or a boot image on some servers but not on others, remote-booting clients may experience erratic behavior or intermittent faults.
It is worth spending some time developing automatic or semi-automatic procedures for synchronizing BOOTCONF.SYS, boot image files, and the surrogate AUTOEXEC.BAT files across servers. The simplest approach is to write a series of custom batch files that use the NCOPY command to copy updated files from one server to the others. More elaborate approaches involve mirroring the relevant files from server to server. Once such procedures are developed, the administrative overhead of adding another boot image server is minimal.
GET NEAREST SERVER Requests. Make sure that servers without boot images do not respond to GNS requests from boot PROMs. If they do, the PROMs will look for BOOTCONF.SYS and boot image files where they don't exist, and workstations will hang when they try to boot. Turn off the server's capability to respond to GNS requests at the console.
The following command should be entered in the server's AUTOEXEC.NCF to ensure that the setting is still in place after the server reboots:
SET REPLY TO GET NEAREST SERVER = OFF
This is a trivial matter if you have management authority over all servers on your network. If not, though, it is essential that you secure the cooperation of the managers of the other servers in setting this parameter on your behalf. If they are reluctant to do this, point out to them that each diskless workstation that gets a response to a GNS frame from their server will take up a connection on that server.
Don't be put off from boot PROMs if the instructions so far seem hopelessly convoluted. In normal use, boot PROMs operate quietly, efficiently, and reliably. The work required to configure them is more than repaid by years of trouble-free booting and by the ability to reconfigure any number of workstations across the network without leaving your seat.
You might run into difficulties in the early stages, of course, and again from time to time as network or hardware trouble arises. This section covers some pitfalls to avoid and some error messages that you might see.
Knowing what to expect in a working setup can help when you're trying to diagnose initial problems.
IPX PROMs generally just display a copyright message and version number on-screen before DOS starts to load. This PROM information may or may not remain on-screen until scrolled off the top as DOS loads--some brands clear the information from the screen as soon as contact is made with the server. Some IPX PROM brands are quite informative, displaying information messages as they contact a server, open BOOTCONF.SYS, search for the boot image, and so on.
RPL PROMs are quite verbose by comparison. A typical PROM startup screen displays the adapter Ethernet address, adapter settings, and the number of FIND frames sent. Figure 28.4 shows a typical example.
This screen is usually visible for only an instant. Once the RPL server responds, the screen is cleared and the RPL bootstrap program displays its version and copyright information at the top of the screen. This remains visible while DOS starts, until it is scrolled off the top of the screen.
First of all, make sure that the diskless workstation can boot properly from the master boot floppy. The problem may be as simple as a typographical error in a batch file or a missing driver file. If the workstation has no floppy drive, you have to assume that the master boot floppy is valid for the workstation until you discover otherwise.
Figure 28.4
This is the workstation screen during RPL PROM startup.
Testing with the boot floppy can also reveal network or cabling problems. If the workstation can't connect to the server when booted from a floppy, it certainly won't be able to do so using a boot PROM.
Check also that the boot PROM version information is displayed on-screen when the workstation is powered on. If not, the PROM has not been properly installed and you need to repeat the installation process before you try again.
In short, make sure that the problem is related to the remote boot process before proceeding with this section.
Bear in mind the following when debugging remote boot problems:
The next sections cover errors that may arise during three separate stages:
Errors covered in this category occur after the PROM code starts to execute but before the workstation starts to download its boot image.
RPL PROMs Only. The following sections deal with aspects of this class of problems specific to RPL PROMs.
No RPL Server Response. If no RPL server responds to an RPL PROM, the PROM's startup information as illustrated above remains on-screen as the PROM continues to send FIND frames. The FIND frame count at the bottom increases by one every couple of seconds until an RPL server responds with a FOUND frame:
RPL-ROM-FFC: 2
Determine why the RPL server is not responding:
RPL: No Boot Server. The RPL PROM startup information is cleared from the screen as soon as the RPL bootstrap program starts. The bootstrap program attempts to connect to the file server where the boot image is stored. If it fails to do so within a few seconds, it hangs and offers you this message:
RBOOT-RPL-100: Unable to CONNECT to File Server; RPL HALTED
Establish why the boot server is not responding:
RPL: No Boot Image. If the bootstrap program connects to a file server but cannot locate the designated boot image--NET$DOS.SYS or the file specified in BOOTCONF.SYS--it reports an error:
RBOOT-RPL-104: Unable to OPEN NET$DOS.SYS; RPL HALTED
If multiple boot images are specified in BOOTCONF.SYS, and if the selected file cannot be opened, the error message is slightly different. RPL does not halt but instead asks the user to select a boot image again:
RBOOT-RPL-104: Unable to OPEN NET$DOS.SYS RBOOT-RPL-106: Place CURSOR on DISK IMAGE file: Hit ENTER when Ready:
In either case, determine why the boot server cannot locate this workstation's boot image:
IPX PROMs Only. The following sections deal with aspects of this class of problems specific to IPX PROMs.
IPX: No Boot Server. If no server responds to the GNS request within a few seconds, an IPX PROM displays an error message: Error finding server.
Establish why the workstation is not able to get a response from the server:
IPX: No Boot Image. If the PROM gets a FOUND GET NEAREST SERVER frame from a server but cannot find its boot image on that server, it hangs and gives you the following message: Error opening boot disk image file.
Determine why the boot server cannot provide the workstation with its boot image:
Errors covered in this category occur while the boot image file is being downloaded.
RPL PROMs Only. The next section deals with aspects of this class of problems specific to RPL PROMs.
RPL: HIMEM.SYS Error. Some versions of HIMEM.SYS perform a comprehensive memory test as they load. Among other things, the test writes to memory areas and then reads back from the same areas to see if the write was successful. The bootstrap program can cause this test to fail, resulting in this message:
ERROR: HIMEM.SYS has detected unreliable XMS memory at address 00800000h. XMS Driver not installed.
Extended memory will not be enabled.
Instruct DOS not to carry out this test at boot time. Turn off HIMEM testing in the CONFIG.SYS with the following:
DEVICE=HIMEM.SYS /TESTMEM:OFF
IPX PROMs Only. The following sections deal with aspects of this class of problems specific to IPX PROMs.
IPX: Boot Image Not RPLFIXed. As explained earlier in this chapter, a problem with DOS 5 and IPX PROMs occurs when the command interpreter is loaded and overwrites the IPX code in memory. The command interpreter is loaded immediately after CONFIG.SYS is processed, its first job being to run AUTOEXEC.BAT.
Therefore, if all CONFIG.SYS statements are executed but no AUTOEXEC.BAT commands are, a boot image is out there that has not been RPLFIXed. Examine the messages displayed by device drivers and so on as they load to ascertain if this has happened.
Make sure that all copies of the boot image are RPLFIXed:
Remember that running RPLFIX on a boot image that has already been RPLFIXed has no effect (but does no harm either).
IPX: RPLODI.COM Not Loaded. RPLODI.COM deals with the hand-over from the PROM's IPX code to the MLID's ODI code. If RPLODI.COM has not been loaded, the MLID loads but the workstation hangs with the error message:
Error reading boot disk image file
Make sure RPLODI.COM is loaded correctly:
Errors in Loading the Workstation Shell. The batch file that NETX.EXE or VLM.EXE is loaded from must be the same within the boot image and in SYS:LOGIN. If not, the byte offset might be wrong, and a variety of errors are possible, like Batch file missing or Bad command or file name.
Synchronize the relevant batch files:
Errors covered in this category occur after the workstation boots or starts to download its boot image but are related to the fact that the workstation was booted remotely rather than from a local floppy disk.
COMSPEC. The COMSPEC environment variable must be set during logon to point to a valid copy of COMMAND.COM for this version of DOS. If not, the following error message can appear when DOS tries to reload part of its command interpreter, typically after you exit an application:
Invalid COMMAND.COM Cannot load COMMAND, system halted
EMM386.EXE. If EMM386.EXE was loaded in CONFIG.SYS without the /Y switch, it assumes that it can reload from drive A. This results in an error when, for example, Windows is started:
EMM386: Unable to start Enhanced Mode Windows due to invalid path specification for EMM386.
DEVICE=EMM386.EXE /NOEMS /Y=F:\WINDOWS\EMM386.EXE /X=D000-D800
The nature of remote booting can lead to peculiar difficulties not normally encountered with ordinary workstations. For example, an error in the boot image can stop your workstation from booting, and you cannot log on to fix the error without going to a non-diskless workstation. The following sections discuss ways to get around some of these problems.
Grabbing the Phantom Floppy. During the remote boot process, the workstation "believes" that it is really booting from its floppy drive although no boot floppy disk is really present. The files contained in the boot image appear to the workstation as if they really are on drive A until the workstation shell loads, so it is possible to get hold of the files in the boot image by getting access to this phantom floppy disk.
Press Ctrl+Break (repeatedly if necessary) after the workstation starts to execute the commands in AUTOEXEC.BAT but before the workstation shell is loaded. Enter Y when you are asked
Terminate batch job (Y/N)?
You then should find yourself at the A:> prompt with access to all the files. You can use any of DOS's internal commands--DIR, COPY, and so on--to look at or manipulate files (watch the drive spinning when you enter DIR). Of course, external commands such as FORMAT and EDIT are not available.
Unpacking the Boot Image. Your master boot floppy might get lost or become corrupt. If the boot image is intact, you can unpack the files in it onto a disk using the /U option of DOSGEN, version 1.2 or later with the following command:
DOSGEN /U NE2$DOS.SYS A:
The disk must be of the same density and capacity as the original master boot floppy used to generate the boot image.
Maintaining Boot Images on the Fly. Making a minor change to a file in a boot image can be a lot of work. You need to find the master boot floppy, make the change, run DOSGEN again, RPLFIX the boot image if necessary, copy it to all the boot servers, and check the flags.
Alasdair Grant of the University of Cambridge, England has written an excellent utility named NETBOOT that allows you to manipulate the contents of an existing boot image in situ. It can be used to extract, replace, or delete files without the need to regenerate the boot image after doing so. Even an RPLFIXed boot image remains RPLFIXed after you change something using NETBOOT.
NETBOOT is command-line oriented rather than menu-driven. This means that multiple NETBOOT commands can be contained in a single batch file, making it possible to update the same boot image file on all servers at once. This reduces the possibility that an essential change will be missed on one or more servers.
In short, NETBOOT is an invaluable tool to anyone working with boot images.
Setting up a diskless workstation can be a complex business when compared to the ease with which a local boot machine can be prepared. There are extra layers of complexity in the preparation of the boot image file and in configuring the server to deliver the boot image. The payback for this extra work comes with the use of multiple similarly configured workstations. A single boot image can serve multiple workstations, so you can manage the boot configurations of an arbitrary number of workstations as if they were one.
This chapter explained how to configure and manage diskless workstations. It detailed the steps involved in preparing the workstation, boot image file, and file server and gave detailed troubleshooting procedures for the most common types of fault that arise when using diskless workstations. For more information on troubleshooting procedures and fault solving, refer to chapters 31, "Locating the Problem: Server versus Workstation versus Links," and 32, "Repairing Common Types of Problems."
© Copyright, Macmillan Computer Publishing. All rights reserved.