https://forums.fogproject.org/topic/14571/imaging-windows-10-v2004-with-uefi-gpt-partitions-onto-31gb-or-smaller-drive-and-failing/3

Not sure if this has been resolved or if this helps -

I’ve created a Win 10 UEFI VM using the 2004 ISO. VMware Workstation 15 Pro 15.5.6 build-16341506. All the settings were default except I went up tp 8GB of RAM. I installed it, ran all the updates, activated it while waiting for updates, rebooted twice then captured the image with FOG dev-branch version: 1.5.9-RC2.11 running on Ubuntu 20.04 LTS

It deployed fine to a similar VM.

I built them in Hyper-V on Windows 10v2004 .

It was a coin toss on whether I witnessed the problem on over three dozen VMs, but I was able to overcome it on every one.

May I ask you to do the following: Let it try to capture a few times more. Every time you save a copy of the /images/dev/aabbccddeeff/d1.partitions (this aabb… is the MAC address of the host without colons) file to another location for us to compare those afterwards. Whenever you see the blkid... error you name it d1.partitions_fail_X (put in numbers instead of X) and if you don’t see the error you name it d1.partitions_ok_X.sfdiskPartitionFileName

What kind of VM do you use? I am wondering if I am able to replicate the issue using the same setup?!

New VMs today, and just to spite me, it failed on the warm reboot test. It worked after resetting to the checkpoint prior to the initial capture attempt. So it worked on a cold boot.

This is definitely the indicator that the capture will be bad.

blkid: error: /dev/sda4: No such file or directory

If I see this, I shut the VM down, revert the checkpoint and try again.

Testing further, but right now, Cold booting into the task appears to be the guilty party.

Wow that would be a really nasty one. Please keep us posted.

Failure scenario

1. Cold boot VM to Quick Inventory
2. Shutdown VM after the natural reboot after QI
3. Create Task
4. Cold boot VM into Task
5. Partition 4 is not recognized as fixed.

Success scenario

1. Cold boot VM to Quick Inventory
2. Pause VM after the natural reboot after QI
3. Create Task
4. Resume VM into Task
5. Partition 4 is recognized properly.

Testing further, but right now, Cold booting into the task appears to be the guilty party.

VM I’m working on now refuses to capture with partition 4 as fixed. It’s throwing the error during capture:

blkid: error: /dev/sda4: No such file or directory

Partition 4 is sometimes not identified as fixed size.

Is this something you can reproduce?

I made one change to the mastering process, to use Disk Management (diskmgmt.msc) within Windows to shrink the OS partition (to just 5GB free space) before sysprep and shutdown. It’s capturing partitions properly with fixed 1:2:4 so far.

Captured images are deploying properly to HDDs both larger and smaller than the original 64GB.

Today I created some more VMs. All with 64 GB drives. Essentially …

Capture VM1

cat d1.fixed_size_partitions
1:2

Capture VM1 a second time

cat d1.fixed_size_partitions
1:2:4

Capture VM2

cat d1.fixed_size_partitions
1:2:4

None will deploy to a drive smaller than the original 64 GB, though the data is only 12 GB uncompressed. It’s just a Windows install.

Looking at the 50 GB drive after a failed attempt to push the 64 GB image onto it. Diskpart reports a single 63 GB partition. wha?
Gnome Partition Editor shows the drive as 50 GB unallocated.

Dumping one of the 1:2:4 images onto a 2TB drive now; and it’s good.

So Partition 3, isn’t really resizing smaller when captured, and Partition 4 is sometimes not identified as fixed size.

cat d1.fixed_size_partitions
1:2

Is d1.fixed_size_partitions still set to 1:2:4 for this image?

Here’s the original on a 1024 GB drive after I’ve shrunk the partitions with GPARTED

And here’s the result immediately after going onto a 110 GB drive.

My original percentage math just happened to be a coincidence. But partition 4 is definitely not reproducing as intended.

I don’t know when I’ll be able to do another physical test, but I will check again, somewhen.

The size of partition 4 is obviously based on % of disk space used on original instead of maintaining the fixed size that is intended.

Really?? Can you please take a picture of Windows disk management after the deploy and first reboot?

Going from a 110GB drive, to a 1024GB drive, partition 4 grows by roughly a factor of 10. The size of partition 4 is obviously based on % of disk space used on original instead of maintaining the fixed size that is intended.

Yes, a recovery partition is desired.

This is a workaround I can live with for now, until a fix is developed, but it puts a kink in the deployment process as we must now ensure a system has a drive that is no smaller than the original system the image was built on.

Makes me think that FOG is resizing the wrong partitions when capturing, though it says it has detected the correct fixed size partitions.

A way to quickly fix this is using a partitioning too (probably even Windows disk management of your running system), shrink sda3 (C: in Windows) down to e.g. 400 GB, move the recovery partition forward as well (don’t think Windows disk management can do this but I am not sure) and then recapture the image.

d1.partitions

label: gpt
label-id: FB16BC47-E9A4-4A26-9E00-495F842C2401
device: /dev/sda
unit: sectors
first-lba: 34
last-lba: 2147483614
sector-size: 512

/dev/sda1 : start=        2048, size=      204800, type=C12A7328-F81F-11D2-BA4B-00A0C93EC93B, uuid=DB56A1C9-1019-46FE-9C8A-8D561A3E1DE4, name="EFI system partition", attrs="GUID:63"
/dev/sda2 : start=      206848, size=       32768, type=E3C9E316-0B5C-4DB8-817D-F92DF00215AE, uuid=B1AC3238-84AA-410A-97AC-7C2683A132C5, name="Microsoft reserved partition", attrs="GUID:63"
/dev/sda3 : start=      239616, size=  2146203765, type=EBD0A0A2-B9E5-4433-87C0-68B6B72699C7, uuid=D6FFACFD-59C5-4AAA-995C-539E27EAD00A, name="Basic data partition"
/dev/sda4 : start=  2146445312, size=     1034240, type=DE94BBA4-06D1-4D40-A16A-BFD50179D6AC, uuid=A7345D7C-3D3F-44E9-B556-6F89394B0C76, attrs="RequiredPartition GUID:63"

=-=-=-=-=-

d1.minimum.partitions

label: gpt
label-id: FB16BC47-E9A4-4A26-9E00-495F842C2401
device: /dev/sda
unit: sectors
first-lba: 34
last-lba: 2147483614
sector-size: 512

/dev/sda1 : start=        2048, size=      204800, type=C12A7328-F81F-11D2-BA4B-00A0C93EC93B, uuid=DB56A1C9-1019-46FE-9C8A-8D561A3E1DE4, name="EFI system partition", attrs="GUID:63"
/dev/sda2 : start=      206848, size=       32768, type=E3C9E316-0B5C-4DB8-817D-F92DF00215AE, uuid=B1AC3238-84AA-410A-97AC-7C2683A132C5, name="Microsoft reserved partition", attrs="GUID:63"
/dev/sda3 : start=      239616, size=    20614004, type=EBD0A0A2-B9E5-4433-87C0-68B6B72699C7, uuid=D6FFACFD-59C5-4AAA-995C-539E27EAD00A, name="Basic data partition"
/dev/sda4 : start=  2146445312, size=     1034240, type=DE94BBA4-06D1-4D40-A16A-BFD50179D6AC, uuid=A7345D7C-3D3F-44E9-B556-6F89394B0C76, name="attrs=\x22RequiredPartition GUID:63"

=-=-=-=-=-

d1.fixed_size_partitions

1:2:4