[SOLVED] HP 250 G3 Notebooks caught in infinite PXE boot loop

[JeffD]

We have recently purchased some HP 250 G3 (Realtek 8136 NIC) Notebooks that came pre-installed with Win8.1.
They use UEFI but support a legacy BIOS system. Since we had to install Win7, the legacy BIOS setting was our only option. It doesn’t seem to play nice with with our FOG server.

Our FOG server is up to date and runs on an up to date virtual Ubuntu server that runs under Win2012 Server. The Windows server takes care of DHCP. We have many PCs of different makes and manufacturers that all boot into the PXE software and they can all use FOG’s functionalities just fine.

These notebooks show [URL=‘http://i.imgur.com/t1bjUQu.png’]this error[/URL] when attempting to load iPXE. Immediately after showing this error, the machine reboots and then attempts to load the same program, then show the error and reboot again. It will loop infinitely like this. If you follow the URL provided in the error, it says this error code no longer exists.

Not sure if this is relevant but [URL='http://i.imgur.com/VoqIqzz.jpg’]here[/URL]'s the BIOS settings used.

I have tried changing the DHCP server option 067 from “undionly.kpxe” to “undionly.kkpxe”, but that didn’t fix it.

So how do I make these laptops work with our FOG server?

[Junkhacker]

how “up to date” is your fog server?
are you running the latest official release (1.2.0) or a SVN dev release?

[Wayne Workman]

maybe try these?

[url]http://www.sevenforums.com/installation-setup/321097-how-install-windows-7-uefi-mode-usb.html[/url]
[url]http://forums.hexus.net/windows/296453-installing-windows-7-uefi-machine.html[/url]
[url]http://superuser.com/questions/676249/clean-install-of-windows-7-pro-64-bit-on-a-uefi-laptop-with-gpt-partition[/url]
[url]http://blogs.technet.com/b/askcore/archive/2011/05/31/installing-windows-7-on-uefi-based-computer.aspx[/url]

[BigMan99211]

Have you checked to see if your switches have Spanning Tree running? If so, it may be a combination of delays. Some laptop GbE interfaces have a tendency to be slower than normal when spanning tree is doing a loopback check. This delay could be just long enough for the ipxe check to fail.

As a test, if you can, try putting a cheap (netgear, dlink, etc…) switch between your network, and the laptop. That should prevent STP from scanning the laptop interface.

This might help… it might not… it’s 3am, and i’m hopped up on Monster Energy and pixie sticks! lol…
Gotta get work done somehow!

[JeffD]

[quote=“Junkhacker, post: 43809, member: 21583”]how “up to date” is your fog server?
are you running the latest official release (1.2.0) or a SVN dev release?[/quote]

1.2.0 Official.

[quote=“Wayne Workman, post: 43810, member: 28155”]maybe try these?
[url]http://www.sevenforums.com/installation-setup/321097-how-install-windows-7-uefi-mode-usb.html[/url]
[url]http://forums.hexus.net/windows/296453-installing-windows-7-uefi-machine.html[/url]
[url]http://superuser.com/questions/676249/clean-install-of-windows-7-pro-64-bit-on-a-uefi-laptop-with-gpt-partition[/url]
[url]http://blogs.technet.com/b/askcore/archive/2011/05/31/installing-windows-7-on-uefi-based-computer.aspx[/url][/quote]
Oh no, we managed to install Win7 with no problems. But it required enabling its legacy BIOS (by default it uses UEFI) setting to install it in the first place. I think that may be causing the issues with FOG so that’s why I brought it up.

[QUOTE=“BigMan99211”]Have you checked to see if your switches have Spanning Tree running? If so, it may be a combination of delays. Some laptop GbE interfaces have a tendency to be slower than normal when spanning tree is doing a loopback check. This delay could be just long enough for the ipxe check to fail.

As a test, if you can, try putting a cheap (netgear, dlink, etc…) switch between your network, and the laptop. That should prevent STP from scanning the laptop interface.

This might help… it might not… it’s 3am, and i’m hopped up on Monster Energy and pixie sticks! lol…
Gotta get work done somehow! :D[/QUOTE]

STP is disabled.

[Tom Elliott]

Jeff would you be willing to try svn? As far as I know 3112 is stable enough for environmental use and should help with the dhcp receiving issue you’re seeing.

[JeffD]

I’m definitely willing to try this but I’ll have to run it by my boss, whom I won’t see until next Friday. I’ll let you know how it went hopefully next week.

Thanks so far for the quick replies everyone

[JeffD]

Can I just install the 3112 revision over my current 1.2.0 install? (after backing everything up just in case, of course)

[Junkhacker]

yes

[JeffD]

I installed revision 3112. Uploading/deploying to all PCs still seems to work but these notebooks are still not. The error code is different this time:
[URL=‘http://i.imgur.com/U4dXvso.jpg?1’]Image[/URL]. It points me to [url]http://ipxe.org/4c126035[/url].

I was able to retrieve files over TFTP from Win7 on the notebook so I don’t know if TFTP access is the problem.

What else can I try?

[Tom Elliott]

Maybe see about disabling UEFI?

[Tom Elliott]

hmmm, see the error seems to point to MTFTPD (and indicator of UEFI)

[Sebastian Roth]

I reckon it’s time to build your own ipxe binary with debugging enabled to get more information about this… see here: [url]http://fogproject.org/forum/threads/build-ipxe-from-source.10152/[/url]

[CODE]make … DEBUG=dhcp[/CODE]

[JeffD]

[quote=“Uncle Frank, post: 44194, member: 28116”]I reckon it’s time to build your own ipxe binary with debugging enabled to get more information about this… see here: [url]http://fogproject.org/forum/threads/build-ipxe-from-source.10152/[/url]

[CODE]make … DEBUG=dhcp[/CODE][/quote]

I couldn’t build it with the instructions provided in that link. I managed to successfully build it using these instructions instead. [url]http://www.fogproject.org/wiki/index.php/Building_undionly.kpxe[/url]
I don’t know much about any of this so I probably didn’t do it right.

Just in case I did it right after all, here’s what I got.
[url]http://i.imgur.com/nXeiAIh.png[/url]
[url]http://i.imgur.com/evSgrE4.png[/url] (error referenced in this picture: [url]http://ipxe.org/err/040ee1[/url])

[Tom Elliott]

I’m going to guess that you built it without an EMBED script, which is why you’re getting the infinite loop.

[Sebastian Roth]

Doesn’t look like a loop to me as this client does not seem to get beyond iPXE’s DHCP routine. To me it looks like that client is sending out DHCP requests to the server (or maybe it just says it does?!?) but doesn’t get the DHCP response to that request. From what I read in your other posts I guess that it’s not a general problem. You wrote that other clients work well. It’s just that notebook model, right???

Please give undionly.kkpxe a shot! Change your DHCP settings to point to undionly.kkpxe instead of undionly.kpxe …
If it does not work you can also try ipxe.kpxe and ipxe.kkpxe

See any difference?

Edit: Others too have issues with Realtek PCIe NICs [url]http://forum.ipxe.org/showthread.php?tid=7356[/url]

[JeffD]

ipxe.kpxe actually works!

It also works with at least one of our other previously already working machines as well. I will test on other PCs later.

There must be a reason why undionly.kpxe is practically considered the “default” binary. Does it just lower startup time because it loads fewer drivers? Are there any problems I should expect when switching to ipxe.kpxe?

[Tom Elliott]

To be honest I have know idea. I know the undionly files only use the nics PXE driver called undi. The ipxe files use the iPXE drivers but I don’t think there’s any difference using Pxe kpxe or kkpxe of the ipxe named files. I simply build them because why not. I’m glad it works for you. What I do know is we default to undionly files mostly because it works on most nics without needing to know what model of nic you have. The drivers ipxe builds do not include every nic so it’s most likely not going to work for all systems.

[Wayne Workman]

[quote=“Tom Elliott, post: 44511, member: 7271”]To be honest I have know idea. I know the undionly files only use the nics PXE driver called undi. The ipxe files use the iPXE drivers but I don’t think there’s any difference using Pxe kpxe or kkpxe of the ipxe named files. I simply build them because why not. I’m glad it works for you. What I do know is we default to undionly files mostly because it works on most nics without needing to know what model of nic you have. The drivers ipxe builds do not include every nic so it’s most likely not going to work for all systems.[/quote]

Which is where DHCP classes and DHCP policies must come into play…
Still working on this… I haven’t looked into it for a good while (spring break, woot!).

But, when I do (and get it working), I plan on writing some very through documentation for the WiKi that is specific to ProxyDHCP and Windows Server 2012 DHCP.

[Tom Elliott]

[quote=“Wayne Workman, post: 44570, member: 28155”]Which is where DHCP classes and DHCP policies must come into play…
Still working on this… I haven’t looked into it for a good while (spring break, woot!).

But, when I do (and get it working), I plan on writing some very through documentation for the WiKi that is specific to ProxyDHCP and Windows Server 2012 DHCP.[/quote]

User Classes are great and the way to handle many things, especially the handing out of files to UEFI systems vs. Legacy systems.