rpld(1M) System Administration Commands rpld(1M)NAMErpld - Network Booting RPL (Remote Program Load) Server
SYNOPSIS
/usr/sbin/rpld [-fdDMblgz] interface
/usr/sbin/rpld -a [-fdDMblgz]
DESCRIPTION
The RPL server provides network booting functionality to x86 clients by
listening to boot requests from them according to the RPL protocol
specifications. rpld runs on both x86 and SPARC systems. Boot requests
can be generated by clients using the boot floppy supplied in the dis‐
tribution. 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
process.
In the first synopsis, the interface parameter names the network inter‐
face upon which rpld is to listen for requests. For example:
/usr/sbin/rpld /dev/eri0
/usr/sbin/rpld /dev/smc0
In the second synopsis, rpld 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 requests.
Network boot 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 ethers(4) and the boot‐
params(4) databases. The ethers database contains a translation from
the physical node address to the IP address of the clients and is nor‐
mally used by the RARP server. The bootparams 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 data‐
bases can be looked up by the RPL server through NIS. See the sub-sec‐
tion Client Configuration for information on how to set up these data‐
bases.
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 informa‐
tion. See the sub-section Signals for details.
The RPL server is not limited to the ability to boot only clients. If
properly configured, the server should be able to download any boot‐
files to the clients.
Client Configuration
The following configuration information is specific to booting x86
clients.
In order to allow clients to boot x86 from across the network, the
client's information has to be pre-configured in two databases:
ethers(4) and bootparams(4). Both databases can be accessed through
NIS. Refer to for information on how to configure a diskless x86
client. The discussion contained in the rest of this section is pro‐
vided for your information only and should not be performed manually.
The ethers database contains a translation table to convert the physi‐
cal 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 ethers database.
The bulk of the configuration is done in the bootparams database. This
is a free-format database that essentially contains a number of key‐
word-value string pairs. A number of keywords have been defined for
specific purposes, like the bootparams RPC in bootparamd(1M). Three
more keywords have been defined for the RPL server. They are numboot‐
files, bootfile, and bootaddr. All three keywords must be in lowercase
letters with no spaces before or after the equals symbol following the
keyword.
numbootfiles Specifies the number of files to be downloaded to the
network boot client. The format of this option is:
numbootfiles=n
Always use numbootfiles=3 to boot x86 across the net‐
work.
bootfile Specifies the path name of the bootfile to be down‐
loaded and where in memory to start loading the boot‐
file. A complete path name should be used. For example,
assuming the client's IP address is 172.16.32.15:
bootfile=/rplboot/172.16.32.15.hw.com:45000
bootfile=/rplboot/172.16.32.15.glue.com:35000
bootfile=/rplboot/172.16.32.15.inetboot=8000
The path name following the equals symbol specifies the
bootfile to be downloaded, and the hex address follow‐
ing 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 vec‐
tor and BIOS data areas). Address 45000 for this
hw.com bootfile is also a suggested value and if possi‐
ble should not be changed. The address of 35000 for
glue.com is a suggested value that, if possible, should
not be changed. The address of 8000 for inetboot is 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 client.
hw.com is linked to a special driver that corresponds to the network
interface card of the client. glue.com and inetboot are generic to all
network boot clients.
The order of these bootfile lines is not significant, but because prob‐
lems have been found with certain boot PROMs, it is highly recommended
that the bootfile lines be ordered in descending order of the load
addresses.
bootaddr The absolute address in memory to start executing after all
the bootfiles have been downloaded. This address should
always correspond to the address where glue.com is being
loaded. If possible, always use:
bootaddr=35000
OPTIONS
The following options are supported:
-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 corre‐
sponds to the BackGround setting in the config‐
uration file. If you have specified that the
error or warning messages be sent to standard
output in the configuration file or by using
the -D option above, the server cannot be run
in background mode. Doing so will cause the
server to exit after announcing the error.
-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 Debu‐
gLevel 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 DebugDest
setting in the configuration file. The default
value is 2.
-f config_filename Use this to specify a configuration file name
other than the system default /etc/rpld.conf
file.
-g delay_granularity This corresponds to the DelayGran setting in
the configuration file. If retransmission
requests from clients do occur, the delay gran‐
ularity 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.
-l log_filename Specify an alternate log file name to hold the
error or warning messages in connection with
the -D 2 option or the configuration file
DebugDest = 2 setting. This option corresponds
to the LogFile setting in the configuration
file. The default is /var/spool/rpld.log.
-M maximum_clients Specify the maximum number of simultaneous net‐
work boot clients to be served. This option
corresponds to the MaxClients setting in the
configuration file. A value of −1 means unlim‐
ited, and the actual number will depend on
available system resources. The default value
is −1.
-s start_delay_count This option corresponds to the StartDelay set‐
ting 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 proto‐
col, 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 retrans‐
mission 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 accu‐
rate measure of time. There is no specific cor‐
relation between the delay unit and the actual
time of delay. The default value is 20.
-z frame_size This option corresponds to the FrameSize set‐
ting in the configuration file. This specifies
the size of the data frames used to send data
to the clients. This is limited by the underly‐
ing physical medium. For ethernet/802.3, the
maximum physical frame size is 1500 octets. The
default value is 1500. Note that the protocol
overhead of LLC1 and RPL is 32 octets, result‐
ing in a maximum data length of 1468 octets.
Signals
The RPL server accepts two signals to change run-time parameters and
display status information, respectively:
HANGUP This will cause the RPL server to reread the default configu‐
ration file /etc/rpld.conf 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 Debu‐
gLevel, DebugDest, LogFile, DelayGran, and FrameSize. For
MaxClients, 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 MaxClients
parameter. For StartDelay, this will only affect new boot
requests. All the existing delay counts for the various
clients in service will not be affected. Finally, the Back‐
Ground 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.
USR1 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 DebugDest.
FILES
o /usr/sbin/rpld
o /etc/rpld.conf
o /var/spool/rpld.log
o /etc/ethers
o /etc/bootparams
o /rplboot
ATTRIBUTES
See attributes(5) for descriptions of the following attributes:
┌─────────────────────────────┬─────────────────────────────┐
│ ATTRIBUTE TYPE │ ATTRIBUTE VALUE │
├─────────────────────────────┼─────────────────────────────┤
│Architecture │x86, SPARC │
├─────────────────────────────┼─────────────────────────────┤
│Availability │SUNWbsu │
└─────────────────────────────┴─────────────────────────────┘
SEE ALSObootparamd(1M), in.rarpd(1M), bootparams(4), ethers(4), nss‐
witch.conf(4), rpld.conf(4), attributes(5)SunOS 5.10 2 Dec 2003 rpld(1M)
