bootparams(4)




NAME

     bootparams - boot parameter data base


SYNOPSIS

     /etc/bootparams


DESCRIPTION

     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:

     clientname    keyword=value...

     The first item of each entry is the host name of  the  disk-
     less  client.  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:

     keyword=value

     The preceding form breaks out further as:

     keyword=server:value

     Where server can be null and value can be a pathname.

     An example that includes a server is:

     client1 root=server1:/export/client1/root

     An example where server is null is:

     client1 rootopts=:vers2

     A minor variation of the keyword=value syntax  is  used  for
     the  domain keyword. Unlike the forms shown above, this syn-
     tax does not use a colon. For example:
     client1 domain=bldg1.workco.com

     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 disk-
     less 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.

     For the JumpStart installation of machines that do not  have
     video  displays, use the term keyword to identify the termi-
     nal type of the boot server. Terminal types  are  listed  in
     /usr/share/lib/terminfo (see terminfo(4)).

     An entry with the ns keyword associates  a  server  (a  name
     server) with, instead of a pathname, a specific name service
     (NIS+, NIS, or none) and, if that server is not on  a  local
     subnet, the netmask needed to reach it. For example:

     ns=hoot:nisplus(255.255.255.0)

     An ns entry forces sysidtool(1M) to use the  specified  name
     service.  By  default,  sysidtool uses NIS+ in preference to
     NIS 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, or if the name server is
     on a different subnet, which is common with NIS+.

     If an ns keyword is not used, sysidtool  uses  broadcast  to
     attempt  to  bind  to either a NIS+ or NIS server. If a name
     server is not on the local subnet,  which  is  possible  for
     NIS+,  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 in add_install_client or  by  Host
     Manager.


EXAMPLES

     Example 1: Sample bootparams Entry

     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:nisplus(255.255.255.0)

     Example 2: Sample Entry for JumpStart

     The following is an example of an entry that might  be  used
     for  the  JumpStart installation of diskless clients that do
     not have displays.

     mozart root=haydn:/export/install/sparc/os/latest/Solaris_9/boot \
     install=haydn:/export/install/sparc/os/8.1/latest boottype=:in \
     install_config=haydn:/usr/local/share/lib/jump-net \
     ns=otis:nisplus(255.255.255.0) term=:xterms domain=eu.cte.work.com


FILES

     /etc/bootparams


SEE ALSO

     rpc.bootparamd(1M), sysidtool(1M), nsswitch.conf(4)


NOTES

     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).


Man(1) output converted with man2html