in out tests the source was X23-81951_26100.1742.240906-0331.ge_release_svc_refresh_CLIENT_ENTERPRISES_OEM_x64FRE_en-us.iso no idea why, but it doesn't work when integrating only the highest LCU, but it works when installed one by one in the same dism session my conclusion is that we should get new W10UI and uup-converter which installs LCU as path to folder
That is manually. The script could look for packages of any KB name, run them in a specified or alphanumeric order, saving the changes after each pass. Does that one command update the winre and winpe files with one run, with the updated winre back into the mounted install.wim image before saving? If not, that can also be scripted. When you said one by one I thought you meant to each of the 3 places to update and all the steps in proper order. I'm pretty sure winre.wim requires being mounted after mounting install.wim before it can be updated, too. Anyway if it's more than one command scripting could save a lot of time in the future. Or just wait for someone else to do it.
in short: we already have W10UI for automatic updates integration the problem: current version integrates only the highest LCU, but MSFT have said we should integrate all LCU MSU one by one and it turns out they were right, W10MUI with the current W10UI can't integrate the latest update /PackagePath:"F:\UUPs" is the same as /PackagePath:"F:\UUPs\LCU1.msu" /PackagePath:"F:\UUPs\LCU2.msu" it doesn't matter if it was in one session or not /PackagePath:"F:\UUPs" takes a lot of time, but it works and it's documented by MSFT
I really can’t understand: when I posted KB5043178, https://forums.mydigitallife.net/th...-2024-24h2-26100-x.88280/page-85#post-1853033 I was accused that this was not the right thing, not for Retail, I was spreading misinformation, etc... (although I myself was writing that this was a Preview for insiders). Now, if I understand correctly, you yourself are trying hard to integrate (install) this update... Why?...And which of us is the fool then?
this is the problem, it processes only the highest LCU, we need new version which reinstalls all LCU MSU from the folder the fool is the one waiting for the new revised patch
I agree, the problem with manual integration is that that is not what the W10UI experience offers with all the other updates (winre.wim/boot.wim) and resetbasing and such... MSFT makes the homebrew updating experience a bit problematic this way.
I'm just wondering what these titanic efforts of yours are for. Probably, there must be some kind of purpose... If someone does something, then, probably, for some purpose... Unless, of course, he is a madhouse patient ...
we have found the problem in the current version of the W10UI https://forums.mydigitallife.net/posts/1853733 happy now?
You yourself was writing that the problem is in the new checkpoint-update method... Naturally as far as I understand the old W10UI is unlikely to work correctly with this method. But I'm sure abbodi1406 will update the script.
the old version should work because it integrates all LCUs, not just the highest one, but it doesn't have the SSU sorting code so we can't use it Abbodi insisted that integrating only the highest LCU is the most correct and efficient way well, it was, but it doesn't work with the new MSFT ISO, so we need to get back to the old method (but this time it should integrate all LCUs in the same session) new ISO - new compatibility testing, it's that simple doesn't matter if LCU wasn't intended for the retail channel
I recently read somewhere that if you install a regular update manually (i. e. not via WU), then you may have problems installing the next update. Because a checkpoint was not created. They are created only when updating via WU.
For UEFI your usb stick needs to be 8gb+ Partition Table in GPT, not MBR and format in NTFS for install.wim over 4gb file size. Creating with rufus it should work. Isn't it work for you if you use the apropriate Rufus settings for GPT?