Troubleshooting LTSP
Sometimes when administrating your LTSP system, you may come across problems that you can't solve immediately. This section has been written to try to give some helpful hints about how to diagnose and fix common LTSP problems. The LTSP Web site, www.ltsp.org, has a large wiki and knowledge base to help you find answers to your LTSP problems.
The Computer Is Not Obtaining an IP Address
If your client machines are not receiving IP addresses, it is likely that there is a problem with the DHCP server. In order to check this, you must load a terminal window and run the following command:
pidof dhcpd3 2&>1 >/dev/null && echo OK
If this shows the result is okay, the problem lies elsewhere. If the result shows that the DHCP server is not running, it is time to check the DHCP logs for errors. To do this, you must restart the DHCP server and then view the logs. Restart the server by using the following command:
sudo /etc/init.d/dhcpd3-server restart
If at this stage you see a FAIL message on starting the DHCP server, you know that there must be a problem with the dhcpd configuration. Checking the logs in the way shown should lead you to the problem. You can easily see the last errors that the dhcpd server had by running the following command:
tail /var/log/daemon.log
A variety of problems can be shown by using this method, and after you have a better idea of what the problem is, you may be able to solve it yourself. You can also contact the Edubuntu team for help by using the information provided at the end of this chapter.
NFS Server Is Not Responding
If your clients exhibit an error, similar to nfs warning: server not responding, it is possible that the kernel is using too large a block size for the NFS packets. In essence the kernel uses a 32K block size, which must be broken down into 1,500 byte datagrams. Since this results in a large number of small datagrams being sent, the client can time out before receiving all the data. Fortunately, the fix is simple enough.
You must load the file /var/lib/tftpboot/ltsp/pxelinux.cfg/default so that it can be edited. To do this you can use any of the methods previously described in this chapter. Once the file is open, there is a line beginning with APPEND; to the end of this line, you must add one of the following:
NFSOPTS="-o nolock,ro,wsize=2048,rsize=2048"
or:
NFSOPTS="-o nolock,ro,proto=tcp"
After this, your clients should be able to boot normally. If you are using Etherboot or require more information on this, you can find help on the LTSP wiki, under the Troubleshooting section.
VMWare Client Crashes While Booting
Some people use VMWare, a virtualization suite, to test various aspects of their setup before they roll it out. However, you may find that VMWare clients are unable to boot properly. This is a problem with the graphics driver and can be solved simply by taking the actions described in the previous section, but instead of adding the NFSOPTS line, simply remove the word splash from the APPEND line. This will remove the loading screen from Edubuntu and should make your VMWare clients bootable again.
Some Intel Boot Agents Will Not Boot at All
Some Intel Boot Agents have a bug that makes them unable to boot at all if your Edubuntu server (TFTP server) is different than your DHCP server. The reason for this is that the Intel Boot Agent assumes wrongly that the TFTP information resides on the DHCP server, which of course it doesn't. One way to work around this is to make a mirror of the /var/lib/tftpboot/ directory on the DHCP server and install a TFTP server on that machine to serve that directory. Remember that if you update the NFS chroot, you must then update this new mirror. It is also possible there is a firmware update for your NIC.