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.
@Tom-Elliott Thank you very much! This will help us greatly as we image off hours or when others want to monitor the duration of imaging and such. Thank you so much!
Respectfully requesting a modification to the data “Image Completion Task” emails contain. The feature is excellent, one small request would be to add the following lines in the email sent:
Image Duration (in other words, how long the task took to complete)
IP Address of the host that was imaged
The image duration is the most important as sometimes we start images before leaving for the day, or sometimes our supervisor requests that sort of information about an image task. Thank you for your consideration!
I suspect this already had the fog client at some point. We image the same machines over and over for various reasons in our labs and in our classrooms. Is this not supported by FOG? Is there some procedure I should be running before we image the machines or something?
From the GUI is there any way to search via mac address?
Thank you Wayne, I use a deployment program to install the client so I figured it should work just like the others in the lab did. It is odd, like 25 will work, and 4 will fail in one room. By “fail” I mean not show up in the client. Attached is the log. I notice the response module fails but I don’t know what that means.
I have several hosts in several computer labs that don’t show up in the console when we install the FOG client. They just never show up in pending hosts or in “hosts”. It is possible we have installed the client on them previously and maybe that is the issue? I tried resetting the encryption data on all of the hosts but it didn’t change anything.
In any event, is there a way I can globally fix this? I considered that 1.5.9 might fix this issue as every update seems to fix problems all over the place but I was curious what the community thought.
I realize this post is a bit old, but I wanted to thank everyone for their suggestions and give our experience to back up what has been said in this topic already. We experienced an image that should have been about 120gb, but was showing in FOG as the full 500GB hard drive. After referencing this thread, it fixed the issue. The steps we took are below in order:
Verified that the PC didn’t have a second drive or second large partition it was capturing
Verified that bitlocker encryption was OFF using the command prompt command “manage-bde -off C:”
Ran Disk Cleanup (to get rid of old unused files)
Ran Tools > Check to scan for hard drive errors (may require reboot to fix)
Ran Tools > Tools > Optimize and defagment
Capture Image again
Once we did those steps, the newly captured image only takes up the actual amount used on the hard drive.
@Sebastian-Roth Thank you for all you and everyone does. I agree with you this was a good choice to make a second topic out of. This is working well now and I greatly appreciate all the assistance!
@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.
@Sebastian-Roth Can confirm that after testing this in my environment with the new init (partclone 0.3.13) and the latest dev Kernel specified, things are back to fast again. Average in my environment was somewhere around 9/GB per minute.
@Sebastian-Roth My apologies if this is too forward, but would the latest build with 0.3.13 be able to be installed by myself as well? I would love to test 0.3.13 to see if it fixes my slowness issue as well. I would gladly report back my findings.