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.

Then ran a normal Deploy task on this fully wiped disk. Result: same exact symptom. Stuck on Dell logo, unresponsive, after reboot.

I also manually selected “Boot from hard disk” from the FOG iPXE menu (instead of letting it fall through automatically) to rule out a boot-order/handoff issue — same hang.

So the stale-RAID-metadata-at-the-tail theory doesn’t hold up in this case, at least not as the sole cause — a completely zeroed disk with a fresh deploy still hangs. Back to square one on root cause, but happy to keep digging with more diagnostics if you have other ideas.

Terminology correction first: it’s not truly “hung.” The system stays responsive at the EC/keyboard level — pressing Caps Lock toggles the LED on and off reliably. So the machine is alive; it’s the display/firmware boot progression specifically that never advances past the Dell logo. F12 does not bring up the boot menu — the screen just stays on the logo, same as a normal boot attempt.

Critical new finding: this only happens after a FOG deploy. It is not tied merely to the drive’s physical presence.

To test this cleanly, I removed the NVMe, wiped/formatted it, and installed Windows fresh from a USB installer (not via FOG at all) onto the exact same physical drive, in the exact same machine. Result: it boots completely normally, no issue whatsoever, every time. F12 works, BIOS is reachable, Windows boots to desktop with no hang.

I then took that same drive and deployed the FOG image onto it (same image, same task). Result: back to the exact same symptom — stuck on the Dell logo, F12 unresponsive, indefinitely, on the exact same physical drive that had just booted a clean Windows install fine minutes earlier.

So the variable isn’t the drive, the brand, or even “a drive being present at POST” in general — it’s specifically whatever the FOG deploy leaves on that drive, compared to what a normal Windows Setup install leaves. Since Windows Setup typically converts/cleans the disk when you delete existing partitions and create new ones, while FOG’s resizable Partclone restore only writes the source partitions and leaves whatever sits outside those partition boundaries untouched — this seems to line up exactly with your stale-metadata-at-the-tail-of-the-drive theory. A regular USB Windows install would wipe that tail area as a side effect of repartitioning; a FOG resizable restore would not.

I’ll still run the diagnostic commands (wipefs, mdadm --examine, sgdisk -v, gdisk -l) in a Debug deploy task right after a deploy that reproduces the hang, and report back with the output, plus test your wipe-then-deploy sequence directly. I’ll also clear NVRAM and adjust the two BIOS settings you mentioned before retesting.

On /dev/md0: I didn’t set it manually, so if it’s not a FOG-side artifact, my best guess is it’s coming from something left on these drives before they reached me (factory RAID/IMSM config, or a prior imaging tool) — consistent with what you’re describing.

Will follow up with full command output shortly.

Two things before the questions.

First, one thing you can rule out on our side: FOS never writes UEFI boot entries. There is
no efibootmgr anywhere in the FOS image, so a deploy cannot leave a bad NVRAM entry
behind. Nothing on the server writes the Host Primary Disk field either — not full
registration, not Quick Registration, not inventory. The only writers are the host edit
form, the group form and the API. So the /dev/md0 you found was set by a person or by an
import, and it is a clue, not a side effect: /dev/md0 can only appear in FOS if an md
array was assembled, and FOS only does that when the host boots with the mdraid=true
kernel argument. That means one of those disks carried RAID (or Intel RST / IMSM) metadata.

Second, your symptom has been reported twice before on this exact family and neither
report reached a root cause:

• https://forums.fogproject.org/topic/14191 — Latitude 3400, resizable, stuck at the Dell
  splash, “the only fix is to wipe the drive and re-format it”
• https://forums.fogproject.org/topic/14147 — Latitude 3500, resizable, same, and the same
  cure

In both, the drive booted fine once moved to another Dell model, and only a wipe on another
machine made the 3400/3500 usable again. That points at the firmware stalling while it
scans the disk, not at Windows. A wipe removes more than the partition table — it removes
whatever is left outside the partitions FOG restores.

So the working theory is stale RAID metadata in the tail of the drive. A resizable deploy
writes the partition table and the partitions; it does not zero the rest of the disk, so
anything the factory install left at the end of the drive survives. Your /dev/md0 is
direct evidence that metadata was there.

Could you run these? All of them in a debug deploy task (tick Debug on the task), at the
shell, before you type fog:

wipefs /dev/nvme0n1                 # lists signatures, changes nothing
mdadm --examine /dev/nvme0n1        # and on each partition, e.g. nvme0n1p4
sgdisk -v /dev/nvme0n1
gdisk -l /dev/nvme0n1               # the header lines, including any warnings

Then, on a machine that is already hanging, the one test that separates firmware from
Windows: with the deployed drive in, does F12 reach the boot menu, or does the machine hang
before that too? And with the drive wiped (sgdisk -Z /dev/nvme0n1; wipefs -a /dev/nvme0n1) but nothing deployed, does it boot to “no bootable device”?

If the wipe-then-deploy sequence boots, that is the answer and we will make FOG clear those
signatures itself.

Two BIOS settings worth clearing on these while you are in there, both known to cause a
logo hang independent of FOG: set SupportAssist OS Recovery / “Auto OS Recovery Threshold”
to off, and set Fastboot to Thorough. Also clear NVRAM once, since a 3400 that has failed
to boot several times will have accumulated stale boot entries.

On your sanitize question: a VM capture needs sysprep /generalize /oobe /shutdown before
the capture, and that is the whole of it for hardware differences. It does not explain a
hang this early — generalize problems show up as a BSOD or a spinner, not as a freeze at
the vendor logo.