@newlined you can fix this Behavior if you remove the /var/www/fog and then do: sudo ln -s /var/www/html/fog /var/www/fog

What version of FOG are you running? The simplest method to enforce a replication to begin again is to simply restart the FOGImageReplicator service.

For most this is accomplished by doing: sudo systemctl restart FOGImageReplicator, similarly Snapin Replication would be: sudo systemctl restart FOGSnapinReplicator.

There is currently no way to force a replication to begin via the GUI. This is because the services are at the linux level and run on boot up as root. These FOG Services (FOGImageReplicator, FOGSnapinReplicator, FOGPingHosts, FOGSnapinHash, FOGScheduler, FOGMulticastManager, FOGImageSize) run separately from the GUI environment. That said, you can adjust the times that these cycle via the GUI, and it will receive its information on the next run cycle.

created another group and linked to the 35 nodes, traffic was ceased

0_1532717283762_76cf347b-343b-4041-8db1-caa3338e7bd3-image.png

Please mark this as solved.

I was replacing the Kernel here /var/www/fog/service/ipxe and it was suppose to be here /var/www/html/fog/service/ipxe.

Kernel 4.15.2 works if it’s installed in the right place. Sorry for wasting your time.

@Amerhbb This is an interesting one. Seems like this is something from the Linux kernel itself: https://github.com/torvalds/linux/blob/master/drivers/firmware/efi/efibc.c

Not really sure what do advice yet…

@kermit1991 Try following George’s great instructions here: https://forums.fogproject.org/topic/11202/fogcontroller-class-php-undefined-offset-3-line-1046

@sebastian-roth I captured the image i used the primery host disk parameter.
Thanks

@jj-fullmer Thanks alot

@tom-elliott
OK that would make since. I’d say that is not an issue.

I was jumping back and forth from 1.5.4 to 1.6 yesterday trying to get some kind of stability. Currently I’m on 1.5.4 and have moved on to other projects. But… Would love to get things going again to multicast. PM me if you have any ideas please.

Thanks!

I tried editing the file and rebooted the server. Fog services no longer started. I will try to wait for the new version of Fog and only image 5 clients at a time…

@tom-elliott
Yes, I found the issue was that I had picked the wrong option on the new Profile. It was set to PartImage instead of Partclone. Changed that option and it deployed properly.

@tom-elliott When I updated the master to the working branch, the three nodes immediately reconnected. I then updated the nodes too. (Two nodes are offline, will get them updated when they get back online). I also realized that some of the memory in the server wasn’t showing up. I think that is a large part of the problem. Ordering some more now…

@george1421 Hi George,

The issue was fixed, need to test it on more machines to make sure it’s a global a fix, but after isolating the boot drive using debug mode it appears to be deploying to the correct drive. I used /dev/sda2 as my host primary disk.

I’ve attached a photo of the drives available to the fog.

I’ll! keep you updated on this and thanks !

Bill.


@tombagley ignoring a mac in fogs webif just ignores it for the specific host not the whole system!

@waynejitehead i simply remove the usb nics mac after deployment because it does not belong to the system, this way new hosts with same usb nics mac will propperl recognized.

Regards X23

@bmacadre Try to put the FOG Server on one of the 100Mbps ports. This would obviously severely hinder unicast imaging, but if you’re mostly doing multicast then this might work better.

@george1421 Fog has been working, but I haven’t had any machines to test a multicast on since we last spoke. I am going to attempt to image a classroom today and will report back.

@george1421 I replicated my images using rsync and verified that all images are in both locations. I also have a backup of my images off of both of the nodes. I went in and I created a new Storage Group. I associated the Storage Node that is not the Master Server with the new Storage Group. I then associated a number of my images with that Storage Group. My goal is to have some images only reside on the node in the new Storage Group and some only reside on the other Storage Group. I set both servers to be the Master Node for their Storage Group. Based on the warning I read about setting a server to the Master Node I half-way expected for any images that were not associated with that Storage Group to be purged from the Master Node but that didn’t seem to happen, which is fine. Is it now safe to go back and purge images from servers via cli if they reside in an image store on a node that is not in the Storage Group that is associated with that image? Thank you!