© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
73416ba
(Get the code!)
RE Thomas Hood's #120: That is very interesting, though I admit it is near the outer limits of my current understanding.
To address the only questions above:
>> The problem is that the LTSP client, after successfully getting
>> DHCP assignments, fails to download the pxelinux boot image.
>> It reports "PXE-E32: TFTP open timeout."
>> To be more specific on the DHCP assignments, it identifies
>> my hardware router as the DHCP server and the default gateway.
>> It identifies the LTSP server as proxy and boot server.
> Is your LTSP server running Ubuntu and standalone dnsmasq? Then shouldn't the client use your LTSP server as the DHCP server?
The LTSP server is running Lubuntu with the default network configuration, whatever that is. I understand you to be saying that this would be a standalone instance of dnsmasq started by an initscript, prepared to handle DHCP and TFTP. And apart from that, network-manager starts another instance of dnsmasq to handle DNS.
Regarding whether the client should use the LTSP server as the DHCP server: I imagine that it is prepared to handle DHCP, and probably does in a standard LTSP setup with 2 NIC's and the client connected to the second NIC, but in this LTSP-PNP setup with a single NIC, the client is connected to the router, and the LTSP server defers to the router handling DHCP.
------------------
Your explanation is very interesting because it explains why my blindly-applied work-around is effective. (And kudos to Simon Kelley who is working to make it possible for everything to work as configured right out of the box.)
But I don't understand what you said about standalone dnsmasq conflicting with network-manager's instance of dnsmasq when /etc/dnsmasq.
Apart from not understanding how the conflict arises, I wonder: Should this conflict be manifesting itself somehow? Everything seems to be working right now.
And would disabling network-manager's DNS-handling instance of dnsmasq then result in the need to set up an alternative DNS handler?
I'm willing to apply another solution blindly, as I did in removing /etc/dnsmasq.