SOLVED TFTP Server requires manual entry
I have a FOG instance running as expected, except that it requires me to manually enter the TFTP server address. The unusual thing: the first pc I pxe boot from (vm or physical) pxe-boots fine…it is only subsequent pxe boots that require the TFTP address (once entered, it boots just fine).
I have uninstalled/reinstalled dnsmasq several times, and have mofified the ltps.conf per several forum post… but get the same results.
Host: Ubuntu 16.04
“Help me, Obi-Wan Kenobi…you’re my only hope”
I have no issues with mine but thank you
@Pikmin use this as a proven ltsp.conf file
# Don't function as a DNS server: port=0 # Log lots of extra information about DHCP transactions. log-dhcp # Set the root directory for files available via FTP. tftp-root=/tftpboot # The boot filename, Server name, Server Ip Address dhcp-boot=undionly.kpxe,,<fog_server_IP> # Disable re-use of the DHCP servername and filename fields as extra # option space. That's to avoid confusing some old or broken DHCP clients. dhcp-no-override # inspect the vendor class string and match the text to set the tag dhcp-vendorclass=BIOS,PXEClient:Arch:00000 dhcp-vendorclass=UEFI32,PXEClient:Arch:00006 dhcp-vendorclass=UEFI,PXEClient:Arch:00007 dhcp-vendorclass=UEFI64,PXEClient:Arch:00009 # Set the boot file name based on the matching tag from the vendor class (above) dhcp-boot=net:UEFI32,i386-efi/ipxe.efi,,<fog_server_IP> dhcp-boot=net:UEFI,ipxe.efi,,<fog_server_IP> dhcp-boot=net:UEFI64,ipxe.efi,,<fog_server_IP> # PXE menu. The first part is the text displayed to the user. The second is the timeout, in seconds. pxe-prompt="Booting FOG Client", 1 # The known types are x86PC, PC98, IA64_EFI, Alpha, Arc_x86, # Intel_Lean_Client, IA32_EFI, BC_EFI, Xscale_EFI and X86-64_EFI # This option is first and will be the default if there is no input from the user. pxe-service=X86PC, "Boot to FOG", undionly.kpxe pxe-service=X86-64_EFI, "Boot to FOG UEFI", ipxe.efi pxe-service=BC_EFI, "Boot to FOG UEFI PXE-BC", ipxe.efi dhcp-range=<fog_server_ip>,proxy
Can you share your ltsp.conf ?
I have seen this as well if I don’t have this line in my confg
@neiliob1973 “The best solution” depends on your situation. In a perfect world, you shut down other DHCP servers and let FOG handle it all and it will work out of the box basically.
However due to policies, preferences or certain restrictions sometimes you are stuck with another DHCP server, this is where dnsmasq comes in with proxy mode. (basically piggybacks the other DHCP server and sends only the PXE boot info)
I do think this may struggle or not work as expected if the original DHCP server is also sending PXE boot info, from what I remember anyway. And certain clients for some reason don’t like it very much either.
@neiliob1973 Don’t get me wrong, dnsmasq is not the wrong way in all cases. It can be very handy and does a lot of great things. But it’s not the default (as in run the FOG installer and don’t care about it) and can be fairly tricky to get to work the way you want it to. So I was just wondering.
See Wayne’s last post. More often than not we have seen such an issue when there is more than one DHCP server answering. Some clients are being confused by that.
@Sebastian-Roth I was told by a co-worker, who has worked with FOG a lot more than me, that dnsmasq was the best solution he had found to not have dhcp conflicts with the main router. I guess it wasn’t the best solution after all…I just went with it, and learned the hard way. LOL
Wayne Workman last edited by
Just adding a note here. Typically when the TFTP server address is requested at a prompt, this in the past has several times been due to multiple DHCP servers replying with different option 066 addresses. Typically, a rogue DHCP server or two redundant DHCP servers that are simply mis-configured.
@neiliob1973 Why do you use dnsmasq? Not that it is wrong to do but it’s not the typical setup and can cause issue. So I just ask to see why you are headed this way.
@Fernando-Gietz purged and reinstalled dnsmasq (per the method you referenced) …after a snapshot, of course.
Seems to be working properly now. There was also some extra, uncommented -therefore-“bad” code in the ltsp.conf file I had copied from another post (not yours).
New snapshot, made myself some notes…all is well!
Hello @neiliob1973 ,
which version of dnsmasq are you using? Do you use dnsmasq as proxy?
Some info about this problem: