PXE seems to work but Fog Cloning menu not displayed.
-
@jmcg Well the first thing I noticed is that you are using syslinux to pxe boot this system. The pelinux.cfg search path indicates this.
Please confirm what your dhcp option 67 is, for a bios (legacy) client this boot file should be undionly.kpxe.
Is your FOG server 192.168.1.16?On a side note, you may want to consider FOG 1.3.0 RCx series if you need NVMe disk support, GPT format, or Win10 support.
-
@george1421 Yes the FOG server is 192.168.1.16.
Under the ip dhcp pool LAN I enter option 67 ascii undionly.kpxe and I received the same results.
-
@jmcg The short answer is its not possible, the screen shot is of syslinux boot not iPXE which FOG uses.
OK we need to understand what is going on in your network. This is pretty easy if the pxe booting device, your dhcp server, and your fog server are on the same subnet. Please install tcpdump on your fog server while I get the command you need to capture a pcap file.
-
OK I want you do this this process.
- Install tcpdump on your fog server.
- key in the following command on your fog server console.
tcpdump -w output.pcap port 67 or port 68 or port 69 or port 4011 - When tcpdump starts, then pxe boot your target computer until you reach the error.
- On your fog server press ctrl-c to exit the tcpdump program.
- Either review this pcap file in wireshark or post it here an I will take a look at it. If you don’t have enough credits the FOG Forum may keep you from uploading the pcap file here, so you will then need to use something like dropbox, box.com, or a google drive and share out the pcap file.
-
@george1421 tcpdump is available on the server.
-
@jmcg said in PXE seems to work but Fog Cloning menu not displayed.:
@george1421 tcpdump is available on the server.
OK do the process I outlined in the previous post. You can either review the pcap with wireshark or I can.
What I’m suspecting is that another dhcp server is talking to the client that is where its getting the pelinux.0 file name and not undionly.kpxe.
-
@george1421 So, I ran the tcpdump (issue.pcap is the first capture). I can see that the fog server 192.168.1.16 is trying to get to a dhcp server (10.122.16.4) which the fog server cannot reach. The 10.122.16.4 server is the dhcp server for a LAN I have to connect to in order to have internet access for updates for fog, ubuntu, etc. At the time of the capture there is no physical connection to the 10.122 LAN, so I’m not sure why it is attempting to go to that server.
So, I issue a sudo dhclient -v -r eth0 on the fog server to release the dhcp lease. I then issue a sudo dhclient -v eth0 to get a new lease from the only connected dhcp server 192.168.1.1 .
I then ran a new tcpdump on the fog server and start up the dell laptop. that is the issue2… pcap . I look at that trace and I see that the fog server 192.168.1.16 is still trying to access the wrong dhcp server, which isn’t even connected to the server.
I tried to upload the .pcap files and I get an error that I don’t have enough privileges to do so.
-
@jmcg Can you upload that pcap to an external service like dropbox or google drive? If you use google drive make sure its world readable.
-
-
@jmcg ok looking at the first pcap.
I see a host 00:19:b9:61:fe:d7 requesting a dhcp address using a discover (frame 16)
Then 2 devices respond to it with an dhcp offer frame 17 and 18.
The first one is 192.168.1.16 who isn’t sending a next server address (dhcp option 66) but it is sending a boot file name of pxelinux.0 (ah ha!!).
The second one is 192.168.1.1 that is sending a next server of 192.168.1.16 with a boot file of undionly.kpxe.
Then a few frames down the client is sending an ack packet back to 192.168.1.1 to reserve its IP address.
Then I see the client 192.168.1.21 request and download pxelinux.0 from 192.168.1.16Except for 192.168.1.16 sending out a bogus dhcp offer confusing the client everything appears to be working.
I guess you need to answer the questions.
- Why do you have 2 dhcp servers on your network (192.168.1.1 and 192.168.1.16)
- 192.168.1.16 IS sending out pxelinux.0 for the boot file name
- 192.168.1.1 IS sending out the right next server 192.168.1.16 and boot file undionly.kpxe. (so running the dhcp server on the FOG server is just causing a conflict)
- If you would have used the filters I provided we would only see dhcp and tftp stuff and not things we shouldn’t see in your pcap. (you control the pcap file and probably should take it down once we are done debugging).
-
@george1421 Well I have to admit that I am confused about the dhcp server on 192.168.1.16, which is the fog server. I can not find an instance of it on the server, yet I see the dhcp offer in the pcap file. I looked for the isc-dhcp-server in the ubuntu server but can’t see it running nor can I stop it. So I am unsure what is running as a dhcp server on the 192.168.1.16. That needs to be cleared up first.
Any suggestions on how to determine what is going on?
-
@jmcg Did you load dnsmasq on that server?
Was that server setup specifically for FOG or was the server recycled?
-
@jmcg
service dnsmasq status;service dhcpd status -
@george1421 It was a new server. So, now I get to the FOG menu.
The issue was that I mikstakenly installed dnsmasq because part of the description (Using FOG with no DHCP server - but I am using dhcp just not on the FOG server) lead me to believe I needed it. But I only went looking for solutions when I couldn’t get to the FOG menu. The reason I couldn’t get to the FOG menu during iPXE was that I had the wrong file name in option 67. So, in my attempt to troubleshoot and apply possible fixes I caused another problem. So this issue is fixed. I have to remove dnsmasq service. The system seems to be fully functional.
Thank you for the assistance. Now to continue on with my project.
-
@jmcg I’m glad you have it worked out. That is why the pcap is so valuable so you can actually see what is going on in the wires and not just guess.
Good job, happy fogging (if that is a word).
