[SOLVED] HP 250 G3 Notebooks caught in infinite PXE boot loop
-
Can I just install the 3112 revision over my current 1.2.0 install? (after backing everything up just in case, of course)
-
yes
-
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?
-
Maybe see about disabling UEFI?
-
hmmm, see the error seems to point to MTFTPD (and indicator of UEFI)
-
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=“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]) -
I’m going to guess that you built it without an EMBED script, which is why you’re getting the infinite loop.
-
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.kkpxeSee any difference?
Edit: Others too have issues with Realtek PCIe NICs [url]http://forum.ipxe.org/showthread.php?tid=7356[/url]
-
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?
-
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=“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.
-
[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.
