Failed to obtain lease on eth0 after ugrading to Fog 1.3.0

[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

[Wayne Workman]

@asbenavides Is the DefautMember marked as master? Also, check and see if the image is set to the Default group ? Image Management -> List all images -> click the image -> Storage Group. Is the default group there? Is it marked as primary or not? I’m not asking you to change anything, I’m just gathering info. What is your maximum clients set to? Storage Management -> click DefaultMember -> Maximum clients. Are there other pending image deployments in Task Management?

Also, can you post a picture of the error?

[george1421]

@Wayne-Workman OK to state where we are (still not happy but…)

We’ve got past the pxe booting and are now at the exit mode for uefi

I would like you to unhide the FOG iPXE menu for a few tests. I want to ensure that you can make menu selections and have the target system function correctly. What I’m interested in is the compatibility test, check for both network and storage media. I also want to ensure that you can register a target computer using the ipxe menu. If you can do that then the target and fog communications are working well.

The part I think is failing is the exit mode for these devices to boot from the devices internal media. But lets take one step at a time and test each bit then work on the exit modes (usually what causes the most pain once you get the FOG iPXE menu to display).

OK scratch that, I missed the post with the error about the storage node.