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

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).

george1421

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

New Switches were installed that only have FastEthernet

?? FastEthernet == 100Mhz ??

Tom Elliott

While I doubt this will fix the problem, I do hope to have a nicer approach to having a device receive an IP Address now.

As stated before, the current mechanism just waited for “ANY” ip address to be assigned to any NIC as needed. As long as it received an IP address (regardless of if that IP could communicate to the FOG Server) it would break out and try “driving” forward with the tasking.

I’ve added what I hope will allow a more dynamic approach to detecting the real fog network. Would you mind giving a try using the init’s and instructions here:

wget -O /var/www/fog/service/ipxe/init.xz http://mastacontrola.com/init.xz
wget -O /var/www/fog/service/ipxe/init_32.xz http://mastacontrola.com/init_32.xz

With this, you’ll also get the latest fixes from last night in regards to resizing code bits and what not. (This isn’t a bad thing)

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

256

11.6k

17.1k

154.6k