How does abbodi1406 know? Why can't there be a simple way to verify what requires what? Aside from this rant, what is the earliest version of Windows 19041 I can use to update to 19043.844? I'd rather redo it from scratch than take chances of a corrupted OS update.
The build date for SS is 02/04 and the build date for CU is 02/10. I bet 841 SS is supposed to be installed before 844 CU.
Open the update cab file with 7-zip and view/open update.mum file it shows the minimum required SSU version KB4601382 Code: <installerAssembly name="Microsoft-Windows-ServicingStack" version="10.0.19041.504" language="neutral" processorArchitecture="x86" versionScope="nonSxS" publicKeyToken="31bf3856ad364e35" /> KB5000736 Code: <installerAssembly name="Microsoft-Windows-ServicingStack" version="10.0.19041.153" language="neutral" processorArchitecture="x86" versionScope="nonSxS" publicKeyToken="31bf3856ad364e35" /> if the version listed is 6.0.0.0 then no explicit SSU version is required
If CU is applied on top of an older-than-required SSU, then does CU application process generate errors or does it simply refuse to update?
I installed the 19043.844 update yesterday and I just checked the updates and they are KB4601382 = Code: <installerAssembly name="Microsoft-Windows-ServicingStack" version="10.0.19041.504" language="neutral" processorArchitecture="x86" versionScope="nonSxS" publicKeyToken="31bf3856ad364e35" /> KB5000736 = Code: <installerAssembly name="Microsoft-Windows-ServicingStack" version="10.0.19041.153" language="neutral" processorArchitecture="x86" versionScope="nonSxS" publicKeyToken="31bf3856ad364e35" /> Not really sure what this means are the SSU intergrated in the LCU or seperate? hope I am understanding this correctly.
@bonesz installerAssembly = the minimum required servicing stack version, not the update version itself 10.0.19041.504 = SSU KB4577266 (September 2020) meaning, KB4601382 require KB4577266 or any later SSU
I can see that or would say already seen that but that is not something that I've asked and neither that clarify the matter.
I have only updated 21H1 EP to 19041.804 VM & now its showing 19043.804 21H1. I will wait for M$ to release LCU , SSU & DU too.
They can be found here: https://forums.mydigitallife.net/threads/windows-10-hotfix-repository.57050/page-588#post-1645340
Just created 19043.844 esd and size is 3.8gb, so figure in two months recovery esd won't fit on fat32 key Spoiler 02/18/2021 05:08 PM 4,090,128,668 install.esd -------------------Fat32 limit 4,294,967,295
Size depends on what you did to it, did you run a cleanup command after/during integrating updates? This is my install.esd from a 19042.804 source WIM updated with only the 21H1 updates, no cleanup possible because of pending flag in the source 19042.804 WIM (which is created by W10UI_9.2 with resetbase set): Code: SKUs: Home, Pro, Education & Enterprise x64 nl-NL Name: install.esd Size: 3625371786 bytes (3457 MiB) Running WIM<>ESD on this WIM (Home x64 only, as base for all other SKUs to be based on): https://forums.mydigitallife.net/th...20h1-2-vb_release.80763/page-318#post-1645619
I added .net 3.5. I avoid cleanup ever since the bug in (iirc 1903), blocking install of new CU if you did cleanup.
That was with a small range IP build CUs which were missing some components. W10UI avoids the resetbase of the LCU for 1903/9/20H1/2/21H1, but it's a few 100MB less then without running it. The wim mentioned also has 3.5 pre-enabled, the settings are shown in the post. wim<>esd is at 43%
That would somewhat resemble what i did with the install.esd here: I think we are good to go for a while (even with your filesize) Code: SKUs: Home x64 en-US 19043.844 Name: install.esd Size: 3181801882 bytes (3034 MiB)