Fresh VM and Fog 1.2.0 install having issues with iPXE boot
-
@jcook What you want to look for is to enable RSTP, portfast, or fast stp (called different things by switch vendors). You also want to disable any green ethernet or 802.3az modes on your switch.
-
Looks like RSTP was already enabled. I am trying to find if there are any green ethernet settings.
-
@jcook If you can find a cheap unmanaged switch. Put that between your building network switch and the target computer. See if that helps. That will surely give us a direction.
The other thing I didn’t see mentioned is what is the manufacturer and model of the target device you are trying to boot?
-
Right now a Dell 3010.
-
@jcook Ok what is the version number of the FOG Kernel? Its possible that you need to update the kernel to support the 3010. I can say the 1.2.0 trunk build (i.e. pre-1.3.0) supports the 3010 out of the box. But that also has a current set of drivers.
-
I didn’t make any changes really yet. I started getting the error after I first tried to PXE the 3010. How can check the kernel version?
-
To get the kernel version run
file /var/www/html/fog/service/ipxe/bzImage*Or you can check (and update) the kernel version via the web interface (FOG Configuration)…
Other than fully upgrading to FOG trunk you can get the newest iPXE binaries or just try different binaries that were shipped with FOG 1.2.0 (e.g. undionly.kkpxe or ipxe.pxe).
-
I get this on the server:
/var/www/html/fog/service/ipxe/bzImage: x86 boot sector
/var/www/html/fog/service/ipxe/bzImage32: x86 boot sectorI will also try those suggestions now and report back.
-
If you can sustain a little of instability, I might recommend that you upgrade to the latest trunk build (pre 1.3.0 release). That way you will be assured you have the latest drivers and boot images and support for uefi firmware, gpt disks and windows 10.
-
Using ipxe.pxe i get the original error again. With undionly.kkpxe "Could not start download: Operation not supported (http://ipxe.org/3c092003).
In another post (that I think most of you were helping me with too :D) I was trying to use .032 and I think the error was the same. I am beginning to believe its the network and not fog. I might try to see if Adtran support can help me if I can explain the problem to them.
-
I agree with George, you should try fog trunk before escalating the issue - when simply upgrading to trunk might totally resolve the issue.
-
@jcook That’s interesting. For me
fileis reporting the kernel version:/var/www/html/fog/service/ipxe/bzImage: Linux kernel x86 boot executable bzImage, version 4.5.0 (root@debian64) #1 SMP Mon Mar 14 06:35:01 EDT 2016, RO-rootFS, swap_dev 0x6, Normal VGA /var/www/html/fog/service/ipxe/bzImage32: Linux kernel x86 boot executable bzImage, version 4.5.0 (root@debian64) #1 SMP Mon Mar 14 06:36:15 EDT 2016, RO-rootFS, swap_dev 0x6, Normal VGAThis is FOG trunk kernel. You’ll probably see 3.x.y version. See if you can find out about the kernel version via web GUI -> FOG Configuration -> Kernel Update
-
When I go to the “Kernel Update” section of the GUI I don’t see an indication of my current kernel. I don’t mind trying updating kernel to make sure I have the latest, just not sure which to choose.
Also upgrading to trunk isn’t a problem either if someone can point to guide I can do that too or first.
-
@jcook Here is a guide for updating to the latest trunk build. https://wiki.fogproject.org/wiki/index.php/Upgrade_to_trunk
-
I have upgraded to trunk and this is what my PXE boot looks like, I noticed another error I might have over looked. Since I’m not sure what any of it means Ill just let u see the screen shot. This is with undionly.kpxe.
Also I forgot to mention the fog server and the clients are on different vlans. I was thinking of moving fog to the same vlan and see if that helps just not sure it will.
-
That picture speaks volumes.
The PXE rom is requesting iPXE (good). iPXE kernel get loaded (good), iPXE isn’t able to pickup a dhcp address (bad).Do you have access to a hub or an unmanaged switch you can place between the computer and your building switch?
So far this is not a vlan issue, but an issue with iPXE being able to pick up a dhcp address. The most frequent reason is that spanning tree is not forwarding right away (but you said RSTP was enabled). So by the time STP switches to the forwarding rate, the iPXE kernel has already given up.
-
I am actaully a lone IT guy here at a small school. The firewall and core switches are in my “office”. My understanding ( and I may have things wrong) each vlan has its own DHCP server. Our “Wired” vlan has the fog tftp info, but the “Management” vlan has a tftp server for out access points. However for the “Management” vlan the tftp sever isn’t supplied via option 67 but another setting in the DHCP server. Should I try leaving the other tftp setting alone and adding the options 66 and 67?
Should I put the dumb switch between the client and the core, the firewall/dhcp, or just between the client and a smart switch( if that mkes since lol)?
EDIT: Also is this something I might be able to fix by adjusting RSTP timings?
-
@jcook The first step is to see if we can use an unmanaged switch between the target computer and your core switch.
The rest of your environment (up to this point) is setup correctly. The root of the issue right now is that when the iPXE kernel starts to run it will reset the network adapter causing the link to drop (if you watch the link light on the target computer) for a second while the network adapter is being configured. Its only out for a second, but with spanning tree in default mode it take 27 seconds for the port to start forwarding data again. The are 3 such network “winks” as the FOS kernel boots (PXE Rom -> iPXE, iPXE -> iPXE, and iPXE -> FOS kernel).
By using the unmanged switch the wink happens between the target and unmanaged switch. The core switch port never winks so it stays forwarding. Understand this is only a test to see if it is spanning tree issue.
-
DHCP is much faster. It asks for the tftp server and after entering it I get the above and it seems to hang.
-
@jcook good, then issue #1 has something to do with spanning tree. The next issue is if iPXE asks for the fog server address the proper dhcp options are not getting to the target. Can you confirm that the dhcp scope for this subnet is sending out dhcp options 66 {next-server} and option 67 {boot file}
<edit> crud that’s not the problem because the iPXE image is getting to the client. Is the FOG server and the target computer on the same subnet </edit>
