/Default.ipxe connection timeout on Dell only
-
I finally got my fog 1.2 server running on the latest version of Ubuntu Desktop (thanks to the help of forum members) but I am having an issue getting Dell computers to PXE boot. They pickup DHCP from my windows servers very quickly, but then give the error
“/default.ipxe… Connection timed out (http://ipxe.org/4c126035)”
Everything seems to work fine to get to the fog menu on HP laptops. I tried adjusting some network boot settings in the BIOS to no avail, as well as changing the default undionly.kpxe for option 67 to some of the others with no luck. Any ideas?
-
While on the FOG menu, could you go to Compatibility and choose the IP option and verify that it actually has a valid IP address.
During task booting, the client actually asks for an IP twice, and it sounds like you might be having issues with the 2nd IP acquire.
Also, a screen shot of the error would be very helpful, too (use a smart phone).
You might also check through our “working hardware” and “problematic hardware” lists in the WiKi.
-
@Wayne-Workman I did not see my specific model dell (optiplex 7020) as an issue on that compatibility list, not to mention, it works on our old fog server, and HP laptops. Not sure what you mean about “While on FOG menu” - I don’t even get to a menu. See screenshot below.
Thanks for your help
-
What I meant was the FOG boot menu. You said you can get to it fine on the HP laptops. You can’t get to it at all on the Dells? Are they set to UEFI ? Is Secure Boot enabled?
A lot has changed since version 0.32, sometimes notes are made in the hardware lists about quirks on various hardware.
-
What switches are you using?
I had a similar issue which was down to portfast not being enabled on the relevant switchports. I only saw this happen after I upgraded to 1.2.0.
-
I have a similar issue with one model of Dell laptops and solved it using this undionly.kpxe
Debug is enabled on dhcp and tftp and the script drops to a shell if it fails to tftp, for further troubleshooting.
The only modification is with the ipxescript:
#!ipxe :netstart dhcp && goto netboot || goto netstart :netboot ping -c 1 ${next-server} || goto netstart chain tftp://${next-server}/default.ipxe || shellAnd here are all to pxe files created with that script. pxe-files.tar.gz
–EDIT–
Forgot to include my issue that this solves.
We have Dell Inspiron 11z laptops that fail to get a DHCP address the first time iPXE issues the command. If the DHCP command is sent right after if succeeds and everything works normally.
-
You’ll likely find it simpler to just update to SVN/Trunk (if you can).
The problem is specific to what that NIC is expecting to download from. It is expecting a specific parameter to get the default.ipxe file.
Most systems work naturally when it is set to:
/default.ipxebut there are a few quirks where the nic is EXPECTINGtftp://${next-server}/default.ipxeBasically it’s expecting the implicit direction of protocol and where to get the file.
-
Also ensure your 7020s are on the latest BIOS release. I have seen a number of PXE issues in Dell systems that are on early editions of their BIOS, especially in 3020, 7020, and 9020s.
-
@need2 said:
Also ensure your 7020s are on the latest BIOS release. I have seen a number of PXE issues in Dell systems that are on early editions of their BIOS, especially in 3020, 7020, and 9020s.
The newer optiplexes (in my experience) auto update their bios. there’s a dell utility that, if installed, will keep it updated.
-
@Tom-Elliott Thank you thank you! - I did some searching and came across this: https://wiki.fogproject.org/wiki/index.php/SVN#Install_Subversion_2 I followed the directions and now everything is working perfect.
Thanks EVERYONE for all your assistance!
-
@cml Thanks for the link to the debug undionly.kpxe it helped us solve our problem right away. Turns out we had a rogue DHCP server that was issuing a second lease after just before the hand-off to the default.ipxe file. That lease didn’t have an ip for the tftp server. As soon as we shut it down we got a successful boot!
-
@Tyler-W.-Cox I’m a bit surprised that you had a second dhcp server running and you didn’t have IP conflicts or other random dhcp issues. But we are glad you got it worked out and have fog deployed successfully in your environment.
-
Not sure what the fix was, Second DHCP server? I’m running 1.4.4 and getting this same issue but I dont see anywhere what the fix was,
-
@tfoote01 The fix was to disable the rogue dhcp server that was giving conflicting information to the target computer ( in Tyler’s case )
If you are having a similar issue, please open a new thread with your specific details. We like to keep specific conditions to their own threads if possible.
