kernel interface not working
-
@george1421 Hi - here is what I did:
The target host is not registered (never has been - new install) so instead I renamed bzImage to bzImage-old and renamed bzImageRT to bzImage.
Got into the menu and got the same result - no DHCP on that interface.
If I need to do that differently please let me know.
JF
-
@Jeff-Findley well that destroys that idea.
So what I want you to do with that host is to schedule a capture or deploy task to that computer, the action doesn’t matter. But before you hit the schedule task button, tick the debug checkbox then hit the schedule task button. Now pxe boot the target computer, it should boot into debug mode on the target computer. You need to press the enter time a few times to clear the text on the screen. Eventually you will be dropped to the FOS Linux command prompt.
At the fos linux command prompt wait 30 seconds then key in the following:
/sbin/udhcpc -i enp2s0 --now
assuming the host from the OP.If that doesn’t pick up an IP address then take a clear screen shot with a mobile phone of the output of these commands.
lspci -nn | grep -i net
ip addr show
-
@george1421 Hi,
Okay, did the deploy an image with debug.
When I got the the prompt I issued the udhcpc command and it got an address just fine. Correct subnet and everything.
lspci showed the correct device for what we are working with.
ip addr show shows two interfaces:
lo and enp2s0 and the working interface has the correct address from the DHCP pool, correct broadcast, etc.
I can ping the FOG server’s address from the target host at the command line.
-
@Jeff-Findley So the only change is time that fixes the problem. I’m going to assume that during the boot into the debug mode it failed to get an IP address, but when you manually issues the udhcpc command it worked fine?
If it is truly time that fixes the issue, the problem is MOST LIKELY spanning tree. Even some of the unmanaged switches have standard spanning tree enabled by default. You typically don’t find this in home switch gear. Usually the test is to put a cheap unmanaged (i.e. $20 monoprice) switch in between to test.
-
@george1421 Okay, that makes sense.
And yes, it did not get an address and then got one fine at the udhcpc command.
So, aside from “fixing” this problem - since I can get to the command line with an address and ping the server is there a way now for me to manually run the scripts to deploy the image I want?
I only have a handful of laptops I need to image at this point.
Later, I can try another network switch and see if I get different results.
-
@Jeff-Findley said in kernel interface not working:
So, aside from “fixing” this problem - since I can get to the command line with an address and ping the server is there a way now for me to manually run the scripts to deploy the image I want?
Sure, in debug mode (as suggested by George) you just type
fog
and hit ENTER to start the task. Though you will need to step through this manually. Give it a go. -
@Sebastian-Roth Excellent! Deploying now.
That’s really frustrating that a crappy NIC and cheap switch can cause such a headache.
I’m so used to having so many devices and tools at my disposal. Now, not so much.
Stone knives and bear skins…
Thanks George and Sebastian for all your help. I’m just trying to make one small step forward.
-
@Jeff-Findley Well you can either go with a cheaper switch or a used enterprise switch where you can enable RSTP, MSTP, port-fast or what ever the switch mfg calls it.
-
@george1421 Just an FYI - according to Netgear none of their unmanaged switches do any sort of STP. But who knows. When I bought this I did notice they have a very similar looking switch that is managed.
I’ll get another cheap one and see if that solves the issue.
Thanks again for the help and the great project. This has been a great tool to me over many many years.
-
@Jeff-Findley said in kernel interface not working:
Just an FYI - according to Netgear none of their unmanaged switches do any sort of STP. But who knows.
Yeah you never know. But beside STP we have seen a few cases where ethernet energy efficiency (EEE) stuff kicked in and caused such things. While it is possible to be EEE I still suspect George is right with STP…