Fog PXE issues
I have used Fog .32 for a while and have had great success. I installed a new fog server (using my old hardware). I went from using Ubuntu 10 to 14 LTS releases. Also using the new PXE setup.
I installed Fog twice using 14 trying to troubleshoot possible issues, at first I think I was having issues with the TFTP service, I rebooted it and got further. In the end I’m still having issues.
The first issues were timeouts and after restarting the services things worked to a point but when PXE would load I wasn’t getting any error messages it would just boot the hard drive. I then decided to load Fog on my VMware server which I like the idea of just leaving it there now - the first thing I noticed was when I booted my VM is that PXE did work properly from my physical machine to the virtual machine… I still moved forward and installed fog on the VM and left the desktop fog machine off. Multiple computers were tried and no real physical towers successfully loaded the PXE menu.
My DHCP server is Server 2008 and like I said, my virtual machine booted to the fog menu properly.
What am I missing?
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 xid[number changes] repeats this with different xid numbers then says:
IP-Config: Reopening network devices…
repeats again with different xid numbers.
i recommend trying the latest versions of the ipxe files, especially undionly.kpxe and undionly.kkpxe, from the svn before going back.
should I try using an older version of fog?
[quote=“x106, post: 35109, member: 25501”]I’ve only tried the .kpxe file, not kkpxe so I’ll try that and get back.[/quote]
This is the error the kkpxe comes up with.
I’ve only tried the .kpxe file, not kkpxe so I’ll try that and get back.
Have you tried using the undionly.kkpxe file instead?
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?
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 will do so today, thanks
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 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.
It took 40 seconds to get a DHCP address that is and issue in itself.
I’m still having the same problem with Debian. I recorded a video that hopefully, will help.
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.
[quote=“x106, post: 34985, member: 25501”]I just installed fresh while waiting for replies and I’m PXE seems to load but slow. I believe there is an error message on the first screen then it goes to an iPXE screen that says configuring and lists the NIC’s MAC address, I’m assuming. Then when it slowly gets past that the system reboots. I don’t have to use VMware, but it is definitely easier to test that way.
When the installation video listed on the site goes through all the steps in Ubuntu it genuinely seems like it is being supported. I’ll try Debian though.[/quote]
14.04 works. I’m using it as my primary storage system. However, the reason we recommend against it is because there have been many many issues with it.
I just installed fresh while waiting for replies and I’m PXE seems to load but slow. I believe there is an error message on the first screen then it goes to an iPXE screen that says configuring and lists the NIC’s MAC address, I’m assuming. Then when it slowly gets past that the system reboots. I don’t have to use VMware, but it is definitely easier to test that way.
When the installation video listed on the site goes through all the steps in Ubuntu it genuinely seems like it is being supported. I’ll try Debian though.
I would start by installing a recommended OS, Ubuntu 14 is NOT a recommended OS.
If you like Ubuntu, try Debian 7.4 or 7.5
You should be fine using VMWare but be warned, it will be slow.