[SOLVED] HP 250 G3 Notebooks caught in infinite PXE boot loop
-
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] -
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!
-
[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.
-
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.
-
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
-
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.
