Thanks for the detailed breakdown — this is genuinely helpful, and I have some important corrections/clarifications after re-testing more carefully.
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.