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!

A test for anyone having this issue. I did a little trouble shooting, and if you go to: Reports > Pending Mac List and approve all the pending mac addresses at once, performance improved somewhat.

I am unsure if this is coincidental but for me my “Hosts” tab is now much more responsive. Same thing with the “Fog Settings” tab. Give that a try. Certainly worked for me for the moment.

@Tom-Elliott I also updated to 1807 and it has fixed it for me as well. As always Tom you are a mad scientist and always figure out the issue. FOG Project is the fastest bug resolution of any software we use and I mean that sincerely. I appreciate this software and your dedication to it so much, thanks for everything!

@Tom-Elliott I also updated to 1807 and it has fixed it for me as well. As always Tom you are a mad scientist and always figure out the issue. FOG Project is the fastest bug resolution of any software we use and I mean that sincerely. I appreciate this software and your dedication to it so much, thanks for everything!

A test for anyone having this issue. I did a little trouble shooting, and if you go to: Reports > Pending Mac List and approve all the pending mac addresses at once, performance improved somewhat.

I am unsure if this is coincidental but for me my “Hosts” tab is now much more responsive. Same thing with the “Fog Settings” tab. Give that a try. Certainly worked for me for the moment.

@Tom-Elliott Yes we utilize the LDAP Plugin for all logins. Version 1.5.5, I will tried logging in with a local account but the slowness persisted.

@Tom-Elliott I collected both log files and sent them to you directly via “Chat”. you should see all of them in there. Thanks so much for investigating this issue.

@Tom-Elliott Thank you for looking into this. Are there any log files from my setup I can provide that would help you? For reference, my server environment is:

Dell Poweredge R620
2x Intel Xeon E5-2640vs 2ghz CPUs
128 Gb ram
Alma Linux 9.7
Fog 1.5.10.1804 (was 1798)

@Infojoe I am getting this exact same issue. Very long load times on the “Hosts” and “FOG Configuration” pages. Additionally there is a number now appended to the front of all the hosts for some reason.

I updated to the latest dev branch version 1.5.10.1804 hoping for a fix, but alas, no change. I applied patches to Alma Linux 9.7 and rebooted but still seeing high CPU on several processes including apache. I am happy to test anything and everything to assist in fixing this issue.

@george1421 Thank you for this suggestion. This disabling of “fastboot” worked PERFECTLY! I interrupted the OOBE with Shift + F10 and got the command line window. I shutdown using the “shutdown.exe -s -t 0” command you suggested. Then after booting up, the FOG capture task I had already started took over and it captured 100% as it should have.

Essentially, I had forgotten to disable fastboot like I normally do on EVERY computer I have. So when it “rebooted” it technically wasn’t rebooting the device since fastboot is a misguided absurd hibernation feature Microsoft developed. The error I got was nearly identical to the one in the original post.

Thanks so much for this suggestion George and all!

@Tom-Elliott Thank you so much Tom, as always I appreciate your support and guidance.

@Tom-Elliott

So, does that mean I should install the new one at the top? Or do I have the new one already by virtue of installing back in July? Sorry versioning gets confusing for me. Also what is FOS?

Our Fog instance updated to Kernel version 6.12.35 sometime over the summer. Since then new Kernel versions have been showing up under the Fog Configuration > Kernel Update menu per normal. The version number on these new versions however keep showing 6.12.35, the same that we already have. The first 6.12.35 shows July 15th as the date, but the newest 6.12.35 shows October 14th as the date.

Is this a bug only affecting us? Should we just update to the new version even though it shows the same number? Anyone else experiencing this? I just want to make sure I have the latest Kernel for new devices we purchase. Thanks everyone!