From: John B. <joh...@so...> - 2016-02-24 18:37:09
|
I have created an Edubuntu 14.04.4 installation with LTSP service checked at installation. I built images for armhf, i386 and amd64, but configuration only uses i386. The last two days I have spent trying to figure out why thin client freezes (PXE). I struggled for 2 days and finally got it to work. I do think however that my struggles may contribute a little. So let me first explain what I have done and then make a few suggestions: Original installation got the client to boot and read the /ltsp/i386/pxelinux.cfg/default from tftp ("ok" displayed). Then after a few seconds, the screen is cleared with just a cursor in the left top corner. It stays this way. DHCP worked as expected (according to syslog) and with -vvv added to tftpd-hpa, I found that all tftp files were sent to the client. pxelinux.cfg/default, vmlinuz and initrd.img. After trying various things, I opted to disable isc-dhcp-server as well as tftpd-hpa and installed dnsmasq. I used settings I found on the web and tried again. This time round I found much more detail in logs and tftp did log the following: ... file /var/lib/tftpboot/ltsp/i386/pxelinux.cfg/C not found sent /var/lib/tftpboot/ltsp/i386/pxelinux.cfg/default to ... sent /var/lib/tftpboot/ltsp/i386/vmlinuz-3.13.0-79-generic to ... sent /var/lib/tftpboot/ltsp/i386/initrd.img-3.13.0-79-generic to ... Also, in stead of a blank screen, the client dropped to a BusyBox shell. I have seen this with Ubuntu 12.04 before but was always able to solve it by configuring nbd-server. I did take out the "authfile" setting in nbd-server config (based on information I got from the internet) and since nbd-server has basically no debug output, I added "prerun" and "postrun" commands that would simply log these events to a file. I tested nbd-server by using nbd-client from a different pc, and that worked for the image that is supposed to be mounted on thin client (/opt/ltsp/images/i386.img). I then checked the thin client (from the busybox shell) and there were no /dev/nbd devices. (also, my prerun debug function was not called). I executed an nbd-client command from busybox and successfully created /dev/nbd0 (and prerun added info to log file). The command I used was: nbd-client 192.168.0.1 -N /opt/ltsp/i386 /dev/nbd0 This is basically where I started writing this email, and then I found another page on the internet which helped me to determine what the server IP was that the client thought it should use for nbd. It turned out that a different DHCP server was handing out the address to the client. I never suspected this, because every single time the PXE client would display the correct information on startup. However, in my hunt for solutions I did find that DHCP DISCOVER does add flags of functionality required of the DHCP server (see allow booting and allow bootp in dhcpd.conf). So PXE client always got the right DHCP server. But when the newly downloaded kernel did a DHCP DISCOVER, obviously it did not require a DHCP server that supports thin clients. Or did it? So I shut down the other DHCP server on the network, and my thin client booted without problem. Also, I was able to switch back from dnsmasq to isc-hdcp-server and tftpd-hpa and it still worked. Based on what I have discovered I would suggest the following changes to the thin client kernel / LTSP server: 1) Client: Add a boot tag in the DHCP request - if a kernel was loaded from tftp server and it got that IP from a DHCP server, then surely that DHCP server is still around for the thin client kernel. See https://tools.ietf.org/html/rfc4578#section-2.4 2) Server: Comment out "authfile" option in nbd-server configurations. It adds complexity and if someone really needs it, they will have to edit the nbd-server.allow in any case. In stead, add a default nbd-sever.allow file with a comment stating that the authfile should be activated. 3) Server: Add -v to TFTP_OPTIONS in /etc/default/tftpd-hpa. A little additional debugging information can help enormously with an initial installation. 4) Server: Add prerun and postrun commands in nbd-server config to log nbd activiy. If a thin client is not booting properly, you need to know where to start looking. 5) Server: I would seriously consider moving to dnsmasq. It works pretty well and combines not only dhcp and tftp, but also allows the LTSP host to be a DNS server, thereby allowing a default DHCP configuration to have it as DNS server. 6) Server: One more thing - I searched quiet a bit for a DHCP configuration that would detect the client architecture and present it with the correct client image (armhf, i386, amd64 etc). There does not seem to be any information out there about such a configuration, but according to DHCP documentation, the spec allows for architecture to be specified by PXE client (even though ARM is not listed in the original spec). However, it would be great to allow a different architectures to be served by an LTSP server. Well this is it for now - I do hope someone finds this helpful in some way. Kind regards John Bester |