Dell OptiPlex 7050 fails to pxe boot
-
I was having the same problem and I have done the following in an attempt to resolve it.
Upgraded Ubuntu to 16.0.4
Upgraded FOG to 1.4.4
Current Kernel is 4.11.0PXE boot on Dell OptiPlex 7050 fails on configuring DHCP.
Dell has a walkthrough article on their site (http://www.dell.com/support/article/us/en/19/sln301475/fog-imaging-walkthrough?lang=en) that I’m going to try next, but thought I would update this existing post with continued problems under current software.
Also, during the FOG upgrade, the config.class.php file had the MySQL password enclosed in double quotes, which MySQL doesn’t like, apparently. Changing to single quotes and reloading apache2 (service apache2 reload) resolved the problem and allowed me to continue with the FOG install/upgrade.
-
[Moderator note: I forked your post from the original one because your conditions are different than the OP of that thread]
For your issue, please post a clear picture of the exact error you are seeing. The context of the error is almost as important as the error message itself.
But without seeing the actual error message, I might place a (dumb) unmanaged switch between the pxe booting computer and the building switch and test to see if you can acquire a dhcp address then.
-
@coh_is said in Dell OptiPlex 7050 fails to pxe boot:
Dell has a walkthrough article on their site (http://www.dell.com/support/article/us/en/19/sln301475/fog-imaging-walkthrough?lang=en)
That article is old and will not add much value to FOG 1.4.4, if you are not careful you can mess up FOG 1.4.4 if you follow the instructions to the letter.
-
Upon initial PXE connection the computer did receive an IP address, but the process terminated with the following message on the iPXE screen:
Configuring (net0 <mac address>)…No configuration methods succeeded (http://ipxe.org/040ee119).
I checked this link and will be looking over the information provided.
However, prior to upgrading Ubuntu to 16 and FOG to 1.4.4, we were on the Ubuntu 14 and FOG 1.2, and were receiving the same error message as the OP in this post: https://forums.fogproject.org/topic/10104/compatibility-optiplex-7050-test-network-fail
-
@coh_is So after documenting the iPXE error, I located another post on this forum with the same problem. In that post was a reply by you (george1421):
@george1421 said in IPXE Error: No configuration methods succeeded:
@Gary-Kulovics A screen shot of the actually error would be helpful to know exactly where in the process its failing.
What model of dell laptop are we talking about here?
The network port where this target computer is plugged in, do you have spanning tree enabled on that switch port, if you do are you using one of the fast spanning tree protocols (port-fast, fast-stp, rstp, [or the other one I can’t remember immediately])?
If you place once of those small unmanaged “cheapie” switches between the building switch and the target computer does it boot correctly?
If your target computer is in bios (legacy) mode then you will want undionly-(k)kpxe. That has worked on every dell device I have in my fleet.
I used the information in the last line of you post to change the dhcp bootfile name to undionly.kkpxe from undionly.kpxe and retried. Now I am able to get past this initial problem and to the FOG menu, but now I have a new one.
After selecting either of the host registry and inventory options, it looks like FOG is unable initialize DHCP and get an address. I fired up Wireshark on another system and did not see any additional DHCP requests coming from this target system. I did, however, see the initial DHCP request iPXE had made when it received an IP address from the DHCP server.
Headed back to the drawing board.
-
@coh_is Can you check:
FOG Configuration Page->FOG Settings->Web Server->FOG_WEB_ROOT (or expand all FOG Settings and search for FOG_WEB_ROOT). Make sure the defined value is /fog/?
-
@Tom-Elliott I checked the setting and it is /fog/
-
@coh_is said in Dell OptiPlex 7050 fails to pxe boot:
Upon initial PXE connection the computer did receive an IP address, but the process terminated with the following message on the iPXE screen:
Configuring (net0 <mac address>)…No configuration methods succeeded (http://ipxe.org/040ee119).Can you place a (dumb) unmanaged switch between the pxe booting computer and the building switch.
Your conditions tend to make me think you have spanning tree turned on (a good thing), but you are not using one of the fast spanning tree protocols (not such a good thing). Standard spanning tree takes 27 seconds to start forwarding data. By 27 seconds come around FOG has already given up trying to boot, yes its that fast…
-
@george1421 I have two switches that I have confirmed have empty configurations with no spanning tree, switchpotrt
or VLAN information. I, also, disconnected the core switch from the rest of the network, after the target system obtained it’s initial DHCP address for PXE. We still had the same problem. Interface eth0 does not appear to be initializing and, if it is, it is unable to obtain a lease from the DHCP server.I just realized that both switches may be missing their helper address information for DHCP. Could this be contributing to the problem?
-
@coh_is Well an unmanaged switch is the best test.
What happens here is that as each kernel is loaded it causes the network link light to wink (momentarily turn off and then back on). This will happen 2 times during the booting process.
The first wink happens between the pxe rom on the network card and the iPXE kernel loading and then between the iPXE kernel and FOS. As each kernel is loaded it will attempt to contact the dhcp server for its address since it knows nothing about the previous kernels network settings.
The problem with spanning tree is that it take 27 seconds to start forwarding data. So each network wink resets that 27 timer. Inserting the unmanaged switch between the target computer and the building switch keeps the building switch link up the entire time. Typically the unmanaged switches don’t have any concept of spanning tree.
-
@coh_is said in Dell OptiPlex 7050 fails to pxe boot:
I just realized that both switches may be missing their helper address information for DHCP. Could this be contributing to the problem?
The IP helper settings are typically done on your core router (or L3 switch acting as a router). These dhcp helpers will forward local dhcp requests to your remote dhcp servers. Its either all or nothing with the relays. You will either have dhcp or no dhcp if they are misconfigured.
-
@coh_is said in Dell OptiPlex 7050 fails to pxe boot:
I just realized that both switches may be missing their helper address information for DHCP. Could this be contributing to the problem?
Possibly yes but very hard to say as we don’t have any information about your network structure/setup. But as you are saying that you get to the FOG menu now and see a DHCP issue after this I kind of doubt that missing ip helper settings are causing this.
From what I can find on the net there seems to be an Intel I219-LM (PCI ID 8086:15e3). Possibly we had a very similar issue here in the forum a year back already: See my post here: https://forums.fogproject.org/post/80802 and of course all the rest of this discussion. Unfortunately it looks like we never got to finish testing and this might still be an issue. Not sure though.
-
So it looks like I have resolved my DHCP problem with this host.
After looking over the post Sebastian Roth posted, I confirmed that we have the exact same model NIC and problem. Then while reading the post by george1421 regarding Spanning-Tree, I re-checked all switches in my imaging room. None of the ports on the switch at the host had spanning-tree portfast enabled. I left this off all ports in an effort to have as plain of configuration as possible.
I went ahead and enabled spanning-tree portfast on the port the host was connected to and re-tried FOG. This time it went right to the host registry and inventory process without stopping.
For now, it looks like I am back in business.
Thank you all for your assistance.
-
@coh_is That is great to hear you have it working.
For the record this wasn’t a FOG issue, but an environmental/infrastructure one.
