@sbenson But the other location was fast at one time. Or the root of the issue is the location IS the difference that causes speed issues??

@sbenson No, we don’t use Avahi/LLMNR in FOG. The FOG installer does not set this up so I suppose you installed/configured it on the server manually?!

@Sebastian-Roth thank you for pointing me at the DHCP! I found the problem! All files are fine, but our company DHCP was not! After trying it in a seperated VMware Network it worked like a charm! So all the effort was in vain - i am sorry

We have an old fog running 1.4.4 in our DHCP config for managing the PXE Menu because we are running multiple (i)PXE Services in one subnet. I created a new boot menu item to forward the pxe boot to the new fog server.

like this:

iseq ${net0/mac} a0:36:9f:bd:XX:XX && goto testing || :testing set pxeserver:ipv4 FOG-IP set next-server ${pxeserver} chain tftp://FOG-IP/default.ipxe exit

Got it from here in 2017: https://forums.fogproject.org/topic/9648/add-a-second-pxe-boot-option

Worked fine, until now … And by now, i understand why no certification cmds were availibe because it got stuck in the old fog enviroment. Need sth. to reload the enviroment i think. I will take a look into it to find a way. Maybe i will open a new topic here!

Thank you @Sebastian-Roth for taking the time! Your scrips are fine - it was my fault …

@george1421 I didn’t know this was a multi-master setup, if that’s what you meant. I was referring to a video on just configuring a second node into an existing fog setup. With the new access control plugin and site plugin, multi-master setups are just that less a good idea.

As it stands now with the access control plugin, location plugin, and site plugin - the only benifit one stands to gain in a multi-master setup is some level of fault tolerance against the upstream box failing - and fault tolerance against the link failing - and for those two things you loose a comprehensive database/control center in a central location - a major drawback.

@Quazz Thanks, this will work, setting it to 87000 so it is just over 24hrs, that way I can unthrottle it and have the service start at 2am. Each image takes about 30 mins so I cannot imagine this being a problem at 7am when people start showing up. Thanks!

Already known about and fixed for RC 12.

@Tom-Elliott the backup was my fault. To gain access to the internet I have to swap cables. When I did the “real” dhcp server gave that server a different ip. The database had the old info.

@sbenson No you don’t, disk expand automatically

Crosslinking similar threads:
https://forums.fogproject.org/topic/8601/ipxe-boot-php-hanging-on-capture