PXE Boot HP ProBook 455 G3

[jloke]

Hey Folks,

We’ve been using FOG 1.2.0 on RHEL since the summer and everyone in the IT staff at the college I work at loves it! Definite improvement over Symantec Ghost.

We have a new laptop (HP ProBook 455 G3) that is refusing to PXE boot (see attached image). The G1 and G2 revisions are marked as supported devices, but I haven’t been able to find info for the G3. We’ve had success with 10+ other models, including a few HPs. After some research, we found a post suggesting that we pull the most current iPXE files, which doesn’t appear to have changed anything. We also tried disabling UEFI boot options to no avail.

Any suggestions?

-Joel

[ch3i]

@jloke Hi, It’s seem to be a network problem, like DHCP or network. Could you try with dev revision (on a test server) : https://wiki.fogproject.org/wiki/index.php/Upgrade_to_trunk

[Tom Elliott]

What ipxe file are you using?

[jloke]

Thanks for the quick replies!

Tom: I found the post we used to upgrade (https://forums.fogproject.org/topic/6508/upload-image-from-hp-probook-450-g3/10). We used the directions @Sebastian-Roth provided (starts with “service xinetd stop”) to pull the current tftp files from the svn repository last week. I looked in the web interface & in Linux, but I don’t see where the version is listed. Where should I look & which info should I provide?

@ch3i: Did the directions we followed do what you’re asking us to try? If not, I can ask our server engineer to create a clone so we can play with a dev environment.

[george1421]

@jloke Again, what ipxe module are you using for this? I’m suspecting that the undionly.kpxe is not the right one for this hardware. I might guess that you need the realtek.kpxe for this box to be happy.

[Sebastian Roth]

Or possibly ipxe.efi/realtek.efi if the machines have UEFI enabled. Please make sure you use the correct binaries depending on how you configure the machines.

• UEFI enabled -> *.efi
• legacy/BIOS/UEFI disabled -> *.pxe, *.kpxe, *.kkpxe

To find out which iPXE binary you are using at the moment you need to tell us how you setup DHCP in your network? Is your FOG server providing DHCP (then look at /etc/dhcp/dhcpd.conf) or is it a Windows DHCP or Cisco router or dnsmasq???

[jloke]

Thanks guys!

We’re using an external RHEL server to run DHCP for the campus, so DHCP isn’t hosted on the FOG server. We confirmed in DHCP that the redirect lists undionly.kpxe as the filename. Thanks especially to @Sebastian-Roth for suggesting trying the realtek option. We switched filename to realtek.kpxe and the laptop is booting!

For fun, we tested booting two Dell desktops and two HP desktops after the realtek change. The Dells boot perfectly, while the HPs now having the same issue the laptop had (i.e. DHCP failed). Looks like we’ll use the realtek file to take care of this laptop, then change back to undionly for our general use.

Thanks for all the help!

[george1421]

@jloke said:

Thanks guys!

We’re using an external RHEL server to run DHCP for the campus, so DHCP isn’t hosted on the FOG server.

You have options since you are using RHEL for dhcp. I haven’t worked this into my kb document yet so this is just an idea I have. But the idea is that you will use the system’s guid to dictate what kpxe file the dhcp server will reply to the client. When the dhcp client boots it sends its guid and arch used to the dhcp server. The dhcp server can use this information for crafting a reply to the client. So the idea is if the dhcp server sees a dhcp request for client with guid: X then for option 67 it sends realtek.kpxe otherwise it just sends undionly.kpxe.

[Sebastian Roth]

@george1421 Good call to use GUID to distinguish between clients. But I don’t think this is needed here because we have a binary that includes all the native drivers - ipxe.(k)pxe

@jloke Please try using ipxe.pxe and if it does not work give ipxe.kpxe a try.

UNDI is an abstract NIC interface which works on most machines. This is why we use undionly.kpxe as a default. But iPXE also has native drivers. Either as “single binary” like realtek.kpxe or intel.kpxe. Or as a combined binary with UNDI and all native drivers - ipxe.pxe

[Wayne Workman]

@jloke said:

Looks like we’ll use the realtek file to take care of this laptop, then change back to undionly for our general use.

@george1421 said:

But the idea is that you will use the system’s guid to dictate what kpxe file the dhcp server will reply to the client.

If the Vendor Class identifier is unique from other models, it’d be easier to use a vendor class identifier in ISC-DHCP. We already have an extensive article detailing how to do this:
https://wiki.fogproject.org/wiki/index.php?title=BIOS_and_UEFI_Co-Existence#Building_custom_DHCP_Classes_for_co-existence_with_FOG

[Wayne Workman]

@george1421 @jloke

Here’s the bit I was talking about:

Specifically this area I’ve circled here:

[Wayne Workman]

@george1421 @jloke

Here’s a DHCP class example I just made up to match the example I posted below.

class "Legacy-Specific" {
    match if substring(option vendor-class-identifier, 0, 32) = "PXEClient:Arch:00000:UNDI:002001";
    filename "undionly.kkpxe";
    }

Of course, the ending bits will be different for others, and you’d want to set this class above the other legacy class so that this matches first and the more generic one matches second, then you’d set the filename you want.