bootparams - boot parameter data base
The bootparams file contains a list of client entries that diskless clients use for booting. Diskless booting clients retrieve this information by issuing requests to a server running the rpc.bootparamd(1M) program. The bootparams file may be used in conjunction with or in place of other sources for the bootparams information. See nsswitch.conf(4).
For each client the file contains an entry with the client's name and a list of boot parameter values for that client. Each entry has the form:
The first item of each entry is the host name of the diskless clieFnt. You can use the asterisk ('*') character as a wildcard in place of the client name in a single entry. A wildcard entry applies to all clients for which there is not an entry that specifically names them.
In a given entry, the host name or asterisk is followed by one or more whitespace characters and a series of keyword—value pairs separated by whitespace characters. There must not be any whitespace within a keyword—value pair.
Each keyword—value pair has the syntax:
The preceding form breaks out further as:
Where server can be null and value can be a pathname.
An example that includes a server is:
An example where server is null is:
A minor variation of the keyword=value syntax is used for the domain keyword. Unlike the forms shown above, this syntax does not use a colon. For example:
Entries can span multiple lines. Use the backslash ('\') character as the last character of a line to continue the entry to the following line. For multiple-line entries, you can split a line only in places where whitespace is allowed. For example, you can use a backslash to split the following entry between the end of the path (root) and the keyword domain :
client1 root=server1:/export/client1/root domain=bldg1.workco.com
In entries that specify a server, server is the name of the server that will provide the file or filesystem to the diskless client and value is the pathname of the exported file or filesystem on that server.
In entries that use the domain keyword, the domain name specified must be the client's domain name. The algorithm for determining a client's domain name is to first check for a domain keyword in the client-specific entry and then in wildcard entry. If none is found, the server's domain name is used.
An entry with the ns keyword associates a server (a name server) with, instead of a pathname, a specific name service (NIS , LDAP, or none) and, if that server is not on a local subnet, the netmask needed to reach it. For example:
An ns entry forces installation software to use the specified name service. By default, NIS is used in preference to LDAP if it can find an NIS server for the system's domain on the subnet. An ns entry might be necessary if you are trying to set up a hands-off installation.
If an ns keyword is not used, installation software uses broadcast to attempt to bind to either an NIS or LDAP server. If a name server is not on the local subnet, which is possible for LDAP, the bind will fail, automatic configuration of the name service will fail, and an interactive screen is displayed, prompting the user to specify the name service.
The ns keyword can be set by Host Manager.
Here is an example of an entry in the bootparams file:
client1 root=server1:/export/client1/root rootopts=:vers=2 \ domain=bldg1.workco.com client2 root=server2:/export/client2/root ns=:nis client3 root=server2:/export/client3/root ns=watson: client4 root=server2:/export/client4/root \ ns=mach:nis(255.255.255.0)
Solaris diskless clients use the keywords root and rootopts to look up the pathname for the root filesystem and the mount options for the root filesystem, respectively. These are the only keywords meaningful for diskless booting clients. See mount_ufs(1M).