FOG 1.3.0 - SVN 6050 - "Please enter tftp server:"
-
Server
- FOG Version: 1.3.0 - SVN 6050
- OS: Centos 6.8
Client
- Service Version: N/A
- OS: Windows
Description
I know this isn’t very descriptive, but this just started happening January 5th, 2017; I believe I updated from 6030 to 6050 on the day before, and I have not been able to image. I first thought that our stateful-firewall was blocking this, but we disabled it for testing and we still had this problem.
Typing in the TFTP server - our FOG server - will attempt to connect it to (tftp://X.X.X.X/default.pxe).
tftp://X.X.X.X/default.ipxe. . . . . . . . . . .Connection timed out (http://ipxe.org/4c126835).
Will reboot in ‘10’ seconds. Press ‘s’ to enter iPXE shell.Any ideas?
It was not doing this on SVN 6030, only after the update to SVN 6050.
-
Typically this happens when you have multiple DHCP servers on your network.
-
@Tom-Elliott We only have one; we have two DNS servers. I use an automated script where it activates fog with
installfog.sh -y. Could it have possibly enabled DHCP through that? If so, is there a way to check or fix it easily? -
@ttrammell There’s a couple causes for this, but more often than not when this message is “suddenly sprung on” the issue is there was an accidentally introduced DHCP Server. DNS Servers have nothing to do with handing out the tftp files. You could potentially try Wireshark capture to see what’s going on.
The other way this could happen, I suppose, is the Option 66 is defined but Option 67 is not. (Option 66 is the IP to look at, while 67 is the file to use for booting).
-
FOG 1.3.0 does not assume Yes, for DHCP server. You could validate this though and yes it’s possible if in the past DHCP was enabled and was not told to be turned off during installation. You might try:
service dhcpd stop -
@Tom-Elliott Running that on the server came back with an error.
# service dhcpd stop dhcpd: unrecognized serviceAs far as everyone I work with knows, we haven’t introduced another DHCP server; will dig around and see if something is hiding on the network.
I will also take a look at Option 66 and 67 to make sure they are still set right.
Any other ideas to try while I am looking into this?
-
@ttrammell If your fog server, dhcp server and pxe booting client are on the same subnet we can use tcpdump to capture the pxe booting process to see if you are getting another dhcp offer packet.
- Install tcpdump on the fog server
- start the tcpdump program with the following command
sudo tcpdump -w output.pcap port 67 or port 68 or port 69 or port 4011 - PXE boot the target computer to the error
- Press control-c on the tcpdump program
- Either review the pcap file with wireshark or post the pcap here and we can review it for you.
-
Tom fixed me up; at least for now.
He can probably give you a much more elaborate explanation as to why it didn’t work; I kind of just watched in awe as he figured it out.
Edit: BTW, thanks again, Tom. Will post more on this if the issue comes back.
-
I remoted in with @ttrammell and we restarted the
rpcbindservice. While initially it didn’t appear to work, it suddenly started working again. I don’t know for sure if this was the rcpbind service restart or if there was indeed a rogue dhcp server. Hopefully, if the issue comes up again, we can probably pin it as a rogue dhcp server.In either case the devices are working right now, and I even helped correct an NFS mount issue :).
-
Marking as solved, for now. If it happens again just let us know.
Thank you,
-
Hi tom, porcierto my english is regular, so I’m using the google tool. I have the same problem, I’m using two dhcp servers, one in the range 172 … and the other one in the 10 … please explain the / tftpboot /
-
@alwos Two comments.
- Please open your own thread because your problem may not be the same.
- If you are more happy, use your native language to explain the problem because your post is not understandable.
