[Solved] This package requires a new servicing stack or a newer version of Windows (W10 21H2)
- Thread starter chrcol
- Start date
Because someone on here (a mod) in another thread suggested it to another user. NTLite itself even says it reduces image size.
Last edited:
Ok its working now. (in progress).
Article here states a SSU update is required first.
support.microsoft.com
Link here.
I downloaded from here. 5th link. Added it to ntlite, and its working.
For attention of nuhi
(I will remove that component removal from the preset, although I guess if its live install only its probably just doing nothing).
Article here states a SSU update is required first.
June 13, 2023—KB5027215 (OS Builds 19044.3086 and 19045.3086) - Microsoft Support
support.microsoft.com
Link here.
I downloaded from here. 5th link. Added it to ntlite, and its working.
For attention of nuhi
(I will remove that component removal from the preset, although I guess if its live install only its probably just doing nothing).
Attachments
0% chance of a bug?
I mean what could be wrong with the cache, I reverted the image, which empties it out, and started fresh again.
Lets see what nuhi says.
Hm, cannot replicate, it integrates fine here. Used this ISO, if you can please confirm on it as well as it is slightly different than yours EnterpriseEval vs EnterpriseS.
And added only cumulative update, as that is the report, the rest is more complex to sort and doubt that it matters (will see from your log).
Please repeat the process and attach %temp%\ntlite.log when the issue pops up.
Removals don't matter, integration is first.
Thanks.
And added only cumulative update, as that is the report, the rest is more complex to sort and doubt that it matters (will see from your log).
Please repeat the process and attach %temp%\ntlite.log when the issue pops up.
Removals don't matter, integration is first.
Thanks.
Apologies for the delay nuhi
I tested with that exact ISO, I used the default 3 updates ticked in ntlite (and net 3.5 template), and selected dism compatible, nothing else was touched, didnt use a preset.
Attaching the log. Ntlite-full includes the end as I attached it before it finished, and also some earlier stuff before this test.
I also tried it with just the single CU update, nothing else, with dism compatible, that log attached also.
I tested with that exact ISO, I used the default 3 updates ticked in ntlite (and net 3.5 template), and selected dism compatible, nothing else was touched, didnt use a preset.
Attaching the log. Ntlite-full includes the end as I attached it before it finished, and also some earlier stuff before this test.
I also tried it with just the single CU update, nothing else, with dism compatible, that log attached also.
Last edited:
Since I had never tried the combination of June CU on previous ntlite (initially ntlite wasnt showing me june updates, then when I restarted to update ntlite they showed up), I recovered the old ntlite (which gave me no problems with May CU) via VSS and tested that, it has the same issue.
Then tried kb5026361 which I think is May CU, still available in my update folder, on the current ntlite and its working, so hopefully this saves some time in trying to figure this out. It seems to be something changed in the CU format rather than something changed in ntlite. I will attach the log for this successful run when it finishes.
The June CU file does pass verification.
Then tried kb5026361 which I think is May CU, still available in my update folder, on the current ntlite and its working, so hopefully this saves some time in trying to figure this out. It seems to be something changed in the CU format rather than something changed in ntlite. I will attach the log for this successful run when it finishes.
The June CU file does pass verification.
Attachments
Last edited:
Thanks for the extra info.
So I tried the simplest case, KB5027215 + KB5027122, it integrates fine.
Even tested it under 1809 host, works as well.
Bit puzzling, could be what garlin mentioned, let's make sure the update cache is not corrupted.
Please go to File - Settings - Extracted updates cache and press Erase on the right of it, then retry on the reverted ISO edit.
Use latest version only.
If it fails again, try on another machine, potentially a VM to simplify things, no need to activate the tool for that.
Another theory it's something with the temp/scratch folders, you can try resetting those to their defaults as well (set to nothing and press OK), before loading an image.
Ok I will update my post on here when done these tests, I am going to just jump to new ntlite install on another machine first (with default paths), and if that works, then I will try again on this machine using default paths and freshly downloaded update, although this will be for testing as there is a reason I dont want to be storing lots of image cache's and updates on my c: drive.
Ok so I have had some time to do a bit more testing.
Sadly I couldnt do a proper test as the free version I couldnt do my setting of parallel + cache, I also couldnt pre download, had to just directly enqueue. This means a different processing flow, but this worked. Host machine is Win 10 21H2 LTSC.
On the c: drive, I downloaded the update before hand, verified it, enabled parallel+cache again, downloaded before enqueue. Drum roll....... It works, however I observed it did still have to extract.
So I repeated the process again to see what happens, when its pre extracted. But before i started I decided to check the extracted folder on the original updates folder.
There is a 1.8 and 1.9 rollup folder, the one that succeeded was 1.9. In the 1.8 folder is the 1.Windows blah cab file, but no SSU folder, doesnt exist, however on the extraction on the C: drive the SSU folder is there, I assume because the extraction is cached, obviously this same extraction cache kept being used.
In the 1.8 folder there is a SSU folder in addition to the main folder. This looks like to be the May update.
Hash values.
windows10.0-kb5027215-x64_45971faad5d92b3fe36347a915dd7144b7f3f0c0.msu in the update folder I was using is SHA256 DD69851F4D6DFAE22F955A3CEC33AD5D070E665C3FCFB796A1EAEF4B15B19968
In the updates folder with the extracted 1.9 with a SSU folder the SHA256 is DD69851F4D6DFAE22F955A3CEC33AD5D070E665C3FCFB796A1EAEF4B15B19968
Exactly same hash.
So same hash, ntlite verify passed, I think fair to say its not a corrupt CU update file.
Back to retrying the successful c: updates folder with a pre cached extraction. Works fine.
Now another test, configure the original updates folder again, but manually wipe the extracted folder and see what happens. It extracts and this time there is an SSU folder.
, this is the cached file I downloaded on 18 June.
So hmm ok, lets remove the extracted folder again, but this time add the language files back into the mix, with the .net stuff. No problem, extracted fine, no error.
At this point I figured out whats happened, but for certianty I repeated the test on my ISO and with my preset, it worked.
So what was the problem?
---
Sadly this wasnt in the full log, because if I understand right that log is reset on every new launch of ntlite. So the culprit happened just before ntlite was restarted.
I mentioned earlier ntlite originally didnt detect the updates, so I resorted to initially grabbing update files from that UUP website, I think I must have tried one run which failed, I then restarted ntlite to grab an update, then I seen it was detecting the new update files and reverted to using those again.
However...
On that first attempt it had extracted the CU update from the UUP download link, I have enabled to keep extracted folders in the cache. The UUP version of the update is a cab file, the one ntlite fetches natively is a msu file, so they different structures. Below is the sha256 and is different.
sha256 hash for update grabbed from UUP - 2B1C897C591253295F81B5570F22382A54D53D3340A41813481F61DF46793A50
The extracted folder name for the UUP update is the exact same name as is for the msu version. so ntlite doesnt realise its cached from a different update file. Which meant on all other future runs it kept using that cache even though I had selected the ntlite update.
Wow what a journey but we have the answer.
This testing took a while, wish I did it all on the other PC which is a 13700k it runs ntlite much faster. (primarily making the new iso for this machine lol)
So yeah wont be using UUP files again at least not for anything that can be downloaded via ntlite such as the CU, and perhaps you could maybe add a trim option that only trims the extracted folders, not the entire update folder? I suppose that could be done already maybe by selecting the none cache option if it wipes the extracted folder before starting?
Both versions of the patch have the named folder in extracted 'package_for_rollupfix~31bf3856ad364e35~amd64~~19041.3086.1.9.5027215'
Anyway mystery solved. I know now anyway to restart ntlite to make it detect newer updates as well.
Garlin's initial hunch correct, although I assumed he/she meant the download cache, I was not thinking about the extraction cache.
I might disable the extraction cache as extracting is fast anyway and I am using an enterprise SSD with an insane write limit for my cache scratch locations.
Sadly I couldnt do a proper test as the free version I couldnt do my setting of parallel + cache, I also couldnt pre download, had to just directly enqueue. This means a different processing flow, but this worked. Host machine is Win 10 21H2 LTSC.
On the c: drive, I downloaded the update before hand, verified it, enabled parallel+cache again, downloaded before enqueue. Drum roll....... It works, however I observed it did still have to extract.
So I repeated the process again to see what happens, when its pre extracted. But before i started I decided to check the extracted folder on the original updates folder.
There is a 1.8 and 1.9 rollup folder, the one that succeeded was 1.9. In the 1.8 folder is the 1.Windows blah cab file, but no SSU folder, doesnt exist, however on the extraction on the C: drive the SSU folder is there, I assume because the extraction is cached, obviously this same extraction cache kept being used.
In the 1.8 folder there is a SSU folder in addition to the main folder. This looks like to be the May update.
Hash values.
windows10.0-kb5027215-x64_45971faad5d92b3fe36347a915dd7144b7f3f0c0.msu in the update folder I was using is SHA256 DD69851F4D6DFAE22F955A3CEC33AD5D070E665C3FCFB796A1EAEF4B15B19968
In the updates folder with the extracted 1.9 with a SSU folder the SHA256 is DD69851F4D6DFAE22F955A3CEC33AD5D070E665C3FCFB796A1EAEF4B15B19968
Exactly same hash.
So same hash, ntlite verify passed, I think fair to say its not a corrupt CU update file.
Back to retrying the successful c: updates folder with a pre cached extraction. Works fine.
Now another test, configure the original updates folder again, but manually wipe the extracted folder and see what happens. It extracts and this time there is an SSU folder.
, this is the cached file I downloaded on 18 June.So hmm ok, lets remove the extracted folder again, but this time add the language files back into the mix, with the .net stuff. No problem, extracted fine, no error.
At this point I figured out whats happened, but for certianty I repeated the test on my ISO and with my preset, it worked.
So what was the problem?
---
Sadly this wasnt in the full log, because if I understand right that log is reset on every new launch of ntlite. So the culprit happened just before ntlite was restarted.
I mentioned earlier ntlite originally didnt detect the updates, so I resorted to initially grabbing update files from that UUP website, I think I must have tried one run which failed, I then restarted ntlite to grab an update, then I seen it was detecting the new update files and reverted to using those again.
However...
On that first attempt it had extracted the CU update from the UUP download link, I have enabled to keep extracted folders in the cache. The UUP version of the update is a cab file, the one ntlite fetches natively is a msu file, so they different structures. Below is the sha256 and is different.
sha256 hash for update grabbed from UUP - 2B1C897C591253295F81B5570F22382A54D53D3340A41813481F61DF46793A50
The extracted folder name for the UUP update is the exact same name as is for the msu version. so ntlite doesnt realise its cached from a different update file. Which meant on all other future runs it kept using that cache even though I had selected the ntlite update.
Wow what a journey but we have the answer.
This testing took a while, wish I did it all on the other PC which is a 13700k it runs ntlite much faster. (primarily making the new iso for this machine lol)
So yeah wont be using UUP files again at least not for anything that can be downloaded via ntlite such as the CU, and perhaps you could maybe add a trim option that only trims the extracted folders, not the entire update folder? I suppose that could be done already maybe by selecting the none cache option if it wipes the extracted folder before starting?
Both versions of the patch have the named folder in extracted 'package_for_rollupfix~31bf3856ad364e35~amd64~~19041.3086.1.9.5027215'
Anyway mystery solved.
I know now anyway to restart ntlite to make it detect newer updates as well.Garlin's initial hunch correct, although I assumed he/she meant the download cache, I was not thinking about the extraction cache.
I might disable the extraction cache as extracting is fast anyway and I am using an enterprise SSD with an insane write limit for my cache scratch locations.
Last edited:
garlin's rule:
Don't mix & match with other Windows modding tools. Every one of them makes a different assumption about managing files.
UUP dump itself is fine, but you're expected to consume the final product as an all or nothing ISO. Picking ala carte components is usually reserved for the advanced users because there's a lot of underlying metadata their scripts hide from you.
Don't mix & match with other Windows modding tools. Every one of them makes a different assumption about managing files.
UUP dump itself is fine, but you're expected to consume the final product as an all or nothing ISO. Picking ala carte components is usually reserved for the advanced users because there's a lot of underlying metadata their scripts hide from you.