Manual page for rpld(1M)
rpld - x86 Network Booting RPL (Remote Program Load) Server
The RPL server provides network booting functionality to x86
clients by listening to boot requests from them according to
the RPL protocol specifications.
Boot requests can be generated
using the boot floppy supplied in the
x86 distribution. Once the request has been received,
the server validates the client and adds it to its internal
service list. Subsequent requests from the client to download
bootfiles will result in the sending of data frames from the
server to the client specifying where to load the boot program
in memory. When all the bootfiles have been downloaded, the
server specifies where to start execution to initiate the boot
In the first synopsis, the interface parameter names the
network interface upon which
is to listen for requests.
In the second synopsis,
locates all of the network
interfaces present on the system and starts a daemon process
for each one.
The server starts by reading the default configuration file, or
an alternate configuration file if one is specified. If no
configuration file can be found, internal default values will
be used. Alternatively, command line options are available to
override any of the values in the configuration file. After the
configuration options are set, it then opens the network interface
as specified in the command line and starts listening to RPL boot
Network boot x86 clients have to have information pre-configured
on a server for the RPL server to validate and serve them. This
involves putting configuration information in both the
a translation from the physical node address to the IP address of
the clients and is normally used by the RARP server. The
database stores all other information needed for
booting off this client, such as the number of bootfiles and the
file names of the various boot components. Both databases can be
looked up by the RPL server through NIS. See the sub-section
for information on how to set up these databases.
To assist in the administration and maintenance of the network
boot activity, there are two run-time signals that the server
will accept to change some run-time parameters and print out
useful status information. See the sub-section Signals for
The RPL server is not limited to the ability to boot only x86 clients.
If properly configured, the server should be able to download
any bootfiles to the clients.
The following configuration information is specific to booting
In order to allow clients to boot x86 from across the
network, the client's information has to be pre-configured in
Both databases can
be accessed through NIS.
for information on how to configure a diskless x86 client.
The discussion contained in the rest of this section is
provided for your information only and
should not be performed manually.
database contains a translation table to convert
the physical node address to the IP address of the client.
Therefore, an IP address must be assigned to the client
(if this has not been done already), the node address of the
client must be obtained, and then this information needs
to be entered in the
The bulk of the configuration is done in the
database. This is a free-format database that essentially
contains a number of keyword-value string pairs. A number of
keywords have been defined for specific purposes, like the
Three more keywords have
been defined for the RPL server. They are
All three keywords must be in lowercase
letters with no spaces before or after the equals symbol
following the keyword.
Specifies the number of files to be downloaded to the
network boot client. The format of this option is:
to boot x86 across the
Specifies the path name of the bootfile to be downloaded
and where in memory to start loading the bootfile. A
complete path name should be used. For example, assuming the client's
IP address is 188.8.131.52:
The path name following the equals symbol specifies
the bootfile to be downloaded, and the hex address
following the colon (:) is the absolute address of the
memory location to start loading that bootfile. These addresses
should be in the range of 7c00 to a0000 (i.e., the base
640K range excluding the interrupt vector and BIOS
data areas). Address 45000 for this
bootfile is also a suggested
value and if possible should not be changed. The address of 35000 for
a suggested value that, if possible, should not be
changed. The address of 8000 for
an absolute requirement and should never be changed.
These files, when created following the procedures in the
are actually symbolic links to to the real file to be downloaded to the
is linked to
a special driver that corresponds to the network interface card of the client.
are generic to all network boot clients.
of these bootfile lines is not significant, but because problems
have been found with certain boot PROMs, it is highly
recommended that the bootfile lines be ordered in descending
order of the load addresses.
The absolute address in memory to start executing after
all the bootfiles have been downloaded. This address
should always correspond to the address where
is being loaded. If possible, always use:
- -f config filename.
Use this to specify a configuration
file name other than the system default
- -d debug level.
Specify a level of 0 if you do not want any
error or warning messages to be generated, or a level from
1 to 9 for increasing amounts of messages. This option
corresponds to the
setting in the configuration
file. The default value is 0.
Note that it is best to limit the level to 8 or below; use of level
9 may generate so many debug messages that the performance of the RPL
server may be impacted.
- -D debug destination.
Specify 0 to send error or warning
messages to standard output, 1 to syslogd, and 2 to the log
file. This option corresponds to the
in the configuration file. The default value is 2.
- -M maximum clients.
Specify the maximum number of simultaneous
network boot clients to be served. This option corresponds
setting in the configuration file. A
value of -1 means unlimited, and the actual number will
depend on available system resources. The default value is -1.
- -b background mode.
Specify 1 to run the server in the background and
relinquish the controlling terminal, or 0 to run in the foreground without
relinquishing the controlling terminal. This option corresponds
setting in the configuration file. If you
have specified that the error or warning messages be sent to standard
output in the configuration file or by using the
option above, the
server cannot be run in background mode. Doing so will cause
the server to exit after announcing the error.
- -l log filename.
Specify an alternate log file name to hold
the error or warning messages in connection with the
option or the configuration file
DebugDest = 2
This option corresponds to the
setting in the
configuration file. The default is
- -s start delay count.
This option corresponds to the
setting in the configuration file. Specify the number of
delay units between outgoing data frames sent to clients
to avoid retransmission requests from them. Using the LLC
type 1 protocol, data transfer is a one-way, best-effort
delivery mechanism. The server, without any type of delay
mechanism, can overrun the client by sending data frames too
quickly. Therefore, a variable delay is built into the server
to limit the speed of sending data to the clients, thus avoiding
the clients sending back retransmission requests. This value
should be machine environment specific. If you have a fast
server machine but slow client machines, you may want to set
a large start delay count. If you have comparable server
and client machines, the delay count may be set to 1. The
delay is only approximate and should not be taken as an accurate
measure of time. There is no specific correlation between
the delay unit and the actual time of delay. The default
value is 20.
- -g delay granularity.
This corresponds to the
in the configuration file. If retransmission requests from
clients do occur, the delay granularity factor will be used to
adjust the delay count for this client upwards or downwards.
If the retransmission request is caused by data overrun, the
delay count will be incremented by delay granularity units
to increase the delay between data frames. If the retransmission
request is caused by sending data too slowly, this will be used
to adjust the delay count downwards to shorten the delay.
Eventually the server will settle at the delay count value that
works best with the speed of the client and no retransmission
request will be needed. The default value is 2.
- -z frame size.
This option corresponds to the
in the configuration file. This specifies the size of the
data frames used to send data to the clients. This is limited
by the underlying physical medium. For
maximum physical frame size is 1500 octets. The default value
is 1500. Note that the protocol overhead of LLC1 and RPL is
32 octets, resulting in a maximum data length of 1468 octets.
The RPL server accepts two signals to change run-time parameters
and display status information, respectively:
This will cause the RPL server to reread the default
or an alternate
configuration file if one is specified when the server
is started. New values of certain parameters can be
used immediately, such as
if the server is
already serving more than the new value, the server will
not accept additional boot requests until the number
has fallen below the
this will only affect new boot requests. All the existing
delay counts for the various clients in service will not
be affected. Finally, the
parameter will have
no effect once the server has been running. You cannot
change the mode of service without first killing the
server and then restarting it.
This signal will cause the server to dump all the parameter
values and the status of each individual boot client to the
destination specified by
Created by unroff & hp-tools.
© by Hans-Peter Bischof. All Rights Reserved (1997).
Last modified 21/April/97