TFTP Problems

[Tom Elliott]

@bacelo Can you hit me up in chat?

I can maybe teamviewer?

[bacelo]

@Tom-Elliott can it be in 1 hour you would save my life

[Tom Elliott]

it sure can be.

[bacelo]

OK thanks to Tom Elliott I got the fog server to work kind of the only thing that is missing is on booting the network card it loses the connection to the lan link card and I have to press S and type dhcp and it gets back up and then o type exit and the menu boots up. The problem is that I have to be physically at the client PC for this to work so if I were to deploy the software it won’t go because I have to press S DHCP and then exit and then it will pop up the menu

[Sebastian Roth]

@bacelo We’ve reworked the iPXE script lately. Seams like you are in a (DHCP) situation where our script does not properly work. Sounds like an interesting issue. Have you tried activating port fast setting on the switch? I guess Tom has talked about this as well.

Could you please take a picture with your smartphone of all the messages you see and the keys/commands you use to get to the boot menu? To me this sounds like a “timing” issue. When booting up the script does pretty much that (dhcp command). So I wonder why it works when you do this by hand.

[bacelo]

@Sebastian-Roth
This is the message that I get when it stops. What I do is Press “s” then I type “dhcp” it configurs the dhcp and says ok
then I type “exit” and boom the menu appears . And yes I think it has to do with the timing because it loses conection to the lan card when it runs this script.

[Sebastian Roth]

@bacelo Ok, this really means DHCP is timing out. Can you upload a picture of the command ifstat run in the iPXE shell?

Have you looked into portfast settings on your switch yet? http://www.cisco.com/c/en/us/support/docs/switches/catalyst-6500-series-switches/10553-12.html

What NIC (exact brand, model and possibly PCI IDs) is it?

[george1421]

@Sebastian-Roth I would tend to agree here with the network being (partially) at fault. I have seen spanning tree cause an issue because it takes too long to move the port into a forwarding state once the link up signal has been sent. By then OS has already given up on the link thinking that it is down. This will generally cause dhcp issues FOG or not, for the first minute or two the port link is up. They created RSTP and portfast to address the slow 30-60 seconds wait for STP topology check.

One quick way to check this is to turn off spanning tree all together on that port where the device is. (ONLY TURN IT OFF to test if spanning tree is your problem or not. Do not leave the port in this state if it is in the user domain)

[Wayne Workman]

I have to agree with the others, this sounds like portfast isn’t turned on. Sounds instead like spanning tree is in use.

Did Tom put you on FOG Trunk or are you still on 1.2.0 ?

[bacelo]

@Wayne-Workman yes it’s fog Trunk but what should i do know?

[bacelo]

@Sebastian-Roth her is the ifstat foto

[Wayne Workman]

@bacelo ask the people who run the network about turning on portfast.

[george1421]

To add a little background information to this. The error noted in the picture is related to configuring the nic. From the ipxe error page this is stated.

This error indicates that iPXE timed out while attempting to autoconfigure a network adapter.

In almost all cases the method used for autoconfiguration will be DHCP, and you should read the information relating to DHCP timeout. 

ref: http://ipxe.org/err/040ee1
While working on a project over the holiday. With a system booting and using dnsmasq I saw the device disconnect and reconnect to the switch 3 times during the boot into the ipxe menu. The last link drop was just after printing Configuring (ne0 …). So that makes me think that this is a spanning tree issue (which can be resolved with portfast or RSTP).

[Sebastian Roth]

Either portfast/RSTP or you can try using iPXE with native driver support. On your DHCP server change bootfile option from undionly.kpxe to ipxe.pxe and see if it makes any difference.