No network interfaces found (verifyNetworkConnection) When deploying Image

[bsmaby]

I’m on Fog Trunk version r6263.
Desktop model: Lenovo C40-05.
FOG Server is running Ubuntu 14.04 LTS
DHCP is a Windows 2003 server.

I am getting a "No network interfaces found (verifyNetworkConnection) " error when trying to push out a Windows 10 Image on Lenovo C40-05 All in one desktop computer. I was able to upload an image from the Lenovo, but then when I try and push an image out to a computer of the exact same model and on the same network it give me that error. It even detects that I have an IP address during the initial fog configuration before it errors out. On a side note I am able to upload and deploy Windows 7 images just fine on HP Probook laptops. Any ideas? Thanks!

[Wayne Workman]

I know you say it’s the same network you’re trying, but can you try deploying the image using the same port you used to upload?

[Fernando Gietz]

Actually I have the same problem, but I notice that if you send the task and reboot from windows, the task works fine.

When the kernel is loading you can see some line like these:

bzImage ... OK
init.xz .... OK
[....]
initiating random number generator .... OK
Starting eth0 interface
udhcpc  (v1.24.1) started
Sending discover ....

Well, If I don t reboot from windows, for example from WOL, the last two lines dont appear and your error appears.

Please, try to reboot from windows to see if the error apeears.

[Sebastian Roth]

@bsmaby This exact error has nothing to do with the client or image being Windows 7 or 10. Neither has it anything to do with upload or download, AFAIK. If upload is working download should not fail with this exact error! Can you reproduce this? Read through Wayne’s answers and you see that it turned out to be a network/equipment issue…

@Fernando-Gietz Interesting! This is not good stuff. Why should you NIC be only discovered (or able to get an IP via DHCP) when cold booted?? Can you start a debug session from cold boot (e.g. WOL) and then run ip addr show when you get to the console?

[Fernando Gietz]

I think that the problem is the energy setup of the network card. If I shutdown the computer from the button, a dirty shutdown, the ip addr show command doesn’t show the ip. But when I reboot from the OS, the network setup appears fine.

[bsmaby]

@Wayne-Workman said:

I know you say it’s the same network you’re trying, but can you try deploying the image using the same port you used to upload?

So I did some testing… I was able to push the image out via the same switch (Cisco 3750x) I did the upload on, but it fails on our Cisco 3750G switch. Any idea what setting on the switch might be causing this? In our old version of FOG everything ran perfect (minus windows 10) on all of our switches.

[bsmaby]

@Fernando-Gietz said:

Actually I have the same problem, but I notice that if you send the task and reboot from windows, the task works fine.

When the kernel is loading you can see some line like these:

bzImage ... OK
init.xz .... OK
[....]
initiating random number generator .... OK
Starting eth0 interface
udhcpc  (v1.24.1) started
Sending discover ....

Well, If I don t reboot from windows, for example from WOL, the last two lines dont appear and your error appears.

Please, try to reboot from windows to see if the error apeears.

Funny you say that because I think we had the same issues that we had to reboot from windows… (on the Cisco 3750G switch), but I think on our newer 3750X switch it worked fine either way.

[george1421]

While I don’t know the cisco switches, I wonder if this is a spanning tree issue. With normal spanning tree it can take up to 30 seconds to move to the forwarding state. As long as the device doesn’t disconnect from the switch then the switch won’t go through the spanning tree check (meaning cold boot == problem, warm boot == works OK). Make sure you have the ports set to RSTP, fast STP, or portfast.

[Wayne Workman]

@Sebastian-Roth @george1421 What are the odds that so many people are recently affected by their network and this error and one switch working and another not?

Just seems like a lot lately - and all about the same time with the same error and same results when trying different switches and such… idk… I’m just suspicious at the moment.

[bsmaby]

@george1421 said:

While I don’t know the cisco switches, I wonder if this is a spanning tree issue. With normal spanning tree it can take up to 30 seconds to move to the forwarding state. As long as the device doesn’t disconnect from the switch then the switch won’t go through the spanning tree check (meaning cold boot == problem, warm boot == works OK). Make sure you have the ports set to RSTP, fast STP, or portfast.

We do have it set to portfast on our spanning tree settings

[Sebastian Roth]

@Wayne-Workman Seams like we see quite a bit of network issues lately. Conspiracy theory - anyone? I don’t know.

@bsmaby said:

Any idea what setting on the switch might be causing this?

Other than the mentioned spanning tree/port fast settings I can’t think of any really! If you are really keen to debug this I would start looking at the LEDs on your network card while PC boots up. As well you might want to connect a hub in between and capture PXE boot traffic to see whats going on (wireshark display filter bootp || tftp). Upload the PCAP file and I will have a look!

[george1421]

@Wayne-Workman said:

What are the odds that so many people are recently affected by their network and this error and one switch working and another not?

Just seems like a lot lately - and all about the same time with the same error and same results when trying different switches and such… idk… I’m just suspicious at the moment.

Thats a pretty good question/assessment. Why now, IS a great question…

Since this is a win10 deployment, is this a UEFI system? Or is the warm boot method initializing the network adapter in a way that the cold boot is not? I have seen this before (in the early days of the net).

[kverkiss]

@Wayne-Workman I have the exact same problem in a callcenter. The problem seems to occur from a cold start but resolves itself when booting to Windows first. This is impacting all images here.

Sttange this is; When I connect the workstation directly into the switchport in the patch cabinet/rack cabinet, the issue doesn’t seem to occur. It only happens when I connect the workstation to a floorport which contains a cable distance of about 25-30 meters.

I think electric or magnetic field causes this problem.

Once I boot-up the workstation into Windows, the issue is resolved, but can return at random timeframes.

[Wayne Workman]

@kverkiss Have you thought that perhaps simply turning the machine off and unplugging everything is what fixes it? I’ve been wondering about this myself lately. I’ve talked with our network guys and they’ve assured me both switches that I have different experiences with are configured identically. However, the runs from the problematic connection are a lot longer, which matches up with your distance-related hypothesis.

[kverkiss]

@Wayne-Workman Hi Wayne,

I did turn off the machine and disconnect all cables in many occasions, this will not resolve the problem.
For me the switches are configured the same too, and I’m using the same type/model of switches. The problem is not switch related for sure.

[Wayne Workman]

@kverkiss Then, using the switch that works - attach a 75ft patch cable (coiled up) and see if that works. If so, string that cable way way out from the switch to the floor and see if it still works.

The super long patch cable isn’t a waste either, you can cut it up later to make shorter lengths.

[neodawg]

I have the same issue, however I am imaging a Dell Venue 11 (7130). I had been testing imaging and now was just testing Win10. I started the task from the ‘quick image’ screen and that was causing this error. I cancelled it and started it from the FOG GUI then it is now going fine.

[Wayne Workman]

@neodawg Can you please re-try to confirm this issue is only with quick image?

[neodawg]

@Wayne-Workman I just finished the successful image of Win10 to the Venue. Trying the quick image now… Seems like it works now… random fluke? I tried removing the device from the dock and putting it back on and reconnecting the network cable and it still gave me that error, which then cause me to google the error and get to this page. Then I tried killing the task and using the GUI to make the task. But seems like its working fine now. the only thing different is the OS drive had Win8.1 on prior and now it has Win10, and both times I am imaging Win10.

[Sebastian Roth]

There is an interesting talk about DHCP working on cold boot but not when restarting the computer: http://forum.ipxe.org/showthread.php?tid=7965