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 .
-
@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.
-
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?
-
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.
-
@kleanthis The “old environment” is completely separate from the now new “FastEthernet” system?
-
@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).
-
@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 ??
-
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.xzWith 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)
