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 ….

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 ….

Yesterday and today several things tested.
First of all a suggestion from the supplier of the hardware.
The test gives an result, error writing, No space let on device……
Next I updated my bzImage file, to 3.19.3.
Again I received other errors, but comparable with the earlier.
Next I updated my environment to V1.3.0-rc…
Still errors.
But everything together, it gives me a clear picture.
For some reason the tooling tries to write/read to many sectors.
For installing the Windows Embedded Standard 7 software I’m using a batch file.
This batch file is working fine for the 8GB SSD.
The contents of the batchfile:
Diskpart /s DoAction16GB.txt
*Dism /Apply-Image /ImageFile:V300.WIM /Index:1 /ApplyDir:C:*
bcdedit /delete {default}
bcdboot C:\windows

Diskpart is calling the file DoAction16GB.txt
The contents:
Select disk 0
Clean
Create partition primary
Select partition 1
Active
Format fs=ntfs label=Wes7 quick
Assign letter = c

Looking to the diskpart script, Create partition primary doesn’t have any optional parameter.
One of the possible parameters is size.
If this parameter isn’t present, it takes the maximal possible size.
I tried a shot, with the size=12000, which means, a partition of 12GB on my 16GB SSD.
And, yes, my problem was solved.
Next, after some experiments, I have now added the size parameter with 15200.
All my problems are solved, even with the FOG 1.2.0 original installation.

My problem now is, how does diskpart know the size of the SSD, if this parameter is not present.
I have asked the question to the supplier of the Embedded PC.
But, perhaps some of the forum users knows it?

FOG 1.3.0 looks very good. I must look to the impact of switching to the latest release.
Thanks for the support.

All right.
Monday I want first test with the last kernel version which will work with FOG 1.2.0.
I understood, version 4.4 and higher is not working with FOG 1.2.0.
I was looking for older version, but was not able to find these.
Can you point me in the right direction?

If this fail, I will look to FOS (very interesting) and to upgrade to 1.3.0.

Can someone confirm this statement?

“George, remember Tom’s post about these late kernels not working in 1.2.0?”

Is it useful to test the mentioned kernel with version 1.2.0?
At this moment I have a kernel from mid 2014. Can I find somewhere the last kernel which works with 1.2.0?
Monday I want to test. I think it’s easy to try several kernels…(rename, copy, test, etc).

Coming Monday I have time to test with the new kernel bzImage32 (it’s 32 bit computer).
Thanks for the link.
I will try first the kernel update, that’s much easier for the final installation.
I have the datasheet of the SSD device link text.
Perhaps you can see potential problems. In my opinion, 8GB is working, so the method is not the problem. I’m still thinking in the number of sectors, which for some reason is running to far …
If the kernel update fails, I will start building new VDI with FOG 1.3.0. But this takes time for me, since I’m not a real Linux User, but I see it as a challenge to learn.

At this moment I have two modified Embedded PC boards with the 16GB SSD soldered.
Both have the same behavior.
The BIOS is recognizing the SSD chip (unfortunately I have no picture of this screen at this moment).
I can see it in one of the BIOS screens.
So, I suppose the Embedded PC supports this 16GB device.
I will send also a email to the supplier to get the confirmation.
I think the device is supporting the 16GB variant, since the Windows Embedded is running well on the 16GB. I installed the Windows Embedded via the Windows tooling DISM. Via DISM it is also possible to make a attended copy (WIM file). This attended copy can be installed without any problem on the second Embedded PC board.

I have a question to you.
What’s FOG doing during the “preparing to send image” step?
Does this have any relation to the kernels you mentioned?
How can I update easily to version 4.6.2? If I look to the Fog Configuration, Kernel Update, I get many different types. Which one is the correct one?

Later I will build a VDI with the latest release. At this moment I’m working for different companies (more info I won’t give on the public forum).

For some reason the JPG pictures are not present, I don’t see them.
These will clarify in more details my problem, I suppose.
Working is already, capture and deploy a 8GB SSD.
Now on exactly the same hardware platform the 8GB SSD chip is replaced by a 16GB SSD chip.
I got now errors/warning during the capture process. Finally it captures, but it takes long.
I will also try again to add the pictures. Pictures says more than thousand words (sorry for my English, I’m from the Netherlands).

link text
link text
link text

Hello all. This is my first post on this forum, because I’m a little desperate.
I’m very impressed of the FOG software and the stability. Great job.
For several years, I have FOG 1.2.0 running on Ubuntu 14.04LTS. I think around 2014 (at the moment FOG 1.2.0 was released).
This installation is working perfect, installing a Windows Embedded Standard installation on Embedded PC boards. These Embedded PC boards are equipped with a 8GB SSD on board chip.
At this moment we want to change the 8GB on board chip into a 16GB chip, from the same family.
Last week I tested the Embedded PC with 16GB SSD. The Windows Embedded image is running well.
Via Dism I can create an WIM image file from the 16GB SSD. This WIM image can I store on a second Embedded PC.
For regular use I want to create a FOG image of the 16GB SSD. At the moment I retrieve the image, I receive the following errors.
On the point “preparing to send image file to server”, it starts generating exceptions, see also the picture.
It takes a while, before the first error is coming. With pauses of a few seconds, many of these are coming. On the third line tag xx is present, this one is incremented. I think till tag 19.

I did also a surface check via FOG. The same errors are present.
But the check succeed.

At this moment I have the idea, the FOG software (or driver) is reading too many sectors.
But I have no idea, how to control.