FOG-Client not booting up due to DHCP-reasons?
-
Hi,
I’m new with FOG and not very familiar with Linux, so please keep calm, if I am silly
I have a Debian machine with LXE-containers and in one of those a FOG-Server is running. Then we have a DHCP Server, which operates on a Windows Server 2016 machine (VM). I’ve configured the DHCP-Server as it was described in the wiki article about UEFI and LEGACY boot coexistence. It was running for a long time, but now, suddenly it stopped working. Here is what happens:- UserPC boots up and starts IPXE netboot.
- It fetches the right address (30.0.99.x) and asks the DHCP Server for bootimages.
- I think it gets the right image but then asks for a tftp-server.
- and stops
if i enter the right address here (DNS-name or IP) it doesn’t work. If i cancel the bootprogress at this point with strg+c i can switch to the PXE-console. If I type “route” in there, it shows me a 192.168.0.x IP-address… So I think it can’t reach the TFTP-server, as it is in the wrong subnet? Pictures will follow (as i have to reboot this machine to get them
)
-
There is a couple of things you can test.
Install the tftp client feature on a windows computer, drop the windows firewall temporary and then use the command line utility tftp to download undionly.kpxe to this second computer. We are testing to ensure tftp is working as expected on your network.
Is your fog server, dhcp server, and pxe booting client on the same IP subnet? If so, lets ensure that your dhcp server is telling the pxe client the right information needed to boot. https://forums.fogproject.org/topic/9673/when-dhcp-pxe-booting-process-goes-bad-and-you-have-no-clue Unload the pcap to a google/dropbox/onedrive and share it public read-only. Post the link here or IM me the link and I will take a look an what the client is being told.
-
Hi,
thanks for your response. I’ve already checked TFTP connection to the FOG server. It works and I get the different boot images, as I request them via a TFTP-client.
FOG (Debianmachine), DHCP (Windows Server 2016 machine) and client (Windows 10 machine) are/should be on the same subnet (at least the first line at booting PXE shows the right address for the client). As described above, the IP-address changes to a not valid address once I get into the PXE-shell, after PXEbootup stopped working due to the “Enter TFTP-server:” thing…
Long story short: FOG is working again for me. I don’t know why and I don’t know how. Is it possible, that Windows Server 2016 DHCP-Server is not working correctly, when there are no free IP adresses to lease? I’ve made fixed reservations for every machine in our network, cause we always had problems with private mobile phones fetching too many IP adresses, so there were no free adresses for relevant machines like workstations. Therefor our whole subnet is “full” as in it is full of reservations (including the FOG machine and the workstation I had problems booting up FOG). The DHCP-service also provides an abundance of messages, crying out loud that he is full, but to be honest: I don’t care about this, as it is intended plus there seems no way to configure the threshhold(default he starts sending messages at 80% “full”) where messages should be generated. So…ye…micorsoft…yipie… -
@manoca said in FOG-Client not booting up due to DHCP-reasons?:
Is it possible, that Windows Server 2016 DHCP-Server is not working correctly, when there are no free IP adresses to lease?
Yes I’d say so! PXE boot needs IP addresses to hand out to work properly.
-
@manoca There are 2 things here.
-
The fog server needs to be at a static IP address once fog is installed. This “static” IP can be physically setting the FOG server at a specific address or by IP reservation. The key is for the FOG server’s IP address to never change once FOG is installed.
-
PXE booting relies on being able to get an IP address from a dhcp server. This can be via reservation or normal dhcp address pool. Either way during dhcp startup the boot information is transferred to the target computer. I have seen (but don’t know why) the pxe rom will get one IP address and iPXE will get a different address from your dhcp server. This may be your issue or your dhcp server may not be sending out the right pxe boot information.
Since all devices are on the same subnet I would like you to follow this tutorial to capture the dhcp booting process of your target computer: https://forums.fogproject.org/topic/9673/when-dhcp-pxe-booting-process-goes-bad-and-you-have-no-clue Upload the pcap to a file share site and paste the link here or IM either myself or Sebastian directly and we will take a look at what your dhcp server is telling the pxe booting client.
-
-
@george1421
thanks for your reply. as mentioned before, the pxe boot with fog works now, so the problem is not reproducable anymore. i expanded the ip handout range for a few addresses on dhcp server. since then it seems to work. so i can’t give additional debug information, sorry. -
@Sebastian-Roth
the ip handout should work properly, as machine plus fog server have fixed reservations on dhcp server. i can also see the client getting the right address on the first lines of pxe bootup console. but after that it shows configuring eth0 again. so i think it want’s to run dhcp request again too? and that’s the point where i think my dhcp server does not work properly… -
@manoca A client does request an address form the DHCP server on PXE boot three times in the FOG world. First when the network PXE ROM comes up for initial PXE booting, second we load iPXE doing another DHCP request as it cannot properly take over the information from the first round and third we load the Linux kernel which is doing DHCP again.
I’d advise you to take a picture of the issue on screen so we really know exactly what you see! It’s a bit of a guess work otherwise.
-
@Sebastian-Roth Thanks for your reply. Interesting to know, how FOG is starting up. As mentioned before, I think the issue was, that DHCP-Server couldn’t hand out a dynamic IP. So one of the last two requests seem to request with the wrong MAC address, as my DHCP has fixed reservations for the right MAC and should have delivered the right IP. Anyhow, as also mentioned before, the bug (or feature) is not occuring anymore as i freed up some space for dynamic hand out. So sorry, but I can’t provide additional Screenshots/Informations…
