@servicedesk-pianezza Those are clean tests and they kill my theory. Correcting the record, and then I think your
own last test moves this a long way.

The stale-metadata idea is dead. A zeroed disk with a fresh deploy still hangs, and
mdadm --examine found no superblock either side of the wipe. Drop it.

I also replayed our GPT restore path locally against a Windows 11 resizable image, onto a
disk deliberately smaller than the captured one — the same order FOS uses: dd of d1.mbr,
sgdisk -z, sgdisk -gl, then the filldisk table through sfdisk. The result verifies clean:
sgdisk -v reports no problems, the protective MBR is a single 0xEE entry spanning the whole
device, and first/last usable sectors match the target. So a malformed partition table is not
what we are looking at either.

Now the part I think you undersold. You reached the FOG iPXE menu and chose “Boot from hard
disk”, with the deployed drive fitted, and then it hung. That means the firmware finished
POST, brought up the NIC, ran iPXE and drew a menu — all with that drive present. The
firmware is not the thing that hangs. It hands off to bootmgfw.efi and the hang is after
that point.

Which reframes the symptom. “Stuck at the Dell logo” is not the firmware stalling. It is the
Windows boot chain hanging before anything repaints the screen, so the OEM logo simply stays
up. F12 being dead is expected there — the firmware gave up the keyboard at handoff. It also
explains the missing Automatic Repair: Windows’ boot-failure counter is incremented by the
boot manager, and a hang never reaches the code that does it.

So the question is now why this image hangs in early Windows boot on a Whiskey Lake Latitude
and not on a 12th-gen HP. Two things to do, in this order.

Deploy the same image to the same Dell as Single Disk (Not Resizable). This splits the
problem in half for the cost of one deploy. Both 2020 reports on this hardware said
non-resizable worked where resizable did not — see banana123 in topic 14147, “Using Multiple
Partition Image - Single Disk (Not Resizable) DOES work fine”. If non-resizable boots, the
fault is in our resize path, it is ours, and I will want d1.minimum.partitions,
d1.fixed_size_partitions and a full debug-deploy transcript. If it hangs too, the resize
path is exonerated and it is the image.

Make Windows tell you where it stops. Boot a Windows installer USB on the hung machine,
Shift-F10 for a command prompt, find the ESP letter with diskpart, then:

bcdedit /store X:\EFI\Microsoft\Boot\BCD /set {default} sos on bcdedit /store X:\EFI\Microsoft\Boot\BCD /set {globalsettings} bootmenupolicy legacy

sos replaces the logo with the list of boot drivers as they load, so the screen names the
last thing it got to instead of showing you a logo. bootmenupolicy legacy gives you the F8
menu, and Safe Mode is itself a useful result.

Last question, because you have not said it anywhere in the thread: was the image captured
after sysprep /generalize /oobe /shutdown, or from a VM that had simply been shut down? An
image captured without generalize carries the source machine’s driver and device state, and
booting on one chipset but not another is the usual way that shows up.

@Tom-Elliott
Multicast
cb765515-1c91-406f-bac6-c30fd8dca2e3-grafik.png
7d927a7b-ff64-4544-bdc1-f166768eeb5c-grafik.png
deee65ea-e430-40ff-b5e9-732fd60bf0de-grafik.png WhatsApp Image 2026-09-22 at 10.31.53(1).jpeg WhatsApp Image 2026-09-22 at 10.31.53.jpeg

root@fog:~/FOG_SERVER_Updates_durchführen# tail -n 40 /opt/fog/log/multicast.log [09-08-26 9:49:42 pm] * No new tasks found [09-08-26 9:49:52 pm] * No new tasks found [09-08-26 9:50:02 pm] * No new tasks found [09-08-26 9:50:12 pm] * No new tasks found [09-08-26 9:50:22 pm] * No new tasks found [09-08-26 9:50:32 pm] * No new tasks found [09-08-26 9:50:42 pm] * No new tasks found [09-08-26 9:50:52 pm] * No new tasks found [09-08-26 9:51:02 pm] * No new tasks found [09-08-26 9:51:12 pm] * No new tasks found [09-08-26 9:51:22 pm] * No new tasks found [09-08-26 9:51:32 pm] * No new tasks found [09-08-26 9:51:42 pm] * No new tasks found [09-08-26 9:51:52 pm] * No new tasks found [09-08-26 9:52:02 pm] * No new tasks found [09-08-26 9:52:12 pm] * No new tasks found [09-08-26 9:56:33 pm] ===== FOG 1.5.10.2473 -- MulticastManager starting ===== [09-08-26 9:56:33 pm] Interface Ready with IP Address: 10.10.3.196 [09-08-26 9:56:33 pm] Interface Ready with IP Address: 127.0.0.1 [09-08-26 9:56:33 pm] Interface Ready with IP Address: 127.0.1.1 [09-08-26 9:56:33 pm] Interface Ready with IP Address: 192.168.0.196 [09-08-26 9:56:33 pm] * Starting MulticastManager Service [09-08-26 9:56:33 pm] * Checking for new items every 10 seconds [09-08-26 9:56:33 pm] * Starting service loop [09-08-26 10:00:14 pm] ===== FOG 1.5.10.2473 -- MulticastManager starting ===== [09-08-26 10:00:14 pm] Interface Ready with IP Address: 10.10.3.196 [09-08-26 10:00:14 pm] Interface Ready with IP Address: 127.0.0.1 [09-08-26 10:00:14 pm] Interface Ready with IP Address: 127.0.1.1 [09-08-26 10:00:14 pm] Interface Ready with IP Address: 192.168.0.196 [09-08-26 10:00:14 pm] * Starting MulticastManager Service [09-08-26 10:00:14 pm] * Checking for new items every 10 seconds [09-08-26 10:00:14 pm] * Starting service loop [09-08-26 10:08:36 pm] ===== FOG 1.5.10.2473 -- MulticastManager starting ===== [09-08-26 10:08:36 pm] Interface Ready with IP Address: 10.10.3.196 [09-08-26 10:08:36 pm] Interface Ready with IP Address: 127.0.0.1 [09-08-26 10:08:36 pm] Interface Ready with IP Address: 127.0.1.1 [09-08-26 10:08:36 pm] Interface Ready with IP Address: 192.168.0.196 [09-08-26 10:08:36 pm] * Starting MulticastManager Service [09-08-26 10:08:36 pm] * Checking for new items every 10 seconds [09-08-26 10:08:36 pm] * Starting service loop root@fog:~/FOG_SERVER_Updates_durchführen#

I use two network cards—the “192” network is the one with the PCs, and the “10” network contains only servers and my backup servers …

Hi Tom,

In my case the culprit was /images/postdownloadscripts/fog.postdownload.

echo "Activating boot partition..." sfdisk --activate /dev/sda 1 echo "Rebooting..." reboot -f

Fix was simply commenting out (or deleting) those lines. After cleanup the file looks like this:

cat /images/postdownloadscripts/fog.postdownload #!/bin/bash ## This file serves as a starting point to call your custom postimaging scripts. ## <SCRIPTNAME> should be changed to the script you're planning to use. ## Syntax of post download scripts are #. ${postdownpath}<SCRIPTNAME>

Thanks for the pointer, Tom — saved me from chasing GPT partition tables for a problem that had nothing to do with them.

@servicedesk-pianezza Confirmed, and your fix is the right one. Thanks for the clear report.

The check was using the 24-character Base24 alphabet. That set is what you use to decode an older key into its binary form, and N is not one of its digits. It is not the set of characters a key is printed with. Windows 8 and later put N in the key itself, so any key carrying one was refused at entry.

There was a second half of the same bug. The browser keeps its own copy of that character list, for the masked display of a saved key. So even where a key with an N got stored, the page showed it as five groups of dots instead of keeping the first and last group. Both copies now say the same thing, and a test compares them character for character so they cannot drift apart again.

The test also runs Microsoft’s published KMS client keys through the validator, and checks that the characters Windows leaves out (A E I O U L S Z 0 1) are still rejected and the length is still exactly 25.

It is in PR #1773 against working-1.6: https://github.com/FOGProject/fogproject/pull/1773

It will be in the next beta build. If you would rather not wait, the one-character edit you already made is exactly what landed.