Failed to obtain lease on eth0 after ugrading to Fog 1.3.0
-
@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.
-
@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.
-
@george1421 I also tried a newer dell model 7020 and its doing the same issue as well.
-
@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.
-
@george1421 thanks that’s what im going to try if it works ill let you know
-
@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?
-
@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?!
-
@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
-
Possibly a db connection issue. How many fog storage nodes do you have? What’s the setup?
-
@Wayne-Workman only one fog setup and I already verified the boot file and everything else
-
@Wayne-Workman and only one Storage Node called DefaultMember as it was created by installation
-
@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?
-
@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 uefiI 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.
-
@asbenavides said in Failed to obtain lease on eth0 after ugrading to Fog 1.3.0:
"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
I think it’s best if you double check those storage node settings. Looking at the code I don’t really see why this is going wrong. Best if you can upload some pictures of the settings in the web gui so we can all check and find the issue.
-
-
-
@asbenavides I can already tell that your storage node password is set to password
In other words, it’s almost certainly configured incorrectly.
Please set the password to the one found in /opt/fog/.fogsettings
-
@Quazz okk i changed the password and image uploaded but when it was finalizing it says “Updating Database…FAILED”
-
@Quazz this is what i found under the IMAGES folder in the image was supposed to be named “windows10testing” and it placed the laptop lan mac address as the image name on the folder? how was that possible
-