The only reason you're likely to encounter ND nowadays is if you have an old Sun 2 machine, like the 2/120 or 2/50. The Sun 2 PROMs can only use ND to boot over the network. (Later, the Sun 3 PROMs would use RARP and TFTP to boot over the network.)
ndbootd
is a very simple ND server that only supports client reads for
booting. It exports a disk that the clients consider to be
/dev/ndp0
(ND public unit zero). The disk is available only to clients that are
listed in
/etc/ethers
and have valid hostnames.
(Sun 2 PROMs don't do RARP, but they do learn their IP
address from the first ND response they receive from the server.)
boot1
is a file containing the mandatory first-stage network boot
program, typically
/usr/mdec/bootyy
.
The layout of the exported disk is:
With the
-s boot2
option,
ndbootd
will also make a second-stage network
boot program available to clients, typically
/usr/mdec/netboot
.
When
boot2
is a filename, that file is the single second-stage network boot program
to be served to all clients.
When
boot2
is a directory name, typically
/tftpboot
,
ndbootd
finds a
client's second-stage network boot program by turning its IP address
into a filename in that directory, in the same manner later Sun 3
PROMs do when TFTPing (i.e., if a client has IP address 192.168.1.10,
ndbootd
expects to find
/tftpboot/C0A8010A.SUN2
).
When used in this last manner with an ND-aware first-stage boot program, ndbootd serves the same purpose in the Sun 2 netboot process as tftpd(8) serves in the Sun 3 netboot process.
Any second-stage network boot program always begins at block 16 of the exported disk, regardless of the length of the first-stage network boot program.
All first- and second-stage network boot programs must have all executable headers stripped off; they must be raw binary programs.
The remaining options are:
/etc/ethers
/etc/hosts