New machines not finding PXE info

[forte647]

Hello. I’m having an odd issue with a specific model of HP laptop getting its DHCP info in PXE boot. I’ve been using Fog to image our HP Probook 4545s laptops just fine. We’re switching over to HP Probook 455 G3 laptops.

Only thing that has changed is the laptop model

The old 4545s laptops will still work as intended.

Any ideas on what to try? Let me know if more information is required.

[Tom Elliott]

Try the undionly.kkpxe file instead of the undionly.kpxe file?

[george1421]

If the switch to the undionly.kkpxe doesn’t work please try the following:

As a test install a dumb / unmanaged switch between the building switch and the target computer. See if this corrects the behavior.

We are seeing an issue between these new realtek chips and smart / advanced network switches like the Catalyst series. Is your building switch a Catalyst switch?

We can discuss other options once we identify if the dumb switch resolves your issue.

[forte647]

Changing the boot file to " undionly.kkpxe" didn’t seem to change anything. The old laptops will still find Fog. New ones will not.

We have 2 managed switches between the client and the DHCP server with nothing special set (still default settings). I’ll try plugging in two flat switches in a moment when no one needs the network.

Thanks for your help so far. I’ll be back momentarily with a results.

[EAHarvey]

Reboot your server or restart your DHCP service.

[EAHarvey]

@EAHarvey My server will sometimes do this and not give address.

[Tom Elliott]

Try changing the boot file.

I just saw this issue on brand new HP ProBook 645 G2 and the fix for us was to use the ipxe.pxe file.

[EAHarvey]

My bad. I see it’s pulling an address.

[Tom Elliott]

@EAHarvey It’s pulling IP in PXE, but iPXE is failing to get IP.

[forte647]

Thanks for the suggestions. Unfortunately I was not able to get my hands on a reliable dumb switch. All our old dumb switches seem to have port issues and I cannot reliably rule out an issue with our switch.

I did try switching to ipxe.pxe and that worked. It will try and configure (net0 00:00:00:00:00:00) and then fail. It’ll try again with the correct address and succeed right after.

Another thing I tried in case this is helpful to anyone:
I grabbed this version of ipxe.iso from this page https://svn.code.sf.net/p/freeghost/code/trunk/packages/tftp/ and booted from that CD and it worked.

But yeah, changing the bootfile to ipxe.pxe works for the new and old HP machines. Thank you all for your help.

[george1421]

@forte647 OK, while you have a solution its not a real fix (IMO).

What I think is going on is one of these:

1. The target computer will wink (momentarily drop and reconnect) the network link during the transitions between PXE (ROM) and iPXE and then between iPXE and the FOS (Fog OS linux) kernel starting. This is because the network adapter is reset between each kernel loading. If you don’t have fast spanning tree, port fast, or RSTP enabled then the port doesn’t start forwarding for 20 some seconds after the link light turns on. So if this is the case ensure that your network ports are using one of the fast spanning tree protocols.
2. We’ve also seen the green ethernet (802.1az) cause similar issues with the network wink between kernels. Disable any green ethernet commands.
3. The network adapters are negotiating the wrong network speed between the switch and the target computer. Fixing the network speed in the switch at 1GbE typically resolves this issue.

Placing a dumb switch between the building switch and the target computer breaks (masks) the above bad behavior. Beyond that I’m pretty sure this issue is a network issue and not an iPXE kernel issue.

Just to collect a bit more information on this network adapter, on a windows computer will you collect the vendor and device ID? You can access it through the hardware manager. The hardware id will be vend_xxxxx&dev_xxxxxx

[Wayne Workman]

@george1421 #wiki worthy.

[george1421]

@Wayne-Workman actually I though Sebastian had a wiki page with this outlined. But again I’m wiki search challenged today. I know I saw at least one of his posts that had this lined out point by point.

[Tom Elliott]

@george1421 I ran into exactly the same problem it had a dumb switch connected between. It has to be a driver issue.

[forte647]

@george1421 i have 4 instances for “Hardware ID” for my NIC on the new laptops.

PCI\VEN_10EC&DEV_8168&SUBSYS_80F0103C&REV_15

PCI\VEN_10EC&DEV_8168&SUBSYS_80F0103C

PCI\VEN_10EC&DEV_8168&CC_020000

PCI\VEN_10EC&DEV_8168&CC_0200

is this what you were asking for?

[george1421]

@forte647 Yes that is the number.

For future reference, the nearest chip set I can track it down to is RTL8111B

[Sebastian Roth]

@forte647 Too bad you got one of those ugly NICs running the r8169 driver. We have seen a lot of trouble with those lately. If I remember correctly this was an auto-negotiation issue most times. As George already said, can you try setting link speed to static GbE or 100M Fast Ethernet on your managed switch and try again? Please keep an eye on the link LEDs (switch and NIC) as well.

Are we allowed to use your picture in the wiki once we figure this issue out? As you are within a private IP range this shouldn’t be an issue privacy wise. Or we can mask the IP and MAC information if you don’t want to see those in the wiki.

@george1421 The article I am working on (don’t find the time to do get this finished) is linked in my signature…