Fog PXE issues
-
I can imagine recommending against it with all of the similar issues I’ve been reading. It sounds like there are so many reasons PXE could not be working that it goes from very simple OS or firmware issues to possibly more complicated switch issues.
I’m definitely trying Debian right now, it would be nice if it was just that easy.
-
[media=youtube]SFLGEST32GI[/media]
I’m still having the same problem with Debian. I recorded a video that hopefully, will help.
-
It took 40 seconds to get a DHCP address that is and issue in itself.
-
I can do the same thing on another ethernet port if you like, without the delay. That port is one I use to test my access points so there is some extra configuration to allow the access points to tag my other VLANs that are accessible on that port. [I]Edit:[/I] I do have 3 other ports without that VLAN configuration in my office to test with, I thought I should explain this better. The access points are configured to use my normal data VLAN for their configuration and those ports the access points use also have access to my other VLANs. When I use a PC on that port they don’t immediately get an address - it seems to take some amount of time before they use the default VLAN specified on that port.
I assure you that the DHCP delay is not related to this problem.
-
As one that has had this exact issue bite me in the behind in multiple ways, use an untagged port. If you have STP turned on, also make sure portfast is turned on for this port.
I had FOG .32 running fine (albeit slow) on a network with tagged/pvid and STP enabled… it worked. The new kpxe in FOG 1.x bombed out in weird spots due to the forwarding delays.
The forwarding delay is triggered each time the network card is initialized (4 times) during Bios > pxe > kpxe > linux kernel. This creates a timeout problem that looks like it’s not an issue, but really is. Trust me. Do not test on a port with forwarding delays!
-
I will do so today, thanks
-
You can always try a test bed, pull the fog server from the network, supply DHCP and use a hub to make sure that you can pxe boot the machines, if FOG works that way, you can step back through the hoops and put the FOG server back into the network and begin troubleshooting network settings, equipment, and possibly set up a service to help circumvent the issue.
Let us know how your tests go and if all else fails we need to set up a test network and verify that the server is functioning properly before we send you on a goose chase hunting network settings.
-
I think I’m making headway but now may be having a different problem with the new PXE.
I’m getting the FOG menu on one test computer which is the primary model I’ve imaged with the old .32 server HP DC5800 but on older HP DX5150 MT I’m getting a message that says press enter to restart or something to that effect. I’m guessing there is an issue with this NIC or PC loading this PXE?
-
Have you tried using the undionly.kkpxe file instead?
-
I’ve only tried the .kpxe file, not kkpxe so I’ll try that and get back.
-
[quote=“x106, post: 35109, member: 25501”]I’ve only tried the .kpxe file, not kkpxe so I’ll try that and get back.[/quote]
[url]http://ipxe.org/1d8c2139[/url]
This is the error the kkpxe comes up with.
-
should I try using an older version of fog?
-
i recommend trying the latest versions of the ipxe files, especially undionly.kpxe and undionly.kkpxe, from the svn before going back.
[url]http://sourceforge.net/p/freeghost/code/HEAD/tree/trunk/packages/tftp/[/url] -
with undionly.kkpxe - I get a reboot no messages
with undionly.kpxe - I get a reboot no messages
with undionly.kpxe.INTEL - I get a fog menu. I did a host registration on and older PC and it worked, on the newer PC it doesn’t work.
with ipxe.kpxe I get a fog menu - same error as the .INTEL file
with ipxe.kkpxe I get a fog menu and again same error.The error is DHCP/BOOTP: Reply not for us, op[2] xid[number changes] repeats this with different xid numbers then says:
IP-Config: Reopening network devices…
repeats again with different xid numbers.
