Categories

  • 13k Topics
    115k Posts
    G

    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:

    Capture a Windows 11 UEFI/GPT image with the above settings (Debug mode shows “Cloned successfully” with no errors). 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). 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. 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

  • Get the latest news on what's happening.
    184 Topics
    825 Posts
    A

    @Tom-Elliott I really appreciate that you are putting effort into providing more frequent releases, which makes it easier for everyone to deploy new security fixes in time. Keep up the good work!

  • View tutorials or talk about FOG in general.
    2k Topics
    19k Posts
    Tom ElliottT

    @ahaeder No:

    The idea of fog client is to rename the host based on what you name the computer within FOG, not the other way around.

    If you want it to be a specific name, and you have the FOG Client installed, set the wanted name in the FOG UI, and the host will change automatically.

  • Report bugs, request features, or get the latest progress.
    2k Topics
    21k Posts
    Tom ElliottT

    @scottrayr I’m not able to replicate the issue you’re seeing.

56

Online

12.8k

Users

17.6k

Topics

157.1k

Posts