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

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