Results 1 to 2 of 2
Enjoy an ad free experience by logging in. Not a member yet? Register.
- Join Date
- Jul 2007
diskless client : weird netbooting behavior
I set up a diskless client on my network. Both client and server are running debian unstable with a custom kernel (2.6.21-bootsplash). The server runs all services needed : DHCP, NFS and TFTP.
Now, the set up works fine since I can boot the client successfully off the server (PXE boot, then nfsroot) BUT! The client boots successfully only once every two attempts. So I have to boot twice every time I need to boot the client since it will fail first, with the following message :
server xxx.xxx.xxx.xxx not responding, still trying.
(xxx means server IP address).
And the funny thing is that the client did get an IP address, got the initrd and vmlinux through TFTP, and even started booting the real root filesystem through NFS. So the problem occurs after the switch to nfsroot.
I tried to ping the client from the server during the boot process. All I could find was that eventually, the client does not respond, as ping stops reporting packets back. If I reboot the client, then it works perfectly. If I then reboot again, it fails. The dmesg, syslog and other system messages are of no help. They do not report any particular error message when the client suddenly gets kicked out of the network during the boot (that's my only suspicion : for some reason the client is no longer visible on the network). Looks to me like the client's network interface gets its configuration screwed ocne every two boots. Don't know why ...
Did anyone observe such a weird behavior ? If of any relevance I can copy/paste the server's DHCP, NFS and PXE conf (?).
Thanks for any tips, I am out of imagination.
- Join Date
- Jul 2007
guess I was not totally out of imagination
I solved my problem by removing eth0 from /etc/network/interfaces on the client, so it would not be reconfigured a second time during the later boot stage. Since I had the interface built in the kernel, it was already brought up at the very beginning of the boot process, which was all I needed.
Doing so really solved the failed boot attempts