I’m going to gues this is happening with kernel version 4.16.6? I ask because I found earlier the kernel architectures were backward. I’ve corrected this on the server, so you should be able to redownload the kernels and have success.
@vince-villarreal I have same issue and I have been going through all threads regarding this particular issue. I have exactly the same issue and I feel it’s definitely going through a replication loop. I’ve been monitoring the replication log for past couple days and seems like the replication is stuck on one storage node. Keeps deleting the d1p2.img file and begins synching only to come back to the same file and replicate to same node again.
I should also mention I have reinstalled fog from scratch configured all nodes so initial replication of an uploaded image worked fine. It was indeed after an updated image upload when replication loop began.
@vince-villarreal what feature are you referring to? An image will deploy to a machine based on the storage nodes within a storage group. Assuming both storage nodes are in the same group, it uses a rudimentary load based system to determine which node to deploy the image from.
I have done this a dozen times in the last few weeks with no issues.
Essentially let http and other services through firewall (no need to disable it) and you can use the command:
to temporarily disable SELinux. Its up to you at that point if you follow the guide and permanently set it to permissive or if you take the time to set the SELinux contexts required for it to all work.
@joe-schmitt Yes. Kaspersky starts when the snap-in finishes.
Sometimes the FOG Client will crash on other snap-ins, but setting the service to automatically restart fixes that issue. This is the only snap-in that does not always reboot after it is completed. I’ll play around with it, maybe adding a wait-time after Kaspersky is installed to let it do whatever it needs to will help.
I did just think of a minor difference between the Windows 7 and Windows 10 images: for deploying Windows 7 to capture I create the partition structure manually using the latest version of diskpart, rather having Windows Setup build it. (This is because I build the image in a Hyper-V VM, but want to deploy it via UEFI, so I capture it as a WIM and re-deploy it on a UEFI compatible machine for capture.) It’s still the same structure, I just do it via diskpart.
This doesn’t appear to be standard activity or in line with the MS design guide. Most people don’t have this level of skills, so you may be one of the few who will run into this issue.
I take it the Hyper-V Gen1 VMs only have bios/legacy mode?
@cstfoguser does the image have an assigned storage group? Can you make sure it does? Go to the image-> edit -> storage groups. Ensure it’s got an assigned group, click the update/add as needed to ensure it does.