@servicedesk-pianezza You are right and I was wrong. F2 hanging settles it. “Preparing to enter BIOS Setup” runs
before any bootloader, so the firmware is the thing that stalls, and my reading of the iPXE
test was bad. Ignore that whole post.
Your Windows 10 control is the best evidence in this thread. Same capture pipeline, same
FOG, same drive, same machine, and it boots. Together with “resizable and non-resizable both
hang”, that clears our resize path and it clears FOG’s table writing as a general fault: we
are laying down the captured disk faithfully, and this particular captured disk upsets this
particular firmware.
So the question is narrow now: which bytes? Two things, and the first one you can do from
your desk.
Diff the two tables. You have a good drive and a bad drive from the same pipeline. In a
debug task on each, capture:
sfdisk -d /dev/nvme0n1
sgdisk -v /dev/nvme0n1
gdisk -l /dev/nvme0n1
Post both sets. Partition count, order, types, attributes and the end-of-disk figures are
the things the firmware reads at enumeration, and a diff of Win10-good against Win11-bad
names the difference without any guessing.
Then bisect the disk, in this order. Start from a deployed drive that reproduces the
hang, and after each step power off, power on, press F2, and note whether Setup opens.
Destroy the partition table only, leaving every byte of partition data where it lies:
sgdisk -Z /dev/nvme0n1
If Setup now opens, the firmware is choking on the partition table — layout, types or
attributes — and not on anything inside the partitions. If it still hangs, the data is the
problem, so redeploy and zero the start of the ESP, which is the only partition the firmware
reads:
dd if=/dev/zero of=/dev/nvme0n1p1 bs=1M count=1
If Setup opens after that, it is the ESP filesystem, and we can bisect it file by file from
there.
Three questions while you are at it. Which Windows 11 build is the image, and which build
was the Windows 10 one? Was the Hyper-V VM Generation 2 with Secure Boot and a vTPM
attached? And what BIOS version are the 3400s on — Dell’s last for that model is in the 1.3x
range, and firmware is the component under suspicion now.
Also worth saying plainly: if this turns out to be the Latitude 3400 firmware choking on a
partition layout it does not like, there may be nothing for FOG to fix beyond documenting
it. Two earlier reporters on this hardware ended up rebuilding the image from a clean install
rather than finding a cause. I would rather find it, and your Win10 control is the first
thing anyone has produced that makes that realistic.
