rbootd(1M)

bootpd/bootptab Dependency :

rbootd now relies on bootpd(1M) to verify the identity of cluster clients and locate the bootable images (from /etc/bootptab). RMP clients are thus administered in exactly the same way as new BOOTP clients. The old methods for administering RMP clients (/etc/clusterconf, context-dependent files, /usr/boot/*) are obsolete and no longer work.

See bootpd(1M) and sam(1M) for details on configuring cluster clients.

It is necessary to have the bootpd daemon running on the same machine as the rbootd daemon.

Auto-Discovery:

To aid the system administrator, rbootd now discovers working ethernet interfaces at startup time and monitors them for boot requests. Alternatively, the system administrator may put a list of up to ten ethernet devices on the command line. Putting device names on the command line means "monitor these devices ONLY". If device names are included on the command line, they must be ethernet interfaces (not X.25, token-ring, etc) and they must be up and running at the time rbootd is started. See lanscan(1M) and ifconfig(1M) to determine the state of system devices. Attempting to have rbootd monitor non-ethernet devices will not succeed. The device names must always be of the form lan0 or lan1 etc, where the device name matches what is reported by lanscan.

Multiple LAN Coverage :

rbootd can monitor up to 10 lan devices (depending on hardware) and can boot clients from all of them. Clients are still restricted to booting from their own builtin lan devices.

Gateway Booting :

RMP clients can now be booted from servers that are not on the same subnet as the client. The RMP boot requests and replies cannot cross gateways, but the repackaged BOOTP requests and replies can. The BOOTP requests and replies are relayed across gateways by bootpd. This is known as the remote configuration.

rbootd uses the NFS or tftp mechanism to transfer the necessary files from the remote server to the rbootd machine, and then transfers the bootable images to the client in a succession of RMP packets. Thus the remote server must make the necessary files accessible by NFS or tftp.

In the remote-tftp case, the boot files are temporarily stored in /var/rbootd/C0809*, and are removed after a period of inactivity, controlled by the -t option. The default is 10 minutes.

S800 Servers :

S800 machines can now be used as cluster servers, booting s700 clients and DTCs. S800 machines are not supported as cluster clients.

Network Install :

rbootd now forwards install requests to instl_bootd(1M). If there is no appropriate response, rbootd will deny the request.

S300/400 Not Supported :

S300/400 machines are not supported as diskless clients.

Performance Recommendations :

Boot from a local server for the fastest boot times. Run the rbootd daemon and the bootpd server daemon on the same machine, and avoid transferring the boot files by NFS or tftp. This is strongly recommended.

If booting from remote bootpd servers (across gateways), use NFS mounts to make the boot files available to the rbootd server. See mount(1M) for more information. The system administrator can configure local and remote diskless clients in any mix, but it is strongly recommended that the number of remote diskless clients be minimized.

If booting from remote servers using the tftp method, there must also be temporary file space available on the rbootd server machine. Generally 6-8 MBytes per diskless client must be available under /var, but this number could be larger when booting customized kernels. These temporary files are removed automatically after some period of inactivity, controlled by the -t option. The default is 10 minutes.

RMP/BOOTP :

The RMP clients are the older s700 workstations and all DTCs: workstations: 705, 710, 715/33, 715/50, 715/75, 720, 725/50, 725/75, 730, 735, 750, 755

The BOOTP clients are the s712, s715/64, s715/100, B-Class, C-Class, D-Class and future workstations.