@sebastian-roth ,

Thank you very much! Changing CAPTURERESIZEPCT option from 5 to 8 has helped to capture image.

The description to this option is “This setting defines the amount of padding applied to a partition before attempting resize the ntfs volume and capturing it”.

As I understand this option impacts to partition shrinking and so to image size. Am I right?

@sebastian-roth ,

I’ve updated fog server as you suggested below. And I still run into this error.

The total score is 3:2. Three PC with big hdd disks were successfully captured and deployed to small ssd. Capturing another two big hdd disks ended with same error.
PS I successfully captured image from one of problematic PC with old acronis backup & recovery 10.0.12703.

@sebastian-roth ,

1. Changing Image Manager to Partclone hasn’t helped. The same error has occurred.
2. After update fog server from 1.5.8 to 1.5.9 I tried Partclone and Partimage one more times. The both was ended with same error.

@sebastian-roth , thank you for reply! I will try Partclone!

Fog tells that:

You are currently running version: 1.5.8
Latest stable version is 1.5.9

We are trying to replace old PC with hdd 500Gb to new PC with sdd 240Gb. Old PC is in Windows domain. So we capture old big hdd, and then deploy in to small sdd. We’ve tested this procedure with such image settings:

Image Type - Single disk (Resizable)
Partition - Everything
Replicate? - Yes
Image  Manager - Partimage

Two old big hdd were successfully migrated to new small sdd with such method.
But next two drives captures were ended in failure:

Collecting resizing constraints...
Needed relocation: 2486382 (10185 MB)
Schedule chkdsk for NTFS consistency check at Windows boot time ...
Resetting $LogFile .. (this might take a while)
Relocating needed data ...
100.00 percent completed
Updating $BadClust file ...
Updating $Bitmap file ...
ERROR(5): Could not map attribute 0x80 in inode 23779: Input/output error
(shrinkPartition)

How could we fix such error to successfully capture image?

@sebastian-roth ,

Thank you very much for reply!

Before deploying Windows 10 Pro x64 to PC, UEFI BIOS boot order is:
#1 - UEFI: PXE IPv4 Intel I211 Gigabit Network Connection
#2 - Windows Boot Manager
After deploying Windows 10 Pro x64 to PC, Windows 10 once changes UEFI BIOS boot order itself to:
#1 - Windows Boot Manager
#2 - UEFI: PXE IPv4 Intel I211 Gigabit Network Connection
How could I prevent Windows 10 to change itself UEFI BIOS boot order after deploying?

Some information:
I experience such problem on Asrock-X570 Phantom Gaming4, MSI Z370-A PRO, MSI H270 PC MATE, MSI H170A PC MATE motherboards. But MSI Z77A-G43 motherboard is OK, Windows 10 doesn’t change itself UEFI BIOS boot order after deploying.

Fog settings:
EFI BOOT EXIT TYPE - REFIND_EFI
BOOT EXIT TYPE - SANBOOT

Windows image: WIndows 10 20h2 Pro 64 bit with GPT partition tables

@george1421 ,

Thank you! What is the purpose of /opt/fog/snapins directory? Is it required for capturing? Or for deployment too?

Could I mount /images on separate drive (ssd) with nodev and noexec mounting options?

@george1421 ,

Thank you very much!
What do you think about installing FOG on the system with one hdd (mounted like /) and one ssd (mounted like /images)?
As I understand placing /images on ssd will help to improve deployment, because reading image from ssd is more quickly by comparison to reading image from hdd.