iPXE issues on Alienware Aurora R12's
-
Currently running into a problem with getting new windows 10 machines to communicate with our Fog Server. We are hitting a roadblock with iPXE. Our DHCP Scope option 67 is set to ipxe.efi. Our older machines have no issues communicating with Fog (Dell Precision T5810’s, secure boot disabled, UEFI), but our new machines (Dell/Alienware Aurora R12’s, secure boot disabled, UEFI) are failing to register with the following errors:
http://x.x.x.x/fog/service/ipxe/boot.php… Connection timed out
Could not boot: Connection timed out
Chainloading failed, hit ‘s’ for the iPXE shell
Any assistance with this issue will be greatly appreciated!
-
@switch_apoc First we need to know the FOG version you are using.
I suggest you update to the very latest version of iPXE manually: https://docs.fogproject.org/en/latest/reference/compile_ipxe_binaries.html
-
@switch_apoc If your IP addresses are in the private range, its helpful for us to see them. If your blacked out IP address in the public (internet) addresses we can work around that. Knowing a non-routable private IP address won’t help any hacker to get into your network because the internet won’t route private range addresses.
It looks like your aurora computer is getting an IP addresses. Is the blacked out IP address the IP address of your FOG server?
Is that device on the same subnet as your FOG server?
-
Hello! @george1421 Our Fog server and the machines that I’m trying to register/image sit on two different subnets. We have rules in place to allow inbound/outbound traffic between the two subnets on our Firewall. And yes, the blacked out IP Addresses is our Fog Server.
-
@switch_apoc said in iPXE issues on Alienware Aurora R12's:
We have rules in place to allow inbound/outbound traffic between the two subnets on our Firewall.
Ok very good.
Part A of the question: So from the subnet where the pxe booting computer is at, can you access the url from a web browser that is listed in your picture?
http://<fog_server_ip>/fog/service/ipxe/boot.php? That should return the text behind the iPXE menu. All I need to know if it returned a page of text or not?Part B of the question: Did you happen to turn on https:// on the fog server?
-
Hello! @sebastian-roth we updated to the stable release yesterday via git to 1.5.9 (previously on 1.4.4). Do the ipxe binaries not update when Fog get’s updated? The onboard NIC appears to be a intel killer e3100.
-
Part A: Yep, I can see the boot.php wall of text just fine from the machine i’m trying to register/image, which is on separate subnet than the fog server
Part B: https is not enabled on the fog server -
@switch_apoc On the switch port where this machine is configured, what is the state of spanning tree? Is it configured for portfast, RSTP, MSTP, fast-STP or what ever your switch mfg calls any of the fast spanning tree modes? If you are unsure, if you have a dumb/unmanaged switch (i.e. those cheapie 5 port switches), place that between the building switch and target computer. Does that address the issue (or just ensure fast-STP is enabled on the building switch port)
-
@george1421 The desktops that the ports are connected to are configured as edge ports, where spanning tree isn’t communicated. But yes, we use rapid spanning tree. I’ll need to dig up a dumb network switch to test the theory that you suggested.
-
@switch_apoc said in iPXE issues on Alienware Aurora R12's:
need to dig up a dumb network switch to test the theory that you suggested
Yes let us know how it goes. Spanning tree is another thing that can cause random boot up communication issues. By the time STP starts normal forwarding FOG has already gave up trying to boot.
The network port {winks} 2 times during pxe booting once when iPXE takes over and the second time during imaging when FOS Linux takes over the nic.
-
@switch_apoc I thought about this a bit more on the commute home. We might be able to test for spanning tree at the error screen in your first picture.
When you get the chain error connection timeout error message. Hit the
skey to get the iPXE shell.At this point you are at the iPXE command prompt. Wait 30 seconds (for STP to start forwarding data). Then try to ping the fog server IP. If you get a response then key in
chain http://<fog_server_ip>/fog/service/ipxe/boot.php(hint the same command that gave us the connection timeout) You might get an error in the next screen, but I’m more interested in seeing if time fixes this issue. If time does solve the issue then its most likely the network port is configured for standard STP. -
@switch_apoc said in iPXE issues on Alienware Aurora R12's:
we updated to the stable release yesterday via git to 1.5.9 (previously on 1.4.4). Do the ipxe binaries not update when Fog get’s updated? The onboard NIC appears to be a intel killer e3100
Oh wow, 1.4.4 is really old. And 1.5.9 is not new either. I suggest you do the iPXE compile from the latest source if you still see issues.
But it could be a network routing/firewall issue as well. Do you have other machines that work fine from that same subnet you have the Alienware machines in?
-
@sebastian-roth the link you provided was super helpful. Upon compiling new ipxe binaries, I had to update the kernel version in FOG, and voila, we are now able to get these machines registered in Fog and deploy images. Thanks for the help! @george1421 Thanks as well!
