Failed to obtain lease on eth0 after ugrading to Fog 1.3.0

[george1421]

@asbenavides Whats really at issue is that you MUST enable one of the fast spanning tree protocols for the access ports. BUT right now we need to determine if spanning tree is the issue.

FWIW When a port transitions from no link to link up, with spanning tree on (and not fast stp enabled) the switch will listen on the port for 27 seconds to listen for other switch announcements. After 27 seconds the switch will start forwarding data. If you watch the FOS engine boot, its checking for a network connection in about 4 seconds.

[asbenavides]

@george1421 disabled the spanning tree on that port and still no luck

[george1421]

@asbenavides well that’s interesting in that it blew my current train of thought. OK so I guess the next bit is as I suggested register a host and then schedule a debug deployment. Hopefully it will drop you to a command prompt on the target computer.

[Tom Elliott]

Is this a USB nic that’s failing in this way?

[Jérôme DUTEIS]

Hello

we had the same problem yesterday …

i just went to switch settings / Layer 2 / RSTP / settings / enable port fast status
no more problems

We are using Alcatel switches

hope it helps

best regards , J

[asbenavides]

@Tom-Elliott its an Onboard NIC, I’ve already tired different models and I get the same error. But its confusing because with the 1.2.0 it was working fine…all I had to do was just pause it on the second nic configuration and it will work the only difference with the new 1.3.0 I cant pause on the third nic discovery…

[Wayne Workman]

@asbenavides said in Failed to obtain lease on eth0 after ugrading to Fog 1.3.0:

all I had to do was just pause it on the second nic configuration and it will work the only difference with the new 1.3.0 I cant pause on the third nic discovery…

How did you pause the third nic discovery in 1.2.0 ?

[asbenavides]

@Wayne-Workman by pressing the pause button on the keyboard but with the fog 1.3.0 it doesn’t work anymore on the 4th nic discovery

[george1421]

@asbenavides Just so I understand this correctly. During dhcp discovery you have been hitting the pause button to “freeze” the dhcp discovery for a bit, then when you release the pause it detects an IP address and the FOS engine continues to run as it should? And you have been doing this since 1.2.0?

If this IS THE CASE this condition still points to spanning tree not forwarding data right away. You MUST enable one of the fast stp protocols.

[Wayne Workman]

@george1421 I was thinking the init could be modified to look for a special kernel argument that tells hosts to wait. We are having portfast issues at work too, I’ve been thinking about this a lot.

[george1421]

@Wayne-Workman I know in the inits that the developers added the loop for the count of 4 for dhcp discovery, which I think the timing should have put it past the 27 seconds forwarding threshold. There should be two values. There should be a loop count and then a wait time you can play with. You “could” pass a kernel parameter to adjust either. It wouldn’t be that hard to extract the inits and update the code. This way if the kernel new parameter didn’t exist then the defaults would be used.

Just in case its not a spanning tree issue we have also seen issues with certain network adapters and green ethernet (802.1az). Typically a dumb (unmanaged) switch would mask this issue. But in the OPs case they are using a pretty old dell o745, and it doesn’t have any of the green ethernet stuff.

[asbenavides]

@george1421 I also tried a newer dell model 7020 and its doing the same issue as well.

[george1421]

@asbenavides said in Failed to obtain lease on eth0 after ugrading to Fog 1.3.0:

@george1421 I also tried a newer dell model 7020 and its doing the same issue as well.

That’s because I feel its a network issue (i.e. outside of FOGs control). The issue is proving its a network issue that is the tough part. Typically installing an unmanaged switch between the target computer between the target computer and the building switch will mask this issue, but it helps us point to the building switch at fault. Since all devices are doing this tells me it (the problem) is in common to all devices and all locations.

Another way to test is to plug the fog server and the target computer into an unmanaged switch and then plug the unmanaged switch into the building switch. Test this setup. If this works, then you will need to get a network engineer involved to look at your switch infrastructure.

[asbenavides]

@george1421 thanks that’s what im going to try if it works ill let you know

[asbenavides]

@george1421 okk the issue for the network is solved…the network engineer enabled the spanning tree portfast trunk on the cisco switch…now the task keeps saying “Attempting to check in”…Failed?

[Sebastian Roth]

@asbenavides Please check your apache error logs on your server (see my signature on where to find those). If you don’t see anything in the error log check the access log in the same directory. If you don’t see anything in either log then there is still a network issue, possibly layer 3 switch blocking HTTP?!

[asbenavides]

@Sebastian-Roth this is what the error log says "PHP Fatale error: Call to a member function getMasterStorageNode() on null in /var/www/html/fog/lib/reg-task/taskqueue.class.php on line 28

[Wayne Workman]

Possibly a db connection issue. How many fog storage nodes do you have? What’s the setup?

[asbenavides]

@Wayne-Workman only one fog setup and I already verified the boot file and everything else

[asbenavides]

@Wayne-Workman and only one Storage Node called DefaultMember as it was created by installation