At this moment I have very less time to investigate (reasons which I don’t want to share on a public forum).
From the supplier I got a response:
Why “create partition primary” would not work as expected (=reserve all available space for a single partition), is not quite clear to me. It might depend on the version of “diskpart” (and its specific flaws), as well as the cyl/head/sector information read from the SSD, or the C/H/S mapping the BIOS applies which may differ from what the SSD tells (yes, this mapping stuff is still around after all these years of LBA…), and may as well depend on the setting of ACPI vs. IDE in BIOS (not sure if the hardware has this at all).
The suggestion to use the tools lsblk and fdisk is very interesting, to see the information which Linux reads from the SSD.
I’m not familiar with Linux, but we can learn. Takes only time.
I have still the idea, there is a mismatch between the SSD configuration, the BIOS information about the SSD, the information windows is using during diskpart and the Linux information.
I’m using FOG very basic. With the Windows Tooling I’m creating an working setup on my golden hardware model (8GB SSD and 16GB SSD). With the FOG tooling I create an image (Multiple Partition Image – Single Disk, Windows 7, not resizable).
The created image is distributed to many identical hardware models (without any modification on the image).
Now, if I create the 16GB image with the windows tooling, while I use the Create partition primary with the size parameter set to 15.2GB, everything works. FOG is not generating any error.
Later (September) I will check in more detail the mismatch ….