Thank you for your replies. I found what was wrong. Indeed it had
nothing to do with the default route or JASS. And the NFS server setup
was Ok, too.
I had earlier installed a JumpStart boot server on one workstation;
now I was trying to put the boot server on another one. And I forgot
to stop or restart the rpc.bootparamd server on the old boot server.
So now I had two rpc.bootparamd servers in the same network.
So practically, because I was sloppy last time when I played with JS
and did not clean up after it I had to pay the price now. It was
however a good oportunity to learn more about the process and play
with snoop.
I simply stopped rarpd, tftpd, bootparamd, nfs server on the old boot
server and it all worked fine.
BTW: is there any script provided with Solaris to undo the config
modifications done by the add_install_client script ( to automate
what I did in the above steps ) ?
Vlad Grama.
> > Hello,
> > I setup a JS install server (on one subnet) and on another subnet I
> > setup a boot server.
> > I use RARP/BOOTPARAMS for booting the client.
> > When JS client boots (boot net -v) it finds the boot server,
> > configures /dev and /devices says "using RPC bootparams ...", says
> > configured eri0 (the only network interface on client) and here it
> > dies.
> > I presume the JS client does not get the default root from the Boot
> > Server. The Boot Server has previously been hardened using JAAS. Does
> > anyone know what service (or lines in /etc/init.d/inetsvc ???) should
> > be started so that the JS client can find its way to the install
> > server and mount the OS image ??
> Hmm. Why do you think it's the default route at issue? Are you certain
> the image has never been mounted rw by a client, and that it's shared
> with anon=0?
> > I didn't find anywhere detailed information about how the default
> > route gets transfered from boot server to install server. Normally I
> > would not care "how exactly" it is done. But as you see I am forced
> > to.
> The traditional method involves the use of rpc.bootparamd which is used
> earlier in the boot process to specify the mount point for the root
> directory. It simply hands the client the same default route that is
> used by the bootparamd server.
> However, that point of the boot process isn't likely to stall based on a
> default route. Snoop the wire for client packets and see what you get.
> Are you getting any NFS transactions at the time?