1bootparams(4) File Formats bootparams(4)
2
3
4
6 bootparams - boot parameter data base
7
9 /etc/bootparams
10
11
13 The bootparams file contains a list of client entries that diskless
14 clients use for booting. Diskless booting clients retrieve this infor‐
15 mation by issuing requests to a server running the rpc.bootparamd(1M)
16 program. The bootparams file may be used in conjunction with or in
17 place of other sources for the bootparams information. See nss‐
18 witch.conf(4).
19
20
21 For each client the file contains an entry with the client's name and a
22 list of boot parameter values for that client. Each entry has the form:
23
24 clientname keyword=value...
25
26
27
28
29 The first item of each entry is the host name of the diskless client.
30 You can use the asterisk ('*') character as a "wildcard" in place of
31 the client name in a single entry. A wildcard entry applies to all
32 clients for which there is not an entry that specifically names them.
33
34
35 In a given entry, the host name or asterisk is followed by one or more
36 whitespace characters and a series of keyword—value pairs separated by
37 whitespace characters. There must not be any whitespace within a key‐
38 word—value pair.
39
40
41 Each keyword—value pair has the syntax:
42
43 keyword=value
44
45
46
47
48 The preceding form breaks out further as:
49
50 keyword=server:value
51
52
53
54
55 Where server can be null and value can be a pathname.
56
57
58 An example that includes a server is:
59
60 client1 root=server1:/export/client1/root
61
62
63
64
65 An example where server is null is:
66
67 client1 rootopts=:vers2
68
69
70
71
72 A minor variation of the keyword=value syntax is used for the domain
73 keyword. Unlike the forms shown above, this syntax does not use a
74 colon. For example:
75
76 client1 domain=bldg1.workco.com
77
78
79
80
81 Entries can span multiple lines. Use the backslash ('\') character as
82 the last character of a line to continue the entry to the following
83 line. For multiple-line entries, you can split a line only in places
84 where whitespace is allowed. For example, you can use a backslash to
85 split the following entry between the end of the path (root) and the
86 keyword domain:
87
88 client1 root=server1:/export/client1/root domain=bldg1.workco.com
89
90
91
92
93 In entries that specify a server, server is the name of the server that
94 will provide the file or filesystem to the diskless client and value is
95 the pathname of the exported file or filesystem on that server.
96
97
98 In entries that use the domain keyword, the domain name specified must
99 be the client's domain name. The algorithm for determining a client's
100 domain name is to first check for a domain keyword in the client-spe‐
101 cific entry and then in "wildcard" entry. If none is found, the
102 server's domain name is used.
103
104
105 For the JumpStart installation of machines that do not have video dis‐
106 plays, use the term keyword to identify the terminal type of the boot
107 server. Terminal types are listed in /usr/share/lib/terminfo (see ter‐
108 minfo(4)).
109
110
111 An entry with the ns keyword associates a server (a name server) with,
112 instead of a pathname, a specific name service (NIS+, NIS, LDAP, or
113 none) and, if that server is not on a local subnet, the netmask needed
114 to reach it. For example:
115
116 ns=hoot:nisplus(255.255.255.0)
117
118
119
120
121 An ns entry forces sysidtool(1M) to use the specified name service. By
122 default, sysidtool uses NIS+ in preference to NIS or LDAP if it can
123 find an NIS+ server for the system's domain on the subnet. An ns entry
124 might be necessary if you are trying to set up a hands-off installa‐
125 tion, or if the name server is on a different subnet, which is common
126 with NIS+.
127
128
129 If an ns keyword is not used, sysidtool uses broadcast to attempt to
130 bind to either a NIS+, NIS, or LDAP server. If a name server is not on
131 the local subnet, which is possible for NIS+ or LDAP, the bind will
132 fail, automatic configuration of the name service will fail, and an
133 interactive screen is displayed, prompting the user to specify the name
134 service.
135
136
137 The ns keyword can be set in add_install_client or by Host Manager.
138
140 Example 1 Sample bootparams Entry
141
142
143 Here is an example of an entry in the bootparams file:
144
145
146 client1 root=server1:/export/client1/root rootopts=:vers=2 \
147 domain=bldg1.workco.com
148 client2 root=server2:/export/client2/root ns=:nis
149 client3 root=server2:/export/client3/root ns=watson:
150 client4 root=server2:/export/client4/root \
151 ns=mach:nisplus(255.255.255.0)
152
153
154
155 Example 2 Sample Entry for JumpStart
156
157
158 The following is an example of an entry that might be used for the
159 JumpStart installation of diskless clients that do not have displays.
160
161
162 mozart root=haydn:/export/install/sparc/os/latest/Solaris_9/boot \
163 install=haydn:/export/install/sparc/os/8.1/latest boottype=:in \
164 install_config=haydn:/usr/local/share/lib/jump-net \
165 ns=otis:nisplus(255.255.255.0) term=:xterms domain=eu.cte.work.com
166
167
168
170 /etc/bootparams
171
172
174 rpc.bootparamd(1M), sysidtool(1M), nsswitch.conf(4)
175
177 Solaris diskless clients use the keywords root and rootopts to look up
178 the pathname for the root filesystem and the mount options for the root
179 filesystem, respectively. These are the only keywords meaningful for
180 diskless booting clients. See mount_ufs(1M).
181
182
183
184SunOS 5.11 22 Jul 2004 bootparams(4)