![[Previous]](../prev.gif) |
![[Contents]](../contents.gif) |
![[Next]](../next.gif) |
|
|
|
Service boot requests from the network (QNX)
netboot [-Aav] [-B burst] [-b address] [-f bootfile]
[-m mapfile] [-P packets] [-S ms] &
Boot data is sent out in bursts of packets, in between which netboot pauses. This is done so that machines executing from the boot ROM (which is slower than executing out of RAM) are not overwhelmed and unable to keep up with the flow of data. If a given node repeatedly tries to boot (within a short interval of the last data packet being sent), netboot will assume that the machine had trouble with the data rate and will use smaller packet bursts. The netboot utility will remember the last packet burst size used for a given node and will reuse it if that machine boots again within 15 minutes.
Special -B burst values may be specified to restrict this auto-slowdown feature:
The netboot utility services boot requests from machines attempting to boot over the network. If a node is being used as a boot server, netboot must be running on that node before other machines can boot over the network from that node.
When netboot starts, it queries the Network Manager (Net) about the network drivers currently running on the machine. Using the information it receives, netboot will "adopt" a corresponding set of boot packet protocols. Net then passes incoming boot packets to netboot, which services the boot request.
When boot request packets are passed to netboot, Net informs netboot of the following information:
With this information, netboot first determines the logical node ID of the requesting node, and then looks up how it is to boot that logical node.
The netboot utility determines the logical node ID of the requesting node by looking for an entry in the /etc/config/netmap file that matches the logical network ID and physical node ID of the requesting node. Only the logical-to-physical node ID mapping fields are considered; that is, netboot will try to boot the node regardless of whether the node is masked or unmasked. For more information on the format of the netmap file, see the documentation for the netmap utility.
If it doesn't locate a matching entry in the /etc/config/netmap file and if neither -a nor -A was specified, netboot will ignore this boot request and go back to waiting for another one. However, if -a or -A was specified, netboot will assign a logical node ID to the requesting node and append an entry for it to the end of the netmap file. It will then proceed to the next step of looking up how to boot that node.
Once netboot has found out the logical node ID of the requesting node, it uses that ID in combination with the logical network ID that the request came in on to look up in the /etc/config/netboot bootfile for information on how the boot request should be serviced.
The netboot file contains lines of the form:
log_node_ID [log_net_ID] [c=build_command] f=file|F=file [server_ID]
Each field is separated by white space consisting of space or tab characters. At least one white space character must separate each field. Any line starting with a # character is treated as a comment and ignored.
 |
Don't put any comments on the same line as an entry. For
example, don't do this:
8 f=build/node.8 #Node 8 has a UPS Comments must reside on their own line, like this: #Node 8 has a UPS 8 f=build/node.8 |
The fields are as follows:
This field has two forms:
F=imagefile
This form specifies that the named OS image be transmitted to the booting node. The imagefile must name the path to an OS image that has been built previously (usually via the buildqnx utility). If a relative pathname (one not starting with /) is used, it's assumed to be relative to the /boot directory. For example, F=images/ws.arcnet is equivalent to F=/boot/images/ws.arcnet.
f=buildfile [b=address]
This form instructs netboot to invoke buildqnx (or the program specified by the c=build_command field) on the fly to build an OS image. This image is then piped back into netboot and shipped as an image over the network. The specified buildfile is used by buildqnx to construct the image. As with the above F= form, relative pathnames for the buildfile are assumed to be relative to the /boot directory. (Note that f=buildfile is the preferred form.)
You can include a [b=address] after the f=buildfile to specify a load address for the OS image being constructed. If a b= is present, it will override (for this node only) the default address or the one specified by the -b command-line option to netboot. As with the -b command-line option, the address is always specified in hex, must be greater than or equal to 0x1000, and must be a multiple of 0x1000.
Generally, you should use f=buildfile instead of F=imagefile, since you save considerable disk space by not keeping prebuilt OS images on disk. Nevertheless, you may sometimes wish to freeze a particular image to keep it immune from subsequent OS module updates. For example, if you build images on the fly (f=) and obtain an updated version of Proc, the new Proc will become part of that network-booted OS image the next time the node is booted. However, if you built the image beforehand and used F=imagefile, the new Proc would not form part of the network-booted OS image until you run buildqnx to create a new imagefile on disk.
Since QNX is a modular OS, you don't need to build into the transmitted image all the modules you may require. Once the operating system loads, you can start many subsequent modules from the command line, or more typically, from the sysinit.node file. For more information on this method, see the buildqnx and sinit utilities.
Broadcast boot requests are similar to saying, "Will my boot server A boot me, please?" Every netboot process running on the network will get the broadcast boot request. It's up to each boot server to look in its own /etc/config/netboot bootfile to determine what its relationship to the booting node is. Based on this relationship, the boot request will be either serviced or ignored. That is, each boot server must check its bootfile to discover what server it is to be for the requesting node (i.e. server A, B, or C) and whether this is the server that the actual boot request is asking for. If it's a match, the request is serviced. Otherwise, the request is ignored.
If netboot is being run on multiple nodes, each netboot must have its own bootfile tailored to uniquely identify it as each node's primary, secondary, or tertiary boot server. This is required because of the way servers respond to the broadcast boot requests. If it isn't done, the multiple netboot servers on the network will respond simultaneously to the broadcast boot request.
The server_ID field must be a single alphabetic character. Typically, network boot ROMs that broadcast boot requests ask only for A, B, or C (primary, secondary, tertiary). The field isn't case-sensitive: upper- and lowercase both mean the same thing.
For the purposes of serving broadcast boot requests, having no server_ID field is treated the same as having a server_ID field specifying A (i.e. netboot will regard itself as being that node's primary boot server, by default).
Let's say you have two networks connected to node 1: logical network 1 (Arcnet) and logical network 2 (Ethernet).
The following are the contents of a /etc/config/netboot file that could be used by netboot on node 1:
| NID | LAN | Bootfile | "I am server..." |
|---|---|---|---|
| 2 | f=build/ws.arcnet | ||
| 3 | 1 | f=build/ws.arcnet | |
| 3 | 2 | f=build/ws.ether | B |
| * | 1 | f=build/ws.arcnet | |
| * | 2 | f=build/ws.ether | C |
The entry for logical node 2 is simple: boot node 2 regardless of which logical network the request came in on; use the build file ws.arcnet.
For node 3, a boot request may arrive via logical network 1 or via logical network 2. If the boot request for node 3 comes via logical network 1, then node 3 will be booted with the build file ws.arcnet. If the boot request for node 3 comes via network 2, netboot will respond to the request only if node 3 asks for its secondary (B) boot server. (We're assuming that another node is the primary boot server for nodes booting by Ethernet.) The ws.ether buildfile would be used in this case.
Any other nodes booting via network 1 will boot using the buildfile ws.arcnet. Any nodes that request to be booted from their tertiary (C) boot server on logical network 2 will boot using the build file ws.ether.
Run in verbose mode on the unused console /dev/con8:
ontty /dev/con8 netboot -v &
Assign node IDs automatically:
netboot -A &
As new network drivers become available for QNX, new versions of the netboot utility will be released that know about the new drivers and their boot packet protocols. When netboot starts, it will write a warning message to standard error if it doesn't support one of the network drivers you're running. A list of supported network types (e.g. Arcnet, Ethernet) is maintained in the usage message (use netboot).
|
|
|