1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
|
D E F I N I N G M E N U S
Since version 0.7 netboot supports a Menu Generation Language called MGL, which
is a Pascal like language. It provides an easy way for creating customizable
menus for the netboot process. You have to write a simple MGL program which
will then be compiled by mknbi-mgl into a directly loadable and executable
network boot image file. It can then be loaded by the bootrom via TFTP like
any normal boot image, but allows booting different other image files depen-
ding on the MGL program itself. It is planned to discontinue the use of the
older BOOTP vendor tag method, which is described below, in the near future.
Defining a menu with MGL:
========================
Using a menu means booting different operating systems, selected by the
user at runtime. This means that you first have to provide all those
boot image files, which you want to boot lateron. To do this, you have
to use the mknbi-<os> programs. See the general install.netboot file and especially
the corresponding man pages for further information about how to do this.
I recommend to name all boot image files as bootImage-<os> and keep them
all together in one directory for each client system. Now read the mknbi-mgl
man page which explains the definition of MGL to some detail. If you are
familiar to the Pascal programming language be careful as MGL is only
_similar_ to Pascal, not identical! However, since reading a language
definition is not very entertaining, and you probably won't understand
it the first time you read it, I recommend to use some sample program.
For this change into the directory mknbi-mgl/tests in the netboot distri-
bution and read the file menu.mgl in parallel with the man page. You will
then understand the MGL definition more easily. Then you should copy the
menu.mgl file to some other directory (best would be to use the directory
where you also keep your boot image files) and modify it according to your
local setup with a normal text editor. Especially you want to adjust the
paths to the different operating system boot image files, and also change
the device names for the local partitions in case you also want to offer
to boot from a local hard disk. If your client doesn't have any hard disk
installed, you should remove the corresponding lines in menu.mgl. When you
are finished editing, compile the file with
mknbi-mgl -i menu.mgl -i bootImage-menu
which will create a boot image file named bootImage-menu. If mknbi-mgl
finds any program errors, it will print the line numbers where it detected
the errors. You will then have to reedit the source file and run mknbi-mgl
again. When your menu program compiled without an error, change the 'bf'
tag for the diskless client in your /etc/booptab to point to this new boot
image file. If you have bootpd permanently running on your server, send
it the HUP signal and reboot your client. It will now load the bootImage-menu
file and you should see the output of your menu program.
Definig a menu with the older tag method:
========================================
Starting with version 0.4 the bootrom supports BOOTP vendor tag extensions
which allow menu definitions and selection of different boot image files.
These definitions have been first suggested by Markus Gutschke, and the
bootrom is compatible with those suggestions, using some minor enhancements.
The basic idea behind this menu definition is the fact that most modern BOOTP
daemons have the ability to define custom vendor extension tags. RFC1533
reserves the range from 128 to 254 for those custom tags. The following
tags are currently used by the bootrom:
Tag 128:
This tag contains a total of six bytes. The first four bytes
have to be the magic number E4 45 74 68. If this magic number
is not present, the bootrom will not examine any of the other
tags described herein. The fifth byte contains the major version
number and the sixth byte the minor version number of this pro-
tocol extension. The current version recognized by the bootrom
is 0.1. If the major number is different, it's assumed that
the specification of the remaining tags has been changed signi-
ficantly. Also, if the minor version number is higher than
that expected, the bootrom assumes unsupported extensions. In
both cases it rejects all other tags and boots in the standard
way without displaying a menu. However, the minor number can
be smaller than expected.
This tag requires that the BOOTP daemon is able to accept
some form of hex data in the bootptab file.
Tag 160:
This tag contains a string which consists of colon separated
options. Each option contains a keyword, an equal sign and
a numeric decimal value. Currently the following options are
supported:
timeout - A value which tells the bootrom how many seconds
it should wait for user input. After the timeout
has elapsed without, the it will boot a default
image. If no timeout has been defined or the
value is zero, the bootrom will wait indefinitely
for user input.
default - This value tells the bootrom which image to load
when a timeout occurs. It can be either a value
in the range from 0 to 15, referring to the corres-
ponding menu entry number. Or it can be a value in
the range from 192 to 207, referring to the tag
number corresponding to the default image.
Tags 184 to 191:
These tags contain strings which will be displayed before
printing the menu. After printing each string, the bootrom
will print a CR/LF. The strings can also contain common con-
trol characters like CR, LF etc. If you built the bootrom
with ANSI display support you can use ANSI control sequences
here. The bootrom currently supports the following ANSI
control sequences:
Display attributes
Code Effect
<esc>[0m normal text
<esc>[1m high-intensity on
<esc>[21m high-intensity off
<esc>[5m blinking on
<esc>[25m blinking off
<esc>[7m reverse video on
<esc>[27m reverse video off
<esc>[3xm set foreground color:
<esc>[4xm set background color. x can be:
0 - black 4 - blue
1 - red 5 - magenta
2 - green 6 - cyan
3 - yellow 7 - white
Cursor control
Code Effect
<esc>[r;cH move cursor to row r and column c
<esc>[rA move cursor up r rows
<esc>[rB move cursor down r rows
<esc>[cC move cursor right c columns
<esc>[cD move cursor left c columns
<esc>[?7l turn off line wrap
<esc>[?7h turn on line wrap
<esc>[J clear screen and home cursor
<esc>[s save the cursor position
<esc>[u return cursor to saved position
Note that you usually have to specify any control characters
directly (rather than in hex form) in your bootptab file.
Tags 192 to 207:
These tags define the boot images to be offered in the
menu. They don't have to be in successive order. However,
the bootrom will display all option in numeric order with
consecutive numbers. Each image has to be specified in the
form:
label:server:gateway:filename
If any of the colon separated entries is missing, the default
value will be used which is set by other tags defined in RFC1533
and RFC951.
label - This string appears in the menu right after the
menu item number.
server - Specification of the TFTP server on which to find
the boot image file. It is possible to use either
the IP number of the server in dot form, or give
a host name. The bootrom will try to resolve this
hostname using the default domain and domain name
server given with other BOOTP tags. However, the
bootrom is only able to resolve names for which
the given name servers are authoratative. Recursive
resolving is not directly supported, but the name
servers are free to handle recursion in lieu of
the client.
If the server entry is empty, the bootrom will
use the IP address which has been given with the
'sa' tag in the bootptab file. And if that tag
is also missing, it will use the BOOTP server.
gateway - Specification of gateway to be used by the bootrom
to reach the TFTP server. If this is empty, the
first address given with the 'gw' tag is used.
Hostname resolving is the same as with the server
entry as described above.
filename - The full pathname of the boot image file on the
TFTP server. If the pathname starts with "/dev/"
it will be interpreted by the bootrom itself. It
interprets the filename as a local device according
to the device names used by Linux, and reads the
boot sector from that device and starts it. This
can be used to boot an operating system from a
local disk instead from the network. Currently
the bootrom only knows about the following devices:
/dev/hdax, /dev/hdbx, /dev/hdcx, /dev/hddx
/dev/fd0, /dev/fd1, /dev/fd2, /dev/fd3
If a bootblock can't be read, or the filename
entry is empty, the bootrom calls the standard
BIOS boot loader. But you should be aware of the
fact that the bootrom only starts up when the
BIOS was unable to locate a bootable partition
after poweron. Therefore, bailing out to the BIOS
by leaving this entry empty is only useful if the
user inserted a floppy disk into the client. Other-
wise you should give one of the above mentioned
special device codes for local disk booting.
Defining custom tags in the bootptab file can be done using the letter
'T' followed by the decimal number of the tag with most BOOTP servers.
Because defining a menu with the tags described above can result in a
rather large vendor tag area within the BOOTP packet, it is usually
necessary to use a BOOTP extension file. A program to generate such an
extension file from a bootptab is usually called 'bootpef', but this
may vary with your implementation. See your server documentation for
further information.
As an example of how a menu definition might look like, here is a
sample excerpt from my bootptab file which loads either Linux or MS-
DOS from the network, or by default loads MS-DOS from the first par-
tition of the local hard disk into a client named mydos. The .menu
entry refers to .localnet, which contains general parameters for all
systems on my local network and which is not included here. The two
characters '^[' stand for the escape character. If you are editing
/etc/bootptab with vi you can generate such a special sequence using
the Ctrl-V key sequence. Check your editor documentation for further
information.
.menu:\
:tc=.localnet:\
:T184="^[[2J ^[[44m+=============================================================+^[[40m":\
:T185=" ^[[44m| |^[[40m":\
:T186=" ^[[44m| Boot menu for mydos |^[[40m":\
:T187=" ^[[44m| |^[[40m":\
:T188=" ^[[44m+=============================================================+^[[40m":\
:T128=E44574680001:\
:T160="timeout=10:default=195":\
:T192="Linux from network server:::/boot/mydos-root/bootImage-linux":\
:T193="MS-DOS from network server:::/boot/mydos-root/bootImage-dos":\
:T195="MS-DOS from local disk:::/dev/hda1":
mydos:tc=.menu:ha=004001417173:ip=192.109.225.66:\
:bf=mydos-root/bootImage:\
:ef=mydos-root/bootExtension
|
