ESD Compression

fxart

fxart

New Member
Hello to Everyone!
My work is to installa continuosly 10P [any builds], LTSB, LTSC, and SEVEN over differents industrial mainboards with different bios vendors.
I have noticied that repacking the WIM file in ESD format, in some rare circumstances, after the first reset, OS setup didn't not find the partition to continue his setup.
The same OS image in wim format, works 100% fine always.
But the problem is not related to one BIOS/Motherboard version, is random.
This problem has never appear before the latest 10 updates of NLITE.

Mainboards are produced by ASRock, Advantech, AAEON, Commell, Aplex. Bios are AMI APTIO, Phoenix or AWARD.
These can be in Legacy or GPT.
USB pendrives are written with Rufus or similar.
Disks utilized can be SSD of Transcend, Innodisk, Samsung Pro or WD
Can be something that we have to check before repacking into ESD??
for this operation I have always choose NTLITE.

In Wim format, no problems at all but the Wim size can be at least 7 / 9GB when ESD max 6.1GB.
Also original untouched images!

Thanks a lot.
 
What was your previous version of NTLite? From the change log:

October 27, 2020​

2.0.0.7705

Upgrade​

Source: Improved ESD image compression detection for some custom images
 
to be honest i havent heard of this issue before. you say this occurance is rare, approximately how rare ? 1 in 10 , 1 in 20 ?

would be interesting to know which board and or bios the issues arise with
 
fxart said:
I have noticied that repacking the WIM file in ESD format, in some rare circumstances, after the first reset, OS setup didn't not find the partition to continue his setup.
In Wim format, no problems at all
Click to expand...
Hello,

just to make sure, please do the following when you see the ESD/partition issue next time:
- reboot and retry again, same ISO
- if the same error repeatably, never passes, convert ESD to WIM, remake ISO/USB
- retry, does that really solve the issue? Repeatably passes?
- if it fails as a WIM, you might think that going once to ESD already corrupted the image.
To retest that, please edit the image in a WIM format always, copy the install.wim aside and convert to ESD from the Source page before copying to the ISO (or choose right-click Export - ESD on that WIM when copying to the USB/ISO), so you have both files to switch independently.

And the obvious, if you claim that it always worked with the older NTLite, do you have it, try with it, at least the ESD conversion.
The ESD library was updated few versions ago.

Haven't noticed a similar report so far, so let's first pin-point if it is really the ESD conversion.
It's more likely that it depends on the disk existing state, maybe when switching from BIOS to UEFI modes and vice-versa, sometimes disk requires manual cleanup.

Let me know if you have more info.

Thanks.
 
I had a similar problem, I don't know if it's the same. But the error appears on the first boot with the ISO (I don't remember well but I think it's in the part where it starts copying the files). The image is corrupted when converting to ESD. It looks like a bug with wimlib. Tried converting with wimlib 1.13.4 and same problem. I have not tried with the new version 1.13.5.
 
nuhi said:
Hello,

just to make sure, please do the following when you see the ESD/partition issue next time:
- reboot and retry again, same ISO
- if the same error repeatably, never passes, convert ESD to WIM, remake ISO/USB
- retry, does that really solve the issue? Repeatably passes?
- if it fails as a WIM, you might think that going once to ESD already corrupted the image.
To retest that, please edit the image in a WIM format always, copy the install.wim aside and convert to ESD from the Source page before copying to the ISO (or choose right-click Export - ESD on that WIM when copying to the USB/ISO), so you have both files to switch independently.

And the obvious, if you claim that it always worked with the older NTLite, do you have it, try with it, at least the ESD conversion.
The ESD library was updated few versions ago.

Haven't noticed a similar report so far, so let's first pin-point if it is really the ESD conversion.
It's more likely that it depends on the disk existing state, maybe when switching from BIOS to UEFI modes and vice-versa, sometimes disk requires manual cleanup.

Let me know if you have more info.

Thanks.
Click to expand...
Hi Nuhi.

Thanks for your reply.

I think there is a problem with wimlib.
I have always used your app from the beginning.
I'am one FAE for one of the most famous italian PC's Industrial Manufacturers.
We produce and assembly at least 400/500 pc's every months so I know what I install.

I know that can be strange.
Every time I found this problem in the past, I rewrote the iso on another new pendrive without success.
But the new pendrive fail again on this PC.
The same pendrive works with other chipset hw but has always works with this hw before your major updates.

After investigatin and trying to maintain the ISO structure 100% compatible, I really focused the problem unpacking the ESD to WIm and writing it back on the same pendrive and it works always.

believe me: it's depend by ESD compression.
I will have regenerated the different masters at least 50 times to understand if one of the integrated drivers could create problems before writing it here ...
Why the same image in wim format works always with the same HW, pendrive, SSD, same HW config and why not if the wim is converted to ESD?

If you need my help to test something, I think I'm the right person because the base of my HW starts from the Celeron J1900 up to the latest 12th generation Intel.

This is not to criticize your work.
I'll love your app and dedication.

Thanks in advance.
 
fxart said:
After investigatin and trying to maintain the ISO structure 100% compatible, I really focused the problem unpacking the ESD to WIm and writing it back on the same pendrive and it works always.

believe me: it's depend by ESD compression.
Click to expand...
OK, so let's recap, as you gave a lot of interesting info and to make sure we're on the right track:

- same ESD works on some hardware, not on another, can you next time write down what is the difference in terms of CPU model, RAM size and disk model between those?

- regarding the non-compatible machines, I presume they reliably fail always, it's not like random as we misunderstood earlier, you meant random machine type?

- even though you go over 400+ each month, somehow you know that the same new machine was working before with ESD, that part is a bit tricky.
Could it be that Windows changed in the meantime, let's say before you used Win10 21H1, now Win11 21H2, etc?

Only thing that comes to mind regarding NTLite updates and this is the newer wimlib and Windows SDK, but AeonX states that the previous version had it as well so maybe it's Windows version itself in regards to certain hardware.
Let's see the comparison what you list as an example then we can see more, maybe I can test it myself etc.

Thanks.
 
I confirm what fxart writes, I also have such a problem - not always, but it is also for WIN 10 or WIN 11.
What have I not tried and this reason is not there?
 
In my tests I used Win 10 21H2. A detail that I forgot to mention and that may be related is that I always uncheck the option "Verify image files" in File -> Settings in NTLite to save time. It would be interesting to test with this option checked. Although this is still a bug it can be a workaround.
 
nuhi said:
OK, so let's recap, as you gave a lot of interesting info and to make sure we're on the right track:

- same ESD works on some hardware, not on another, can you next time write down what is the difference in terms of CPU model, RAM size and disk model between those?

- regarding the non-compatible machines, I presume they reliably fail always, it's not like random as we misunderstood earlier, you meant random machine type?

- even though you go over 400+ each month, somehow you know that the same new machine was working before with ESD, that part is a bit tricky.
Could it be that Windows changed in the meantime, let's say before you used Win10 21H1, now Win11 21H2, etc?

Only thing that comes to mind regarding NTLite updates and this is the newer wimlib and Windows SDK, but AeonX states that the previous version had it as well so maybe it's Windows version itself in regards to certain hardware.
Let's see the comparison what you list as an example then we can see more, maybe I can test it myself etc.

Thanks.
Click to expand...
Hi Nuhi,

- it's not depend by Windows build. The problem appear also with old builds and also with Seven Professional x86/x64. One example: Mainboard Advantech AIMB-275 with intel Core i5 I6500TE, 16GG RAM and SSD 128GB Transcend & 10P 21H1 or 21H2. Standard wim installation goes always fine. Same wim repacked in ESD format, same pendrive, same machine, same HW, anything changed, fail. But the same pendrive, on another HW [different chipsets like Braswell] goes fine. When the problem appear, ALL THE PC's with the same chipsets can't be installed with the ESD ISO. I have to take the same image in WIM format to continue my jobs. I know that results are the same but the ISO size goes bigger.

For my tests, wimlib ESD compression does not like to much Baytrail Chipset [J1900, N2930, Skylake chipset [i3, i5].

Also with SEVEN.
First restart during setup Windows cannot find the source where he has put his installation files and wait... [press any key to boot ...]
 
A single layer dvd has 4.3gb availible once its been formatted with Nero(Express).
 
Last edited:
You must log in or register to reply here.
Back
Top