Failed to get an ip from DHCP ! Tried on interfaces eth0 eth0 .

george1421

/dev using udev : error creating epoll fd

That is just a warning message and is not related to your current issue.

OK I think the next step is to manually register this device and setup a debug capture/deploy (what ever you were doing). A debug deploy/capture will instruct the FOS engine to drop you to a command line on the target computer. From there we need to do some debugging commands like ip addr show to see if any ip address is being picked up by any interface.

OK so can we say that RC10 was also defective in regards to this system too?

kleanthis

One more thing . I have tried now on the 3rd lan port of the box . Intel Agent 1.2.6 and not 1.3.x loaded . Fog was able to grab an ip now , register and start deployment . What could be causing this ? Lan 1+2 with Intel Boot Agent 1.3.x dont work but Lan 3 which loads with Intel agent 1.2.x loads just fine . I am waiting to see if the deployment finishes fine.

kleanthis

@kleanthis So it looks like it does not work with Lan 1 and Lan 2 but only with LAN 3 . I dont know why though . Can you check ?

george1421

@kleanthis it would be interesting (again) to setup a debug deploy/capture to get access to the FOS engine command line. I’m suspecting that FOS is setting the eth0, eth1, eth2 order based on hardware discovery order, which seems to be inconsistent with what the iPXE kernel is doing.

kleanthis

Is there a guide on this ? Debug deployment?

george1421

@kleanthis Its simple. Just schedule another capture/deploy to the same target. Since you have LAN3 working use that interface. But before you submit the task select the check box that says debug.

This tells FOS to not start the task automatically but drop the user to a linux command line. This is what the developers use to debug the FOS engine.

kleanthis

@george1421 ok so use lan 3 (the one thats working) for the debug deployment?

george1421

@kleanthis what we “need” is to get to the linux command prompt on the target computer THEN key in ip addr show, or ip link show. From the output then we can see the reference between ethX and mac address. That will help us identify what FOS “thinks” eth0 is.

Don’t worry about breaking what you were just able to do, we are NOT going to start the deploy/capture as long as debug was enabled.

george1421

@george1421 When you get to the FOS command line, if you give root a password, you can connect to the FOS engine via putty to help with any copy paste operations you need.

at the FOS command line key in ip addr show to get the device’s IP address
then key in passwd and give root a password. It doesn’t matter what password you give it, as long as its not blank. From there you can connect to the FOS engine using putty and login as root and what ever password you give it. Then you can run the debugging commands from there.

Tom Elliott

@kleanthis This connecting via putty is nice because you can copy/paste the contents of the output from commands we might request.

kleanthis

There you go :

[Fri Mar 17 root@fogclient ~]# ifconfig
eth0      Link encap:Ethernet  HWaddr 00:0B:AB:70:9A:21
          inet addr:192.168.1.111  Bcast:192.168.1.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:1600 errors:0 dropped:0 overruns:0 frame:0
          TX packets:67 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:183345 (179.0 KiB)  TX bytes:15605 (15.2 KiB)

lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

[Fri Mar 17 root@fogclient ~]# ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast qlen 1000
    link/ether 00:0b:ab:70:9a:21 brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.111/24 brd 192.168.1.255 scope global eth0
       valid_lft forever preferred_lft forever
3: eth1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop qlen 1000
    link/ether 00:0b:ab:70:aa:69 brd ff:ff:ff:ff:ff:ff
4: eth2: <BROADCAST,MULTICAST> mtu 1500 qdisc noop qlen 1000
    link/ether 00:0b:ab:70:aa:6a brd ff:ff:ff:ff:ff:ff

george1421

@kleanthis OK now we know the order that FOS is seeing the interfaces.

eth0: 00:0b:ab:70:9a:21 (192.168.1.111)
eth1: 00:0b:ab:70:aa:69 
eth2: 00:0b:ab:70:aa:6a

If this was a typical “server” I would say that eth0 is considered an add on network adapter (which is typically discovered first) and then the built in network adapters (eth1 and eth2). Where eth1 and eth2 mac address are consistent with a dual port network adapter. What’s happening is understandable.

For the sake of discussion, if you plug in the other two nics and run the ip addr show again, do the other interfaces get an IP address too? You may loose access via putty when you do that, but you can still key things in on the FOS console.

The bigger question now is why isn’t FOS testing each network interface for an up link. Right now it sounds like its giving up after testing eth0 (LAN3) and not continuing to loop.

kleanthis

@george1421 Nope , the other two lan ports dont get an ip . Their leds dont even come on . Its like they are unplugged or not activated. As soon as i plug the cable on lan 3 lights come up.

Tom Elliott

@kleanthis this is kind of by design, as @george1421 was saying earlier.

It’s not caring “what” the IP address is. The idea is, get an IP address, and as soon as one is available continue forward with the tasking. Otherwise you’re waiting for each interface to come up before your tasking can start. (This can be a bad thing if there is nothing for the device to pick up).

kleanthis

@Tom-Elliott Well why cant my lan 1 and 2 get an ip but lan 3 can . This is my actual question . Otherwise when an os is installed all lan ports work fine .

Tom Elliott

@kleanthis I don’t know, that’s what we’re trying to get to the bottom of.

There are any number of reasons why, and it seems (to me) that possibly Spanning tree, or Power Saving features are preventing things from “normally” happening.

Tom Elliott

What’s even more boggling, to me, is your post that it just “started” happening. “Everything worked fine until suddenly today I am having this issue.”

Did something in your networking environment change?

kleanthis

New Switches were installed that only have FastEthernet , but because i thought of that as well i tested it in my old environment Gigabit downstairs were it was working before. and still same issue.

Tom Elliott

@kleanthis The “old environment” is completely separate from the now new “FastEthernet” system?

george1421

@kleanthis said in Failed to get an ip from DHCP ! Tried on interfaces eth0 eth0 .:

@Tom-Elliott Well why cant my lan 1 and 2 get an ip but lan 3 can . This is my actual question . Otherwise when an os is installed all lan ports work fine .

(sorry working at my real job right now).

What I find stange is that the link light is not coming on, on this lan1 lan2 interface. The link light is a hardware/software function. If there is a functioning network jack, the light should come on.

From the FOS side, its seeing the network adapters AND talking to them since its getting a mac address from the network adapters. So FOS is happy with the network adapters.

I might understand why they are not getting an IP address depending on how FOS manages the network adapters. We may need to issue the dhcp command again on these interfaces (once we can understand why they link light is not coming on).

Failed to get an ip from DHCP ! Tried on interfaces eth0 eth0 .

156

11.7k

17.2k

154.7k