iPXE issues on Alienware Aurora R12's
-
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!
