iPXE Error 0x040ee119: Tried all forum suggestions
-
OK, I looked up that error and it basically says (translated) that ipxe could not configure the interface (i.e. acquire an IP address).
Following along with Tom’s post.
Is your dhcp server located on vlan 71 or is it on a different vlan?
If no, did you setup the dhcp-relay/dhcp-helper for forward dhcp requests from this vlan to your main dhcp server?
Does your dhcp server have a scope setup for this vlan?
If you plug a physical computer into this vlan does it pxe boot OK?
Did you setup vlan 71 specifically for FOG (i.e. is this a new VLAN configuration or has it been working for a while)?Wait, thinking about this, you pxe booted so dhcp IS working because you are in the ipxe console already. If you press the s key at the above error message it should drop you to a console prompt. keying in dhcp should start the dhcp acquisition process again. If this was a physical machine I would suspect spanning tree here.
-
Yes, we have Dell switches with a global ip helper-address. I am using our Windows server as the DHCP server which serves DHCP to all of our VLANs. I am able to PXE boot to our Foreman server without any issues but Foreman does not use iPXE. Here is my DHCP setting in Windows:
-
@ellusiontech So ALL systems are reaching the same DHCP server at IP 10.20.32.199?
-
That is correct. This is at our coporate office. We only have 3 VLANs at this location.
-
@ellusiontech If this is for your vlan 71 scope then I see an issue.
The IP address being detected by the vm that is booting is 10.90.71.x and your dhcp server is on 10.20.32.199. So there is a router between.
Your option 003 (assuming this is the scope for vlan 71) is pointing to a device not on vlan 71. (10.90.100.1) I would expect this to be 10.90.71.1 or similar.
Is this a new vlan setup just for fog and pxe booting this client?
In regards to your dhcp-helper you need to tell it to monitor each vlan and relay onto the dhcp server. If this is a new vlan I might suspect that this was overlooked.
-
@ellusiontech and can I assume that 10.90.71.240 IS your fog server?
Just realize this is not (yet) a FOG issue, but more of a dhcp/pxe boot part. We’ll get this sorted out we just need a few more details on your setup.
-
You are correct, the Fog server is working great, I can get clients to check in like they should using the Fog client. I have had no config errors and setup seems correct, my main issue is the iPXE issue. So basically my setup is quite simple. Fog server running on VMware and client computers on the same vlan both physical and virtual. The DHCP server is in a separate VLAN do to legacy items. Everything is connected to a stack of Dell switches. I did read a lot about Portfast being an issue but did not think this would come into play if both the server and client on on the same VMware host. If the virtual worked and the physical did not I would say yet must be Portfast issue. Thanks for your help, I really want to use for over WDS.
-
@ellusiontech Are you using a spare physical nic for this VM? For example, if you have 4 nics, and each are assigned their own network, is the client nic the only network used by this nic?
-
No, it is using the VMware virtual switch which is basically used to to access the network through the dell switches. There are 4 nics on the host server 2 which are used as trunked network access and two that are used for management. Is iPXE the only option for PXE boot with Fog? As stated earlier we have a Forman server which is identical CentOS7 box running PXE and if I switch to that as the TFTP server the virtual and physical machines PXE boot with no issues. When switching back to Fog iPXE I get the error that you see in the picture. I am going to setup an isolated environment to see if I have the same issues.
-
@ellusiontech Are your switches setup for STP?
-
If this is a spanning tree/portfast issue this is kind of easy to find out. Just hit ‘s’ as you are asked on the screen. Then wait for another 30 seconds (just to make sure) and type
dhcpon that iPXE shell and hit ENTER. Does it fail the same way or is it working then?I don’t think this is playing a role at this stage (maybe later when iPXE tries to load the kernel via HTTP) but why do the boot screens shot GATEWAY IP: 10.90.71.254 when your windows DHCP setting shows option 3 (router): 10.90.100.1??
-
I tested out Portfast and it is not the issue. Even with Portfast on I get the same error. The screen shot that I posted from DCHP was from another scope that is why it shows that for the router. Here is the correct scope:
-
Also you see undionly.kkpxe because this was another suggestion on the forums to try.
-
@ellusiontech OK now that we have a bit more sane information (don’t get hung up on my words). What is 10.90.71.254, is it an L3 (switch) router or a some other router?
Does it have or use ACLs or firewall rules to control the traffic flow? I just want to be sure that there is nothing blocking the communication between these two subnets. 10.20…x.x and 10.90.71.x
If you plug a windows PC into the vlan 71 subnet does it pick up a dhcp IP address OK?
From that PC can you ping every device on each of the other vlans?
Right at this point I can’t tell if this is a networking problem or a vmware issue. We have to start with some known good systems and then work our way to where the problem isn’t. You’ve mentioned this Forman server a few times. Is this server in the same subnet as your FOG server (I’m concerned that its doing something like proxy dhcp that adding some unexpected information to the ipxe boot process).
-
@george1421 From what we see in the screenshots the VM is picking up an IP when the (virtual) PXE ROM is first trying to netboot. So it seams like getting an IP via DHCP is not generally impossible. It’s just iPXE not getting one when trying next.
@ellusiontech Have you tried my suggestion on entering the shell and trying to get an IP via the
dhcpcommand? Also try the iPXE commandifstatwhile you are at it. Maybe this can shed a light on what’s wrong. Two more things I have in mind. Try netbooting a normal PC on that VLAN and see if it works. As well install wireshark on your VM server and capture packets to see if the real traffic (I suggest display filterbootp || tftp- possibly we won’t see TFTP traffic as this might be taking the internal route but DHCP for sure) -
-
@ellusiontech Any news on this? Were you able to capture a packet dump using wireshark? Thanks for testing in the shell and sending a screenshot. Seams like this is NOT a spanning tree issue. But I really wonder why DHCP is fine on the first go, then downloads iPXE via TFTP and fails on the second DHCP (send by iPXE)?
