Network Technician at Cayuga Community College
Found the issue! After some research and discussion with Cisco, we had to add “PIM” to the vlan on our core, even though both the server and client are both on the same vlan!
Used the command - ip pim sparse-dense-mode on vlan 1 interface and it started working like a charm! I really appreciate everyone’s assistance here. This will help our institution so very much.
As always, the community comes through! Not sure how this got askew, but following these directions I was able to fix the issues. The image pulled correctly and at the end updated the database info. The image is good, I am all set. Thank you again this was awesome!
@Tom-Elliott Good thinking, I just attempted that but it seemed to make no difference. My clients still seem to hang on the partclone screen. I did reach out to Cisco to check to see if my 6509E core switch has all the correct settings on it for multicasting. I also made sure the port the server was on is using “port-fast”. It worked like a charm the moment I plugged it into the edge switch. I will do some more testing while I wait for Cisco to answer me back. Sorry for all the back and forth with this, I really do appreciate this product, it’s developers, and the dedicated community behind it.
@george1421 I watched during the deploy but didn’t see anything relating to which bzimage version it is using. Odd. I have a feeling it is still using the other bzimage. I am going to test by backing up the current 4.19.101 bzimage and renaming the bzimage533 to “bzimage”. Just a temporary test.
@Sebastian-Roth Testing with newer init with partclone 0.3.13 and kernel 4.19.101 seems to fix my slowness in deployment of images. I am seeing speeds of 9GB or more in my testing now. I am guessing it is the partclone that is causing the slowness in some environments. Will continue to test and utilize 0.3.13 partclone to verify theory.
@george1421 I will certainly never try to upgrade CentOS forklift style again. You were correct I upgraded Centos from version 7 to 8. After the mess it created I took your advice and ran the FOG installer using “GIT” and it cleaned up a bunch of the issues. A BOAT LOAD of things were missing after the upgrade but now they are functional. Thank you for all the assistance, FOG’s community and dev team is top notch.
Finally finished a brand new image this morning where we started from a fresh Windows install. The image captured without an issue. I suspect the age of our previous image was to blame for the issues with the capture. I think recent Windows updates by Microsoft to the recovery partition may have modified the size or something else in those recovery partitions.
New image pulled using the 6.6.34 Kernel, and then deployed successfully as well. If anyone is having issues related to the errors I posted above, I would try the CHKDSK + defrag/trim, and if that doesn’t work I recommend rebuilding your image from a clean Windows install with the absolute latest Windows enterprise installer.
Thank you Tom and crew for all the excellent technical assistance!
UPDATE
After some investigation, I found that if I connect to FOG using the FQDN, the Kernel versions show. If I connect via IP address, which I had been previously, it doesn’t show. This was on a machine with our Endpoint protection enabled. On a machine without any endpoint protection, both IP and FQDN show the Kernel versions. Strange, must be some sort of overzealous web protection on the part of our endpoint software. Thanks for your help @Tom-Elliott !!!
@Tom-Elliott Correct, in yours you see the bzImage and arm_image, but in mine it is totally blank for some reason. Been like this for quite a while and I have no clue what I did to cause it. Unless it is potentially just a browser issue or something with my PC only?
Current version - 1.5.10.1598
Several versions ago, I found t hat under the “Kernel Update” tab, it no longer shows me which Kernel versions I have installed. If I clicked on “Default Member FOG Version: ()” it would list what versions of the kernel were installed. It stopped working some time ago, and I didn’t mess with it. Is there an easy fix for this? I have tried updating and a few small changes but no luck. Not a huge deal, but would like it back if I can. Thanks everyone!
Finally finished a brand new image this morning where we started from a fresh Windows install. The image captured without an issue. I suspect the age of our previous image was to blame for the issues with the capture. I think recent Windows updates by Microsoft to the recovery partition may have modified the size or something else in those recovery partitions.
New image pulled using the 6.6.34 Kernel, and then deployed successfully as well. If anyone is having issues related to the errors I posted above, I would try the CHKDSK + defrag/trim, and if that doesn’t work I recommend rebuilding your image from a clean Windows install with the absolute latest Windows enterprise installer.
Thank you Tom and crew for all the excellent technical assistance!
@Tom-Elliott Was going to try, but discovered that after the last CHKDSK, the FOG Client wasn’t running correctly. Now I can’t uninstall or reinstall it correctly. I think for now I am going to re-create this image from scratch. I am speculating that since this was an older image that we had added onto several times, that a Windows update of some kind caused partition issues of some sort. I plan to format and install Windows from Scratch, and then build the image and pull it tomorrow. If this works I will report back with my findings.
In the meantime, are there any logs that I could send that would help you or anyone else who also finds themselves having this issue? Happy to assist in any way I can. I sincerely appreciate all the support and assistance on this.
@Tom-Elliott I believe you are correct. I ran a CHKDSK /F and it repaired the disk, but now I am faced with a new error. It claims “could not allocate new MFT record: No space left on device” and several other issues. Not sure where to go from here other than perhaps start a new Fresh Windows image? 
Thank you, while looking at the log, I noticed an oddity and after reinstalling the FOG client, it is now fixed. I appreciate the assistance in helping me track down this problem. The tasks are working correctly when coming from the FOG server itself now. I appreciate it!
@Tom-Elliott So, does that mean I need to add port 80 and 443 to an inbound TCP rule on the machine I am trying to capture from? The client seems to not pick up the task no matter how long I wait. I assume it shouldn’t take more than 60 seconds or so.
Thank you for helping with this.
@Tom-Elliott said in Cannot capture image: run lists overlap:
nfs-kernel-server
I am getting this error in 1.5.10.41 after updating. I am running on CentOS 8. I restarted my NFS Server, but that didn’t seem to do anything. I noticed that the NFS “interfaces” were pointing to something other than my servers interfaces so i changed those to match what the server says is the network interface. Not sure if NFS interfaces are something different or they should match as well? Any assistance on how to troubleshoot this would be great as I have an image to capture and at this time can’t accomplish that.
We are a FOG Server school, and we utilize the .13 client. We are on version 1.5.10.41 which we recently updated to. When we attempt to start tasks, the client on the machines don’t seem to execute the tasks regularly. I am thinking it is because we are missing firewall rules on the machine we pull the image from, but am unsure. Are there specific ports we should be adding on the client itself in Windows Firewall? If so, what are they, and are they inbound, outbound, TCP or UDP?
Any assistance would be appreciated. We have the FOG client itself in the Windows Firewall inbound list, but doesn’t seem to have changed anything.