Windows Embedded 7 preparing to send image exception
-
@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 ….
