@billvgn I’m trying to figure out the best way to debug this, because what is happening, shouldn’t be.
Is the issue with any model computer or only one specific model?
If we do a debug capture we might be able to catch it in the act of misbehaving.
Lets schedule another capture task, but before you hit the schedule task button, tick the debug checkbox.
Now pxe boot the target computer
after a few screens of text you will be dropped to the fos linux command prompt.
key in fog to start single stepping through the image capture.
keep pressing enter until after the first partition is captured by FOG.
At this point we should inspect the FOG server. In the /images/dev directory there should (better) be a directory with the name that appears like a mac address. Change into that directory and see if it has files. Right now don’t care how many file it has, only ensure that d1p1.img exists. It should be small since its just the efi boot partition. If its ok change up one directory, don’t stay in the capture directory or the capture will fail later at updating the database like you have.
now back on the target computer. If this is a standard windows image capture there should be 4 partitions, where the 3rd will be the largest and the 4th will be relative small since its just the recovery partition. Keep pressing enter until the 4th partclone upload is computer. Don’t press enter, but inspect the directory again make sure it has files / content but don’t go into that directory. The very next step should be the target computer will connect to the fog server using ftp and move the directory from /images/dev/<mac_address> to /images/<image_name>
Step by step single step through the capture while watching that /images/dev directory. That directory should disappear, but reappear in /images directory as the image name.
Somewhere in here its failing. Watch for an error message on the target computer.