Fog 1.3.4 stable, iPXE doesn't work with my Optiplex 790

[FredG]

Server

• FOG Version: 1.3.4
• OS: Ubuntu 16.04

Client

• Service Version:
• OS:

Description

Files pxe (bios legacy) do not work with the optiplex 790.
I also tried the file ipxe.pxe of the version 1.3.5RC2 But I obtain the same result.
I followed the procedure to make an ipxe.pxe.
https://wiki.fogproject.org/wiki/index.php?title=IPXE#rom-o-matic.eu
https://github.com/FOGProject/fogproject/blob/dev-branch/src/ipxe/src/ipxescript

https://rom-o-matic.eu/
output format: PXE bootstrap loader image [Unload PXE stack] (.pxe)
Choose a NIC type: all-drivers
If I remove the option “NET_PROTO_LACP, Link Aggregation control protocol” the file ipxe.pxe works.

https://rom-o-matic.eu/build.fcgi?BINARY=ipxe.pxe&BINDIR=bin&REVISION=master&DEBUG=&EMBED.00script.ipxe=%23!ipxe ifopen isset %24{net0/mac} %26%26 dhcp net0 || goto dhcpnet1 echo Received DHCP answer on interface net0 %26%26 goto proxycheck %3Adhcpnet1 isset %24{net1/mac} %26%26 dhcp net1 || goto dhcperror echo Received DHCP answer on interface net1 %26%26 goto proxycheck %3Adhcperror dhcp || prompt --key s --timeout 10000 DHCP failed%2C hit 's' for the iPXE shell%3B reboot in 10 seconds %26%26 shell || reboot %3Aproxycheck isset %24{proxydhcp/next-server} %26%26 isset %24{next-server} %26%26 echo Duplicate option 66 (next server) from DHCP proxy and DHCP server %26%26 echo Using IP sent by DHCP proxy %24{proxydhcp/next-server} %26%26 prompt --timeout 5000 || goto nextservercheck %3Anextservercheck isset %24{proxydhcp/next-server} %26%26 set next-server %24{proxydhcp/next-server} || isset %24{next-server} %26%26 goto netboot || goto setserv %3Asetserv echo -n Please enter tftp server%3A %26%26 read next-server %26%26 goto netboot || goto setserv %3Anetboot chain tftp%3A//%24{next-server}/default.ipxe || prompt --key s --timeout 10000 Chainloading failed%2C hit 's' for the iPXE shell%3B reboot in 10 seconds %26%26 shell || reboot&general.h/NET_PROTO_STP:=0&general.h/NET_PROTO_LACP:=0&general.h/DOWNLOAD_PROTO_HTTPS:=1&general.h/DOWNLOAD_PROTO_FTP:=1&general.h/DOWNLOAD_PROTO_NFS:=1&general.h/CRYPTO_80211_WEP:=0&general.h/CRYPTO_80211_WPA:=0&general.h/CRYPTO_80211_WPA2:=0&general.h/IWMGMT_CMD:=0&general.h/NSLOOKUP_CMD:=1&general.h/TIME_CMD:=1&general.h/DIGEST_CMD:=1&general.h/LOTEST_CMD:=1&general.h/VLAN_CMD:=1&general.h/REBOOT_CMD:=1&general.h/POWEROFF_CMD:=1&general.h/IMAGE_TRUST_CMD:=1&general.h/PCI_CMD:=1&general.h/PARAM_CMD:=1&general.h/NEIGHBOUR_CMD:=1&general.h/PING_CMD:=1&general.h/CONSOLE_CMD:=1&general.h/IPSTAT_CMD:=1&general.h/TIVOLI_VMM_WORKAROUND:=0&console.h/CONSOLE_FRAMEBUFFER:=1&general.h/ROM_BANNER_TIMEOUT=2&console.h/KEYBOARD_MAP=fr&

[george1421]

First of all lets backup here.

I have the o790s on my campus and they do ipxe boot. In legacy mode (the only mode that supports pxe booting on the 790s) I use undionly.kpxe.

With that said, I “just” updated to 1.3.4. Let me confirm this is still functional. I know 1.3.3 worked.

As for your statement: iPXE doesn’t work…

What exactly isn’t working? What error are you getting? Is is something you can capture with a picture?

[FredG]

The screenshot :

I’m sorry, my English is bad

[Tom Elliott]

@FredG This is normally occurring due to STP on your network.

Please try placing a dumb switch between your “problem” machine and the network, see if it works.

[george1421]

@Tom-Elliott While Tom doesn’t need confirmation, this IS typically a Spanning Tree issue if you are using standard spanning tree protocol and not one of the fast protocols (RSTP, fastSTP, etc) on your building switch. The default spanning tree take 27 seconds from the time the link goes active until it starts forwarding data. This 27 seconds is much to slow for PXE booting.

By using an unmanaged switch between the target computer and the buidling switch, the unmanaged switch ensures the building switch port doesn’t wink (momentarily turn off and on) as the fog kernels boot.

[FredG]

I put an unmanaged switch between the machine and the network and it works.
I’ll check with our network team.
Thank you all

[george1421]

@FredG Just for future reference, as the saying goes “A picture speaks 1000 words”. The picture gives us the context of the error which drives us to a quick answer.

[FredG]

I come back to you.
Our network team set up the RSTP on our building switch but it does not still work.

With "NET_PROTO_STP, Spanning Tree protocol " and without "NET_PROTO_LACP, Link Aggregation control protocol ", the custom ipxe.pxe works on our network.

If you confirm that it is “typically a Spanning Tree issue”, i’ll try to find a solution.

[george1421]

@FredG This is typically a spanning tree issue. We have also seen green ethernet (802.3az) cause an issue similar to this. But typically it is spanning tree at fault.