multiple client root partition "feature"

[Steve Platt]

Dear Paul,

I just read your bit in sun-spots after having spent all Friday trying to
boot the right system up on my machine.

I had made a worse mistake, that of preparing to shift a client from one
server to another - I had made the new nd.local entries on the new server
(you have to to copy stuff into the ndl partition) while the old server
was still offering ND services to the client too.

What then happened was that I tried to boot my client and got
"cant exec /etc/init - code 2" errors, the client endlessly rebooting.

I searched manuals and put the scraps of info together, what follows is my
impression of what happens. You certainly dont control much by making or
deleting the entries in /tftpboot, except where the "ndboot" program MAY
come from - note that this needent be the server vmunix comes from!

When a diskless client boots:-
1) the PROM broadcasts its ethernet address asking for its IP address
(M)any host(s) may reply to this - the first reply is used (?) ...

2) The PROM tries to TFTP the (nd)boot program from THAT host (ie the one
that it took that first reply from) - hopefully this is a server ....

If the server has an entry in /tftpboot for that client (in the form of
the HEX ethernet address link to the boot program)  it will send the program.

2a) if the server does not respond with ndboot, the PROM retries the tftp
request to ALL servers by broadcasting it (gasp!) - some servers may then
find the /tftpboot link and send the ndboot program(s) ...

The above is roughly what boot(8) says, upon reflection

3) ndboot then tries to load vmunix from an ND partition (ndp1, maybe)
 - but from which nd server? Maybe it broadcasts an ND request ...
  (In fact it probably needs to find its IP address first)
Next, any ND server with an appropriate public partition entry in nd.local
might respond, which fits the observed facts!

So, some server gives you its pub/vmunix, which now starts up.  It needs
to mount its root filesystem (say nd0) so it too broadcasts REVARP and ND
requests (etc) till someone comes up with nd0 for root and nd1 to swap on

So if you have multiple servers with entries in nd.local naming your
workstation they could all potentially become your nd0 server. Who gave
you your ndboot program is pre-history; the /tftpboot entry is irrelevant,
so long as there's at least one on your network. Which kernel you are
running seems somewhat arbitrary too.

You can control some of this by forcing the PROM to load ndboot from a
specific server by using "b le(0,xx,0)" where "xx" is the hex host number
of the server - ie the last part of the IP address. This gets the ndboot
program from just that server, and passes the string le(0,xx,0)vmunix on
to ndboot, to force a specific kernel to get loaded. I dont think that
determines the kernel's ND server however!

So if you must keep an entry in nd.local to keep the filesystem available
for some reason, just rename it to some unknown hosts name (eg client.bak)
and although nd complains you can get at the partition with the /dev/ndl?
entry.

I'm sure someone will fill in the holes in the above, which is mostly my
guesswork Hope it helps.

Steve Platt
Applied Psychology Unit
Medical Research Council
15, Chaucer Road
Cambridge CB2 2EF
0223 355294 x 114

[[ You'll be happy to know that this is all different under 4.0.  No more
ND.  And the file /etc/bootparams describes where a client's root comes
from.  And /etc/ethers is a YP database.  I'll provide more detail (about
the ramifications) another day.  --wnl ]]