Windows Embedded 7 preparing to send image exception
-
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. -
From your post its not clear, are you able to capture / deploy to the 8GB SSD but not the 16GB SSD?
IF FOG is not able to deploy to either, then I would question how is storage being presented to the the FOS engine (the linux OS that runs on the target computer which captures and deploys storage images). From the FOG iPXE boot menu select the compatibility tests do both the network and storage pass?
You may want to download the latest trunk build of the kernels, which are about version 4.6.2. This will give you access to the latest drivers for the newest hardware. Or if your just upgrade to the trunk build (or 1.3.0 rc1 which was just released) to get better debugging tools for your deployment. There is an answer here we just need more information on your hardware.
-
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). -
@Marinus OK the pictures help quite a bit.
I guess I have 2 questions
- Do all systems with 16GB fail the same or is this the first and only one you have tested?
- Does the embedded device (firmware) support 16GB media?
(I’ve worked at a royal dutch company before, so no worries. I can translate).
-
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).
-
@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/bzImage32This 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.
Please help us build the FOG community with everyone involved. It's not just about coding - way more we need people to test things, update documentation and most importantly work on uniting the community of people enjoying and working on FOG!
-
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. -
@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.
-
@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/bzImage32This 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?
-
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). -
@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).
-
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.
-
@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.
-
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:\windowsDiskpart 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 = cLooking 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. -
@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.txtand resizedisk.txt contains
select disk 0 select partition 2 extend exitNot sure if that info will help you or not.
-
@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
lsblkandfdiskwould 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. -
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 ….
