Deploying captured Windows 11 golden image using FOG results in Windows only being able to boot into recovery

[lucamathuse]

Hardware/Environment:

Server: FOG Project v1.5.10 (Running on Ubuntu 22.04)

Target Hardware: 550x HP ProDesk 600 G6 SFF

Golden Image: Windows 11 Pro (fresh install)

Image Settings: Single Disk - Resizable, Partition Manager: Partclone Zstd

The Problem:

I am able to capture and deploy the image successfully (no errors during the PXE process), but upon reboot, the target machine immediately enters a Recovery loop with Error Code: 0xc000000f and File: \WINDOWS\system32\winload.efi.

Steps taken on Golden Image before capture:

Entered Audit Mode (Ctrl+Shift+F3) during OOBE.

Disabled WinRE:

reagentc /disable

Deleted the Recovery Partition via diskpart and extended to fill the disk (resulting in: EFI -> MSR -> C:).

Disabled Hibernation:

powercfg -h off

Verified BitLocker/Device Encryption is Fully Decrypted.

Made BCD agnostic:

bcdedit /set {bootmgr} device partition=\Device\HarddiskVolume1

bcdedit /set {default} device boot

bcdedit /set {default} osdevice boot

Ran Sysprep:

sysprep.exe /oobe /generalize /shutdown

My captured image directory looks like this:

total 5.9G
-rwxrwxr-x 1 fogproject fogproject    4 Apr  7 09:45 d1.fixed_size_partitions
-rwxrwxr-x 1 fogproject fogproject 1.0M Apr  7 09:45 d1.mbr
-rwxrwxr-x 1 fogproject fogproject  697 Apr  7 09:45 d1.minimum.partitions
-rwxrwxr-x 1 fogproject fogproject   20 Apr  7 09:45 d1.original.fstypes
-rwxrwxr-x 1 fogproject fogproject    0 Apr  7 09:45 d1.original.swapuuids
-rwxrwxr-x 1 fogproject fogproject  697 Apr  7 09:45 d1.partitions
-rwxrwxr-x 1 fogproject fogproject  697 Apr  7 09:45 d1.shrunken.partitions
-rwxrwxr-x 1 fogproject fogproject  15M Apr  7 09:45 d1p1.img
-rwxrwxr-x 1 fogproject fogproject  767 Apr  7 09:45 d1p2.img
-rwxrwxr-x 1 fogproject fogproject 5.9G Apr  7 09:54 d1p3.img.000

Observations:

• The target machine BIOS sees the disk as a generic “UEFI - WDC…” rather than “Windows Boot Manager” after deployment.

• Changing FOG Exit Type to rEFInd did not resolve the issue.

Has anyone encountered this specific behavior with Windows 11 on HP UEFI hardware? Or with FOG in general? I tried everything I could find but nothing is helping.

[mashina]

@lucamathuse Hi. I have faced similar situation on HP. I think your computers are going into recovery because the BIOS hasn’t updated its boot entries. So it still thinks it should load the old OS.

From the steps, I saw you fiddling with the Boot entries. I’m not familiar with that method, but at least on my computers, I don’t need to change anything. Just a sysprep -> Shutdown and capture.

Have you actually tried investigating whether the data has been copied to your disk? Do you see the boot directory? You should be able to drop into the CMD from that recovery or advanced option and investigate that.

I have deployed Windows 11 while the image type was Windows 10, and never needed to change anything.

[lucamathuse]

@lucamathuse Update

I found some more information that changes a lot of stuff. Instead of it deploying correctly and somehow magically landing in the recovery screen it turns out Clonepart messes something up when capturing and deploying. It leaves out some partitions in the config files and when I try to deploy it it skips C:\ completely thus leaving it in a RAW state. I have collected some outputs:

Image directory with all the files:

0-rwxrwxr-x 1 fogproject fogproject 6 Apr 7 12:18 d1.fixed_size_partitions 
-rwxrwxr-x 1 fogproject fogproject 1.0M Apr 7 12:18 d1.mbr 
-rwxrwxr-x 1 fogproject fogproject 873 Apr 7 12:18 d1.minimum.partitions 
-rwxrwxr-x 1 fogproject fogproject 20 Apr 7 12:18 d1.original.fstypes 
-rwxrwxr-x 1 fogproject fogproject 0 Apr 7 12:18 d1.original.swapuuids 
-rwxrwxr-x 1 fogproject fogproject 873 Apr 7 12:18 d1.partitions 
-rwxrwxr-x 1 fogproject fogproject 873 Apr 7 12:18 d1.shrunken.partitions 
-rwxrwxr-x 1 fogproject fogproject 15M Apr 7 12:18 d1p1.img 
-rwxrwxr-x 1 fogproject fogproject 767 Apr 7 12:18 d1p2.img 
-rwxrwxr-x 1 fogproject fogproject 5.6G Apr 7 12:27 d1p3.img.000

d1.partitions:

label: gpt 
label-id: 99934977-65D0-41C6-B5E0-92E8085EC24F 
device: /dev/nvme0n1 
unit: sectors 
first-lba: 34 
last-lba: 500118158 
sector-size: 512 /dev/nvme0n1p1 : start= 2048, size= 409600, type=C12A7328-F81F-11D2-BA4B-00A0C93EC93B, uuid=740FC648-717D-439E-9AC9-224A270007E2, name="Basic data partition", attrs="GUID:63" /dev/nvme0n1p2 : start= 411648, size= 32768, type=E3C9E316-0B5C-4DB8-817D-F92DF00215AE, uuid=45621D9E-3DD9-4D22-9D25-BCCDE3D0D714, name="Microsoft reserved partition", attrs="GUID:63" /dev/nvme0n1p3 : start= 444416, size= 498042880, type=EBD0A0A2-B9E5-4433-87C0-68B6B72699C7, uuid=F20FBC57-04B6-4522-9D20-33998BF119F9, name="Basic data partition" /dev/nvme0n1p4 : start= 498487296, size= 1628160, type=DE94BBA4-06D1-4D40-A16A-BFD50179D6AC, uuid=0D84E62A-99BF-4D91-A1D1-1B5D86FD2F45, attrs="RequiredPartition GUID:63"

d1.original.fstypes

/dev/nvme0n1p3 ntfs

d1.fixed_size_partitions

1:2:4

Windows partition layout:

Partition 	Type 	Size
1 	EFI (System) 	200MB
2 	MSR (Reserviert) 	16MB
3 	Windows (Primär) 	237GB
4 	Recovery (Wiederherstellung) 	795MB

I have no clue why Clonepart or FOG is doing this.

[mashina]

@lucamathuse From the metadata you posted, I do not see evidence that Partclone skipped the Windows partition.

d1.partitions shows p3 as the large Microsoft basic data partition, d1.original.fstypes shows p3 as ntfs, and d1p3.img.000 exists. That indicates the Windows partition was captured. That, by itself, does not prove that the deployed content is valid, but it does not support the claim that C:\ was simply left out.

So I think it is important to distinguish between these two cases:

1. The Windows partition was not restored at all
2. The Windows partition was restored, but the system is not bootable

Based on what you posted, this looks closer to the second case.

The reported behaviour also points more toward a Windows boot configuration issue than a Partclone omission. In particular, the manual changes you described on the Windows side — disabling WinRE, deleting/extending partitions, and editing BCD-related settings before capture — are much more likely to produce a recovery-only boot state than Partclone “skipping C:”.

If you want to prove that C is actually not being deployed, the correct test would be a debug deploy or checking the failed target from recovery/WinPE:

• confirm partition 3 exists
• confirm it is NTFS
• confirm C:\Windows is present

If those are present, then the problem is not that Partclone omitted C:, but that Windows cannot boot from the restored layout.

[lucamathuse]

@mashina I used a Windows bootstick to go into recovery and checked. All partitions are there but C:\ or the one that would be C:\ is RAW.
I modified my golden image files to “fix” the problem I’ve been having and here’s the output of the modified files:

Directory output:

total 5.7G
-rwxrwxr-x 1 fogproject fogproject    4 Apr  7 13:44 d1.fixed_size_partitions
-rwxrwxr-x 1 fogproject fogproject 1.0M Apr  7 12:18 d1.mbr
-rwxrwxr-x 1 fogproject fogproject  697 Apr  7 13:18 d1.minimum.partitions
-rwxrwxr-x 1 fogproject fogproject   59 Apr  7 13:44 d1.original.fstypes
-rwxrwxr-x 1 fogproject fogproject    0 Apr  7 12:18 d1.original.swapuuids
-rwxrwxr-x 1 fogproject fogproject  697 Apr  7 13:17 d1.partitions
-rwxrwxr-x 1 fogproject fogproject  697 Apr  7 13:18 d1.shrunken.partitions
-rwxrwxr-x 1 fogproject fogproject  15M Apr  7 12:18 d1p1.img
-rwxrwxr-x 1 fogproject fogproject  767 Apr  7 12:18 d1p2.img
lrwxrwxrwx 1 root       root         12 Apr  7 13:42 d1p3.img -> d1p3.img.000
-rwxrwxr-x 1 fogproject fogproject 5.6G Apr  7 12:27 d1p3.img.000

As you can see I used I symlink to attempt a fix of d1p3.img.000 and maybe that was my demise.

d1.partitions:

label: gpt
label-id: 99934977-65D0-41C6-B5E0-92E8085EC24F
device: /dev/nvme0n1
unit: sectors
first-lba: 34
last-lba: 500118158
sector-size: 512

/dev/nvme0n1p1 : start=        2048, size=      409600, type=C12A7328-F81F-11D2-BA4B-00A0C93EC93B, uuid=740FC648-717D-439E-9AC9-224A270007E2, name="Basic data partition", attrs="GUID:63"
/dev/nvme0n1p2 : start=      411648, size=       32768, type=E3C9E316-0B5C-4DB8-817D-F92DF00215AE, uuid=45621D9E-3DD9-4D22-9D25-BCCDE3D0D714, name="Microsoft reserved partition", attrs="GUID:63"
/dev/nvme0n1p3 : start=      444416, size=   498042880, type=EBD0A0A2-B9E5-4433-87C0-68B6B72699C7, uuid=F20FBC57-04B6-4522-9D20-33998BF119F9, name="Basic data partition

d1.original.fstypes

/dev/nvme0n1p1 vfat
/dev/nvme0n1p2 raw
/dev/nvme0n1p3 ntfs

d1.fixed_size_partitions

1:2

The changes I made resulted in partclone not breaking off after d1p2 and saying it’s done. Now it starts deploying d1p3 and stops after around 80% and gives me this error screen. I tried accessing the log they mentioned but it doesn’t exist on my FOG server.

I could try and fix this for days but how do y’all capture an image so that it doesn’t break or get captured in a wrong way? I just want a clean image of Windows 11.