/Default.ipxe connection timeout on Dell only

[Trevelyan]

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.

[cml]

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 || shell

And 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.

[Tom Elliott]

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.ipxe but there are a few quirks where the nic is EXPECTING tftp://${next-server}/default.ipxe

Basically it’s expecting the implicit direction of protocol and where to get the file.

[need2]

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.

[Wayne Workman]

@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.

[A Former User]

@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!

[Tyler W. Cox]

@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!

[george1421]

@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.

[Tfoote01]

@george1421

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,

[george1421]

@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.