Windows Embedded 7 preparing to send image exception

[Marinus]

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

[george1421]

@Marinus You can update the kernels, easy is a relative term.

You can download the latest kernels for 1.3.0-rc1 using these links.
https://fogproject.org/kernels/bzImage
https://fogproject.org/kernels/bzImage32

This need to be placed in /var/www/html/fog/service/ipxe directory. Just rename the original files and place these files there.

Do you know if these ssd storage devices are NVMe based or do the emulate a traditional sata ssd? This is important to know since 1.2.0 stable doesn’t support NVMe drives, the trunk build and 1.3.0-rc1 does. You will either need the trunk build to support uefi firmware, gpt disks, NVMe drives, and Windows 10.

More info is not necessary, we are only interested in the hardware not its use. If you do build a trunk build or 1.3.0-rc1 build that will give us better debugging tools too. So it may be worth the effort to go that path if you have the time.

[Marinus]

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.

[george1421]

@Marinus Just looking over the datasheet, nothing stands out as special. This chip presents itself as a sata drive to the host system. It has all of the onboard stuff to do the translation to nv storage. So I think you are on the right path, with updated kernel image. Do use the current FOG kernels, if that doesn’t work then spin up 1.3.0-rc1 to give better debugging tools.

… actually I wonder if just usb booting the FOS engine (the custom linux OS built by FOG) would be a quicker way to help us test. Since you have ubuntu lts you can follow these instructions https://forums.fogproject.org/topic/7727/building-usb-booting-fos-image/4 If you can’t build the usb boot drive, I have an image that I already created I can share. You will have to update grub to use the 32 bit kernel and intis, but it should work. The idea is to boot from this usb drive and select option 6 to get into the debug kernel this will drop you to a linux command prompt where we can collect some device information needed for debugging.

[Wayne Workman]

@george1421 said in Windows Embedded 7 preparing to send image exception:

@Marinus You can update the kernels, easy is a relative term.

You can download the latest kernels for 1.3.0-rc1 using these links.
https://fogproject.org/kernels/bzImage
https://fogproject.org/kernels/bzImage32

This need to be placed in /var/www/html/fog/service/ipxe directory. Just rename the original files and place these files there.

Do you know if these ssd storage devices are NVMe based or do the emulate a traditional sata ssd? This is important to know since 1.2.0 stable doesn’t support NVMe drives, the trunk build and 1.3.0-rc1 does. You will either need the trunk build to support uefi firmware, gpt disks, NVMe drives, and Windows 10.

More info is not necessary, we are only interested in the hardware not its use. If you do build a trunk build or 1.3.0-rc1 build that will give us better debugging tools too. So it may be worth the effort to go that path if you have the time.

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

[Marinus]

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

[george1421]

@Marinus After I made my post, Tom posted a tidbit of information in another thread that only Tom knew about. With FOG 1.2.0 it can only support kernel images below 4.4. Once you get to 4.4 and newer the kernel relies on some additional code in the inits that is part of the trunk build (and 1.3.0-rc1). One way for you to use the latest kernels is to upgrade to 1.3.0-rc1 (a.k.a the trunk release).

[Marinus]

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.

[george1421]

@Marinus You might want to start here with your kernel search: https://sourceforge.net/projects/freeghost/files/KernelList/

You will be better served just moving to 1.3.0-rc1 (or rc2 that will be released in the next day or so). The migration path between rc1 and rc2 is not difficult. To go from 1.2.0 to 1.3.0 just use the “upgrade to trunk” process.

[Marinus]

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.

[george1421]

@Marinus I’m not really sure what you are telling us here. Is the issue with FOG or with the way you created the master image?

I can say before FOG supported resizeable disks. We would create our reference image on a 40GB drive (smaller that our current fleet of computer disks). Then during the setupcomplete.cmd file we would run the following command to expand the disk to what ever size the physical disk was.

diskpart /s C:\Windows\Setup\Scripts\resizedsk.txt

and resizedisk.txt contains

select disk 0
select partition 2
extend
exit

Not sure if that info will help you or not.

[Wayne Workman]

@Marinus said in Windows Embedded 7 preparing to send image exception:

My problem now is, how does diskpart know the size of the SSD, if this parameter is not present.

If a Linux kernel can use the drive at all, then certainly common utilities like lsblk and fdisk would work, these are some of the things that FOG uses to get information about a disk. However, if your partition layout was already messed up, it’s very highly likely that the calculations that fog would make with those messed up parameters wouldn’t work.

[Marinus]

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