steve%mrc-applied-psychology.cambridge.ac.uk@nss.cs.ucl.ac.uk (Steve Platt) (03/24/89)
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 ]]