Hi all, Sorry, this might be a bit off topic, but I'm not sure of the best place to ask. I'm booting a diskless PC with PXELinux, and the kernel loads successfully and I can log in and use the system as you'd expect. I have done this before, however this time I decided to try using ClusterNFS so that the diskless clients can share the boot server's filesystem. Unfortunately during system boot up to test whether the RPC portmapper is loaded, the boot scripts run "rpcinfo -p" which causes the PC to sit there for about ten minutes and then eventually time out and continue with the boot process. This happens three times during boot, which needless to say means there's a *long* wait before I can log in. Does anyone have any idea why this would happen? Although the diskless client and the host share the same filesystem, they have separate copies of /var/lib/nfs/, /var/lock/ and /var/run/ (among other things) but my only guess is that there's some other filesystem location that is being shared and it shouldn't be. Interestingly enough, the RPC portmapper does eventually load, but none of the NFS programs work properly, all giving various odd error messages and seeming to be unable to find the portmapper. Any ideas? Thanks, Adam.
> Unfortunately during system boot up to test whether the RPC portmapper > is loaded, the boot scripts run "rpcinfo -p" which causes the PC to > sit there for about ten minutes and then eventually time out and > continue with the boot process. > Does anyone have any idea why this would happen?Well, in case anyone has a similar problem in the future, I worked out what the problem was. It seems that the 'lo' interface wasn't being assigned the IP address 127.0.0.1, so whenever any program tried to connect to 'localhost' it would just sit there and eventually time out instead of either connecting or returning a 'connection refused' response. It seems that my distro's boot scripts (Slackware 9.1) were checking to see whether the 'lo' interface was up, and if not they enabled it and assigned it an IP. But it seems that the kernel's IP autoconfiguration process while correctly setting up eth0, also enabled 'lo' but didn't assign it an IP - which tricked the init scripts into thinking 'lo' was already enabled and so they left it alone, when in actual fact it still needed an IP assigned to it. Anyway, I've changed the init script to check whether 'lo' is lacking an IP instead, and it's now assigned an IP during boot, fixing all the problems. Yay! ;-) Cheers, Adam.