Ubuntu 14.04 thin client NBD problem

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


------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140
_____________________________________________________________________
Ltsp-developer mailing list.   To un-subscribe, or change prefs, goto:
      https://lists.sourceforge.net/lists/listinfo/ltsp-developer
For additional LTSP help,   try #ltsp channel on irc.freenode.net