@hvaransky I am assuming something is wrong with our kernel. I received this error when trying to run debug capture:
Latest posts made by hvaransky
-
RE: Capture stuck after 1st partition
-
RE: Capture stuck after 1st partition
@tom-elliott We are running 1.4.4 with what looks like Kernel version 4.11.0. We will try again with a debug capture task and see if it gets any further.
-
RE: Centos Help
@george1421 We were trying an HP 8200 Elite, however, we also tried a 4300 and got the same result.
-
Capture stuck after 1st partition
We are currently trying to capture a new windows 10 image and it keeps getting stuck after successfully capturing the first partition. It finishes 100% and then cloned successfully shows up at the bottom and it never goes on to the next partition. I double checked the image management and have windows 10 selected, image type is set to multiple partition image- single disk, and tried using both Partclone ZSTD on compression 11 or Partclone GZip on compression 9, and both stop at the same place. We also tried another computer and it still the same thing. Any help is appreciated!
-
RE: Centos Help
We have gotten further than you have, with using the undionly file, however, our image has 3 partitions, and only the 1st one will write. After it finished, it says cloned successfully and stops. We are also using CentOS with Fog version 1.4.4
-
RE: Rate is at a slow crawl when trying to deploy/capture image
@george1421 I couldn’t get the 2nd part of the command line to work as I kept getting permission denied. I was able to use the built in benchmarking on the disks menu to come up with the screenshot below:
We also double-checked all of the switches last night and all seem to be set properly and rebooted the FOG server. I am going to try to capture a new image with the ZSTD compression instead of Gzip. On the downside, after changing compressions on the image and it starting out super high transfer rate yesterday, it still took over 8 hours to complete and the rate almost bottomed out by the time it was an hour in.
-
RE: Rate is at a slow crawl when trying to deploy/capture image
@junkhacker We’re not really worried about compression size per say. We would rather it take less time for an image to deploy. (It was running at about 35 minutes per machine last summer and is now taking more than 7 hours to complete.) On the plus size, once changing compression size on the current image I’m deploying, it is predicted to only take about 3 1/2 hours to finish!
-
RE: Rate is at a slow crawl when trying to deploy/capture image
@tom-elliott I changed the rate down to 6 and deployed the image again. It started out at 10GB/Min, but within 10 minutes it is down to 247MB/Min. I’m at 44% completed with it running for an hour and 22 minutes, which is definitely MUCH better, but is there something else I need to adjust to get it even quicker? The rate is still dropping (it is going down at about 2MB every 3 minutes or so). Sorry for all the questions, I really am a newbie with FOG.
-
RE: Rate is at a slow crawl when trying to deploy/capture image
@tom-elliott I understand about the compression rates, but I’m not sure about the Gzip/ZSTD stuff. All of our images are set to partclone Gzip as per screenshot. Am I safe to assume that I have something set up wrong in the image management?
-
RE: Rate is at a slow crawl when trying to deploy/capture image
@wayne-workman I took 2 because I’m not exactly sure what we’re looking for. The compression is set at 22 and the image size is 465GB.