Deploy task never marked complete on GPT/UEFI disks with "Single Disk - Resizable" + Partition: Everything — client reboots into infinite deploy loop

[GRISLET]

FOG version: 1.5.10.2482 (reproduced also on 1.5.10.1660 before upgrading — same behavior on both)
Base OS: Debian, Apache + PHP-FPM (proxy:fcgi on 127.0.0.1:9000)
Target OS being imaged: Windows 11, UEFI/GPT, 4 partitions (ESP, MSR, Windows, Recovery)
Image config: Image Type = “Single Disk - Resizable”, Partition = “Everything”, Image Manager = “Partclone Zstd”

Steps to reproduce:

1. Capture a Windows 11 UEFI/GPT image with the above settings (Debug mode shows “Cloned successfully” with no errors).
2. Deploy the same image back to the same physical machine, only swapping the disk (same hardware, same boot mode — rules out network/driver/boot-mode mismatches).
3. On the client, the deploy completes all local disk work correctly: partition UUIDs reset for all 4 partitions, GPT bootable-flag activation (“Activation is unsupported for GPT — entering nested PMBR…”), disks synced, then reboot — no errors ever shown on screen.
4. On the server side, the task is NEVER marked complete. On next PXE boot, boot.php tells the host to deploy again, re-downloading bzImage/init.xz and restarting the whole deploy — infinite loop.

Evidence from Apache access log (other_vhosts_access.log), filtered by client IP:

…
12:20:31 POST /fog/service/progress.php 200 (every ~3s throughout cloning)
12:20:34 POST /fog/service/progress.php 200 <- LAST call from client
[48s gap — local disk work: UUID reset, GPT flag activation, reboot]
12:21:23 POST /fog/service/ipxe/boot.php 200 <- client re-PXE-boots, asks server what to do
12:21:23 GET /fog/service/ipxe/bzImage 200
12:21:23 GET /fog/service/ipxe/init.xz 200
…

No request of any kind (successful or failed) appears between the last progress.php and the reboot — the client never attempts to signal task completion.

Already ruled out:

• Network/DNS/certificate issues (progress.php calls succeed with 200 OK throughout the entire clone).
• Image content/corruption (reproduced identically with a Clonezilla-produced partclone image manually placed in FOG storage, not just FOG’s own capture).
• Outdated FOG version (reproduced identically before and after upgrading server + client kernel/init to the latest stable 1.5.10.2482).
• Windows 11 “dirty bit”/Fast Startup (disabled, verified clean before capture; also irrelevant since Clonezilla-sourced image fails the same way).

Suspected area: the completion signal appears tied to the GPT partition-table recreation / resize path used by “Single Disk - Resizable”. Have not yet confirmed whether “Multiple Partition Image - Single Disk (Not Resizable)” avoids the issue — will update if I test this.

Happy to provide full debug-mode screen captures, video, or additional log excerpts on request.
I coudnt find information about this using IA o in this forum.

Thanks

[Tom Elliott]

@GRISLET The task is only marked complete by one request: POST /fog/service/Post_Stage3.php, sent by fog.imgcomplete as the last step of the deploy. Your log shows it never went out, so the script exited before reaching it.

You see no error because S99fog prints * Rebooting system as task is complete and reboots whenever /bin/fog exits, for any reason. A silent early exit is indistinguishable on screen from a real completion.

The 48-second gap points at where. fog.statusreporter posts progress.php every 3 seconds for the whole task and stops only when killStatusReporter kills it — which is the first line of completeTasking. After that line, only three things run before the completion POST. One of them is /images/postdownloadscripts/fog.postdownload, which is sourced into the imaging shell. An exit or a reboot in that script, or in any script it calls with ., ends the task before FOG is told about it.

Two things would confirm it:

1. cat /images/postdownloadscripts/fog.postdownload, plus any script it sources. Look for exit or reboot.
2. The last ten lines on the client screen before the reboot. Do Stopping FOG Status Reporter, * Task Complete and Updating Database appear? If they do not, the run ended early and the image type is not involved.

The image type is probably a red herring. Nothing between the end of the restore and the completion POST depends on Single Disk - Resizable.