Working in a VM (QEMU/KVM/Libvert) I found that attempting to capture (single disk resizable) a fresh ISO (June 2026 Windows 11 Enterprise) install where I enter audit Mode and then sysprep, the capture fails to resize during the FOG capture process:

“An error has been detected! … Resize test failed! … Device name: /dev/sda3 … Space in use: 10535MB (16.6%) … Needed relocations: 1610313 (6596MB) … ERROR(28): Could not update runlist for attribute 0x80 in node 156294: No space left on device (shrink partition) Args Passed: /dev/sda /images…”

Previously I had no issue capturing an install using Windows 11 Build 28000.1836 via FOG. The older build allowed for smaller VM disk size such as 40GB if I recall. The newer June 2026 ISO Build requires around 50GB for Windows 11Enterprise to install (else there is an error) so I allocated 60GB to the current VM (where I am getting the capture error).

I found that on the June 2026 Build (28000.2269) if I set the EFI partition size to 2GB (still using 60GB VM disk size) during the installation using diskpart, complete the install, enter audit mode, sysprep, and then attempt the capture I am successful and there is no resize failure. Why does setting the EFI partition to a larger size allow the capture process to succeed? (I found this by accident as I was increasing the EFI partition for another reason discussed in the side note here.

Working in a VM (QEMU/KVM/Libvert) I found that attempting to capture (single disk resizable) a fresh ISO (June 2026 Windows 11 Enterprise) install where I enter audit Mode and then sysprep, the capture fails to resize during the FOG capture process:

“An error has been detected! … Resize test failed! … Device name: /dev/sda3 … Space in use: 10535MB (16.6%) … Needed relocations: 1610313 (6596MB) … ERROR(28): Could not update runlist for attribute 0x80 in inode 156294: No space left on device (shrink partition) Args Passed: /dev/sda /images…”

Previously I had no issue capturing an install using Windows 11 Build 28000.1836 via FOG. The older build allowed for smaller VM disk size such as 40GB if I recall. The newer June 2026 ISO Build requires around 50GB for Windows 11Enterprise to install (else there is an error) so I allocated 60GB to the current VM (where I am getting the capture error).

I found that on the June 2026 Build (28000.2269) if I set the EFI partition size to 2GB (still using 60GB VM disk size) during the installation using diskpart, complete the install, enter audit mode, sysprep, and then attempt the capture I am successful and there is no resize failure. Why does setting the EFI partition to a larger size allow the capture process to succeed? (I found this by accident as I was increasing the EFI partition for another reason discussed in the side note here)

I originally posted here and hoping for more feedback.

I am imaging a Dell laptop (Windows 11) using FOG. The laptop has two identical hard drives identified by FOG as /dev/nvme0n1 and /dev/nvme1n1

I imaged one of the drives a couple times, first using GParted to delete any existing partitions on any of the drives (not formatting). I recall one time after imaging Windows logged in after OOBE (the image was syspreped) and after restarting I got a Windows Inaccessible Boot Device Error. I had options to go into Windows recovery modes. I recall subsequent imaging and restart went ok.

At one point I decided to try imaging the other drive (again deleting any existing partitions first). After FOG finished its imaging and Windows started its setup, the computer started up Dell Diagnostics automatically (which happens on this laptop when both drives have their partitions erased). Subsequent imaging resulted in the imaging completing and Windows logging in as before though after restarting the Inaccessible Boot Device Error occured. I tried deleting the Windows Boot Manager entry in the firmware between reimaging however this did not resolve the issue.

I don’t see any option in the firmware to disable a drive. I physically removed the second drive and it imaged fine, about 4-5 reimages, and restarting Windows caused no issues.

Is this a UEFI/NVRAM issue or something else? Would there be anything I could try instead of having to remove one of the drives?