Solved PXE - Booting issue (strange)

[ITCC]

We had a fog server .032 on IP 192.168.47.254 (currently unplugged)
New server called (Latest SVN) on IP 192.168.39.6

One machine out there is stuck in a boot loop. Now the strange this is it’s getting to TFTP and it’s got the OLD server IP listed.
fails and restarts. also strange is if I pause boot at step of “Configuring” for a few seconds then continue it picks up the correct IP.
(it also fails if old FOG is plugged in)

I have never entered the IP of the old fog into the new fog
i have checked and no DHCP entries exist for this host.
I have deleted and recreate the host in FOG in case of custom loaders

Any Idea’s?

Please note this image is NOT from the console, just an example of the bootup issue location.

[Sebastian Roth]

@Wayne-Workman said:

@Sebastian-Roth Have you had any time to mess with this?

Have been on a short holiday far away from net and power… but working on it right now.

[Tom Elliott]

@Wayne-Workman I’m fairly sure Joe already is on it. Though of course Sebastian probably needs the “finishing” touches lol.

[Wayne Workman]

@george1421 said in PXE - Booting issue (strange):

@Wayne-Workman said in PXE - Booting issue (strange):

Check your DHCP option 66 and 67.

Is the dhcp discovery tool ready for prime time?

@Sebastian-Roth Have you had any time to mess with this?

[ITCC]

Tom Elliott, got me thinking about a “copy” of our windows DHCP server on another DC, that was a backup to when we had issues.
this DHCP is never to be switched on and it’s approx 3 years out of date.

Guess what, somehow (someone) has authorised this scope.

• Although, no stats showing used IP’s, when deactivated the PC continued beyond the loop.

Thanks to everyone who helped.

[george1421]

@ITCC And…

My next step is to confirm that everyone is in the same subnet then setup a packet capture into a pcap file so we can see where that alternate IP is coming from.

[ITCC]

we have a winner!

[ITCC]

have checked twice, no reservation.

Also works after pause, thought that would still resolve incorrect reservation info.

[george1421]

@ITCC Does this system have a dhcp reservation set on your dhcp server?

[ITCC]

it’s back in the office now and still doing it, so not switch equipment.

[ITCC]

[ITCC]

nope, one DHCP server

[Tom Elliott]

That, or, configure the other dhcp server to point at the new fog server as well.

[Tom Elliott]

I’m just going to guess here.

You have at least two DHCP Servers. One of those dhcp servers is responding faster than the other DHCP Server (which appears – from the info here) to be the one you “don’t” want to use.

Why not just turn off the other dhcp server?

[ITCC]

I’ll go get screenshot / PC

[george1421]

Ok you mentioned that you have one machine doing this? Is it safe to assume you have others working correctly? If so what is different (network wise) between the one that doesn’t work and the ones that do work?

[ITCC]

physical system…

[george1421]

@Wayne-Workman said in PXE - Booting issue (strange):

Check your DHCP option 66 and 67.

Is the dhcp discovery tool ready for prime time?

[george1421]

Just to be clear.

Is your issue booting virtual box or a physical system?
It would be most helpful if this is a physical machine to use a mobile and capture a screen shot of the actual error.
Might you have a dhcpProxy server (dnsmasq) running somewhere on your network?
You’ve confirmed and your dhcp server option 66 is the ip address of your new fog server AND dhcp option 67 is undionly.kpxe (not pelinux.0)

[Wayne Workman]

Check your DHCP option 66 and 67.