i219LM NIC, ASUS Q170M-C Motherboard
-
@dustindizzle11 OK now that you are at the debug console I want you to key in the following command
lspci -nnWhat I’m looking for is the ethernet controller line. This one is from my fog server.
0b:00.0 Ethernet controller [0200]: VMware VMXNET3 Ethernet Controller [15ad:07b0] (rev 01)The key is the 8 hex keys “[15ad:07b0]” that will be the nic hardware manufacturer and the device ID. You can also view these values from a running windows system this is the vendor and hardware id in the device manager, but since you have the debug console that is the best way to get that information.
-
I don’t get the expected output from running lspci -nn (or by using the -vv option which displays the same thing. Pic below)
-
@dustindizzle11 Try with just one -n I know one of the command line switches should give the output like I posted. -nn worked on centos 7.
-
@george1421
one “-n” gives me the same thing
… “ip link show” lists eth0 though for some reason.Also, Side note, I am using the 4.6.2 Kernel at the moment with debug on.
-
Is the VM setup for natted interface when it should be bridged?
-
@Tom-Elliott
It is bridged. -
@dustindizzle11 said in i219LM NIC, ASUS Q170M-C Motherboard:
@Tom-Elliott
It is bridged.What, where did a virtualization layer come into scope? My assumption was the FOG Engine was running directly on the hardware.
-
@george1421 I think the problem system is physical just the fog server is a VM.
-
If I go into debug mode and manually enable the interface, then restart networking it works (after getting eth0 added and typing “fog” in debug mode, the computer images fine). The problem is that for some reason, eth0 is not setup as an interface.
So all I did manually was…
ifconfig eth0 up
added to /etc/network/interfaces
auto eth0
iface eth0 inet dhcpthen /etc/init.d/S40network restart
I probably could have just added it to the interfaces file and restarted to get it an address, but wanted to show what I did above. Also I am not sure that the name was “S40network”, i just remember it being called S40"something".
Anyone have any ideas as to why it is not getting added automatically?
-
@dustindizzle11 S40network is the correct init.d script to call.
That said, can you try putting a “dummy” switch between the main and the system you’re having issues with?
See your info tells me the link up is not being detected, which is usually a STP portion issue. That or the patch cable isn’t returning “link up”.
-
@dustindizzle11 I agree with Tom. What we’ve seen is that if the building switch has Spanning Tree enabled and the switch is not configured for one of the fast spanning tree modes the FOS engine will boot, wait and give up before spanning tree starts forwarding data. On your building switch you need to check to see if STP is enabled, if it is you need to enable one of the fast spanning tree protocols (port fast, RSTP, fast STP, or what ever your switch mfg calls it).
One quick check to see if it is a spanning tree issue, is to put an dumb (unmanaged) switch between the target computer and the building switch and then pxe boot the target computer. That unmanaged switch will keep the building switch from seeing the target nic wink (momentarily drop the port link) as the target transitions from the iPXE kernel to the FOS Engine kernel.
-
There is currently already a dummy switch in between. I can image any other model from the same spot, just this model behaves this way.
-
We have port fast enabled on all ports
-
@dustindizzle11 Do you have other systems of the same model MB? Does this happen in the same way for all systems, or just this one system?
-
@Tom-Elliott Yes we have other systems with the same model MB. This happens in the same way for all systems that have this MB. Thanks again for trying to help with this, I appreciate the time you guys take to help troubleshoot. It is strange that it is not auto configuring eth0. Btw, when in debug mode just adding eth0 to the interfaces file then restarting the network is all that needs to be done to get an address and fog the computer. Just mentioning that because I mentioned in an earlier comment what I did to get an address, which was more than I needed to do.
-
@dustindizzle11 the s40 file you referenced is supposed to do this for you but it only adds the interface I’d the nic has a cable attached (or shall I say recognizes the link is up). And I suspect this is where it’s failing. It can’t detect the link for whatever reason.
-
@Tom-Elliott I thoght that either Sabastian or you added a loop to the network startup code where it would check wait, and then check again for the a link or dhcp packet to be received before giving up on the interface. This was done to mask the spanning tree issue (I know this is not the case here) but it would seem the network link is slow to come up for some reason.
-
@george1421 Just want to add, we just tested a different fog server that has it’s own network (hands out dhcp) and only a dumb switch sits between this fog server and one of these models. Still the same exact result.
-
@dustindizzle11 As George already said the network script does kind of wait for a link to come up. It checks link state of all the network devices for about 35 seconds and bails out if the link does not come up in that time. Take a look at the script here.
I am not sure what else we could do? Bring up the interface even if the link state is not connected?
-
@Sebastian-Roth I totally understand if not much can be done, if anything, I just want to give people a heads of that this NIC or NIC/MB combo does not play nicely with Fog at the moment. We were able to image the whole lab, but in involved entering debug mode for all the machines and manually bringing up the interface, then typing “fog” to image them. Thanks everyone for your time and help trying to figure this out. If I find anything else out in the future I will add it here.
Dustin
